Bruno Haible wrote:
> Paolo Bonzini wrote:
>> > + c_locale = newlocale (LC_ALL_MASK, "C", (locale_t)0);
>>
>> Can we cache c_locale in a static variable?
>
> This would make sense for speed, yes. (Think of calling c_strtod in a loop,
> like it is done in getloadavg.c.) Here is a proposed patch. O
Bruno Haible writes:
> Peter Seebach and Simon Josefsson wrote:
>> > Note that NULL could
>> > be the same, or it could be already converted to (void *), so it depends on
>> > the implementation whether:
>> >
>> >printf("%p\n", NULL);
>> >
>> > is legit. (Which means it's not portable...)
>>
Peter Seebach and Simon Josefsson wrote:
> > Note that NULL could
> > be the same, or it could be already converted to (void *), so it depends on
> > the implementation whether:
> >
> > printf("%p\n", NULL);
> >
> > is legit. (Which means it's not portable...)
>
> Indeed, and a quite realisti
se...@seebs.net (Peter Seebach) writes:
> In message <200901212258.n0lmwqx07...@f7.net>, Karl Berry writes:
>>I am surprised. I thought 0 was supposed to be a valid null pointer in
>>all contexts, without casting.
>
> 0 is a null pointer constant. In a context where the language anticipates
> a
In message <200901212258.n0lmwqx07...@f7.net>, Karl Berry writes:
>I am surprised. I thought 0 was supposed to be a valid null pointer in
>all contexts, without casting.
0 is a null pointer constant. In a context where the language anticipates
a pointer, a null pointer constant becomes a null po
> I suppose NULL isn't necessarily defined
Hard to imagine.
POSIX explicitly mentions (locale_t)0
I am surprised. I thought 0 was supposed to be a valid null pointer in
all contexts, without casting.
Paolo Bonzini wrote:
> > + c_locale = newlocale (LC_ALL_MASK, "C", (locale_t)0);
>
> Can we cache c_locale in a static variable?
This would make sense for speed, yes. (Think of calling c_strtod in a loop,
like it is done in getloadavg.c.) Here is a proposed patch. OK, Jim?
2009-01-21 Bruno Ha
Hi Jim,
> I prefer to avoid casts, so please use this test instead:
>
> if (!c_locale)
If you prefer this way. I committed it like you say.
> > + c_locale = newlocale (LC_ALL_MASK, "C", (locale_t)0);
>
> I suppose NULL isn't necessarily defined
POSIX explicitly mentions (locale_t)0. I s
Bruno Haible wrote:
> Sorry for the delay.
>
>> I've reworked those patches accordingly,
>> but didn't test on a MacOS X system.
>> Since your name is on them, I'll wait until
>> you acknowledge before pushing.
...
> Sure, fine with me. You can put yourself into the ChangeLog entry, of course.
> I
Eric Blake byu.net> writes:
> As of this morning, autoconf.git now warns you on instances of expand-before-
> require (aka ordering bugs in older autoconf, and redundant output when using
> bleeding edge autoconf). I'm working on a series of patches to reduce the
> number of warnings we trigge
Eric Blake byu.net> writes:
>
> As of this morning, autoconf.git now warns you on instances of expand-before-
> require (aka ordering bugs in older autoconf, and redundant output when using
> bleeding edge autoconf). I'm working on a series of patches to reduce the
> number of warnings we tri
As of this morning, autoconf.git now warns you on instances of expand-before-
require (aka ordering bugs in older autoconf, and redundant output when using
bleeding edge autoconf). I'm working on a series of patches to reduce the
number of warnings we trigger, starting with this one:
configure.
Bruno Haible wrote:
> Jim, it might be a good idea to do the same thing in
> coreutils/m4/jm-macros.m4.
Thanks. I've just done this:
>From 2a8f5104cd4ee76dad4b803f04ec327e5199bcf8 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Wed, 21 Jan 2009 14:48:15 +0100
Subject: [PATCH] m4: don't use
Bruno Haible wrote:
> Here's a proposed patch to improve c_strtod's error checking:
> 1) It currently does not check against a NULL return from newlocale(),
>which can happen for example if out of memory.
> 2) When strtod_l or strtod returns an error, c_strtod fails to preserve
>errno as a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gary V. Vaughan on 1/21/2009 1:30 AM:
Hi Gary, and thanks for the detailed reports. We may want to subdivide
replies into one email per topic, but for now, here's a bulk response:
> i686-redhat-linux9-gcc322 m4 tests pass, gnulib fa
Bruno Haible wrote:
> getloadavg uses c_strtod, but does not completely chcek against all error
> conditions (such as EINVAL or ENOMEM). Here's a proposed patch to that effect.
>
> The strtod documentation in POSIX says:
> "Since 0 is returned on error and is also a valid return on success, an
>
Hi Eric,
Thanks for working on this, and giving me time to run some tests :)
2009/1/17 Eric Blake :
> I obviously missed releasing GNU M4 1.4.13 by the end of 2008, but maybe
> I'll make January. Gnulib has had some improvements to fix bugs reported
> on the last snapshot, but also introduced so
> - locale_t c_locale = newlocale (LC_ALL_MASK, "C", 0);
> + locale_t c_locale;
> + int saved_errno;
> +
> + c_locale = newlocale (LC_ALL_MASK, "C", (locale_t)0);
Can we cache c_locale in a static variable?
Paolo
Hi Michael,
> fa_IR has a multi-byte monetary decimal point in glibc, but the regular
> ones are all "." or ",".
Yes. The monetary decimal point matters for strfmon(), but not for strtod().
> That locale also prints in Arabic-Indic
> numerals if you use the "I" printf flag, but these numerals a
Hi Jim,
getloadavg uses c_strtod, but does not completely chcek against all error
conditions (such as EINVAL or ENOMEM). Here's a proposed patch to that effect.
The strtod documentation in POSIX says:
"Since 0 is returned on error and is also a valid return on success, an
application wishing
Hi Jim,
Here's a proposed patch to improve c_strtod's error checking:
1) It currently does not check against a NULL return from newlocale(),
which can happen for example if out of memory.
2) When strtod_l or strtod returns an error, c_strtod fails to preserve
errno as an error indicator.
OK
21 matches
Mail list logo
