Re: format is locale aware

[Eric Blake]

On Tue, Jun 08, 2021 at 04:15:36AM +0200, Bruno Haible wrote:
> Hi,
> 
> After building m4-1.4.19 on DragonFly BSD 6.0, with LC_ALL=fr_FR.UTF-8,
> "make check" shows a test failure:
> 

> And indeed, the src/m4 program behaves in a locale dependent manner:
> 
> $ src/m4
> format(`%.0f', `9.9')
> src/m4:stdin:1: non-numeric argument 9.9
> 9
> format(`%.0f', `9,9')
> 10
> format(`%.1f', `4')
> 4,0

Thanks for the report. This is an unintended regression introduced by
the fact that 1.4.19 was the first version to change the program
locale away from the default of "C" in order to allow gettext to work.

> 
> I see the same behaviour also on a glibc system.
> 
> 1) Is the number parsing and printing of numbers in 'format' supposed to
> be locale dependent? If yes, it would be good to document it in
> https://www.gnu.org/software/m4/manual/html_node/Format.html .

Format is not a POSIX-mandated macro, so we can make whatever decision
we want about its behavior.

However, as previous versions of m4 were NOT locale-aware, enabling
locale support on what was supposed to be a minor release feels
awkward; it might be better to make m4 1.4.x remain
locale-independent, and reconsider enabling locale support (possibly
via an opt-in mechanism) for future 1.6 or 2.0 releases.

I'm also aware of someone that has been considering posting a patch
that would teach the eval() builtin to operate on floating point.  The
eval macro IS specified by POSIX, but leaves behavior unspecified for
non-integral input, so there is some wiggle room to allowing
floating-point math by default.  Still, having it be opt-in would
coincide with whether floating point parsing and results should be
locale-dependent, at the same time as format.

> If no, the fix would be in main.c: Add a
>   setlocale (LC_NUMERIC, "C");
> after setlocale (LC_ALL, "").

Or to use gnulib c-strtod and c-vasnprintf modules.

> 
> 2) Why do I see the test 180 fail on DragonFly BSD but not on a glibc
> system? In both cases, I have LC_ALL set to fr_FR.UTF-8, and this locale
> exists (verified with 'locale -a').

May be due to differences in strtod() parsing on those platforms, or
something we may have overlooked in gnulib.  Definitely worth some
further investigation, especially if it persists with the use of the
c-strtod module.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org