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
