On Tue, Jun 08, 2021 at 06:16:05PM +0200, Bruno Haible wrote:
> Hi Eric,
>
> > However, as previous versions of m4 were NOT locale-aware, enabling
> > locale support on what was supposed to be a minor release feels
> > awkward
>
> Yes; it can break some existing scripts that invoke m4.
>
> > > I
Eric Blake wrote:
> > 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 m
Hi Eric,
> However, as previous versions of m4 were NOT locale-aware, enabling
> locale support on what was supposed to be a minor release feels
> awkward
Yes; it can break some existing scripts that invoke m4.
> > If no, the fix would be in main.c: Add a
> > setlocale (LC_NUMERIC, "C");
> > a
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')
> sr
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:
Checking ../../checks/180.format
@ ../doc/m4.texi:6066: Origin of test
../../checks/180.format: stdout mismatch
--- m4-tmp.452851/m4-xout 2021-06-08 03:26:41.805343000 +0200
+++ m4
