Hi Paul,
> Making the variable 'static' might cause some compilers to notice that
> the variable never changes, so it's a constant, so it can be folded, and
> then they (mistakenly) convert -0.0 to 0.0. Originally the variable was
> extern and the extern hack prevents most compilers from doing thi
On 3/13/19 11:35 AM, Bruno Haible wrote:
> A simpler fix would have been to mark the 'minus_zero' variable as 'static':
Yes, that would have been a smaller change. Although I originally did
that, there's a reason I went for the larger change.
Making the variable 'static' might cause some compiler
Pavel Raiskup wrote:
> Is there a gnulib/GNU-preferred way to do this, defined somewhere? I'd
> like to avoid such mistakes in future
There is no GNU-preferred style, nor a gnulib-preferred style. Just for the
gnulib-tool program there is a preferred style.
2019-03-13 Bruno Haible
g
Paul Eggert wrote:
> Thanks for the bug report. I installed the attached patch into Gnulib.
A simpler fix would have been to mark the 'minus_zero' variable as 'static':
--- a/lib/strtod.c
+++ b/lib/strtod.c
@@ -302,7 +302,7 @@ compute_minus_zero (void)
}
# define minus_zero compute_minus_zero
On 3/13/19 5:46 AM, Pavel Raiskup wrote:
>
> Is there a gnulib/GNU-preferred way to do this, defined somewhere?
Not that I'm aware of. Opinions differ. I tend to agree more with Jim
Meyering, and prefer a quoting style like this:
save_IFS=$IFS
for arg
do
IFS=$save_IFS
[Som
On Tuesday, February 19, 2019 7:02:08 PM CET Bruno Haible wrote:
> Hi Pavel,
>
> > > [...]
> > > This patch fixes both issues, and makes the IFS handling a bit more
> > > robust.
> > > [...]
> >
> > > -case $_fpf_arg in
> > > +case "$_fpf_arg" in
> > > [...]
> > > - fpf_dirs=$1 ; shift
