Albert Chin wrote:
There is a -nodtk option to the commercial C
compiler which reverts to the system cc but that would need to be done
for _most_ gnulib-using programs, something that is not desirable.
Why is this not desirable? -nodtk has already been found to be the
preferred workaround
Eric Blake wrote:
I find glibc's output more sensible, since strtod will accept it, while
strtod will not grok 000inf. But FreeBSD appears to be closer to
the POSIX wording, I won't count it as a FreeBSD bug.
I would, though. POSIX allows inf vs. infinity, but unless %010f
prints
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 4/5/2007 5:14 AM:
Eric Blake wrote:
I find glibc's output more sensible, since strtod will accept it, while
strtod will not grok 000inf. But FreeBSD appears to be closer to
the POSIX wording, I won't count it as a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 4/5/2007 5:22 AM:
Albert Chin wrote:
There is a -nodtk option to the commercial C
compiler which reverts to the system cc but that would need to be done
for _most_ gnulib-using programs, something that is not
Ralf Wildenhues [EMAIL PROTECTED] writes:
join perhaps; it's quite stable so long as you run it in the C locale
and stick to the old features. cut I'm not so sure about; it's kind
of persnickety.
What exactly does the word persnickety mean here, and in which way is
cut that way?
'cut'
* Paul Eggert wrote on Thu, Apr 05, 2007 at 06:19:16PM CEST:
Ralf Wildenhues [EMAIL PROTECTED] writes:
fold, split, join, cut, paste
'split' and 'join' are traditional and portable. 'fold', 'cut', and
'paste' are relative newcomers, as they were not part of Unix Version 7
and (if I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Paul Eggert on 4/5/2007 10:07 AM:
- int check_WINT: WINT_MIN = 0 0 WINT_MAX ? 1 : -1;
+ int check_WINT: WINT_MIN = (wint_t) 0 (wint_t) 0 WINT_MAX ? 1 : -1;
This fix looks suspicious to me, as I think it might cause the test to
Eric Blake wrote:
That's now three reasons why I think FreeBSD's behavior is wrong.
OK, let's summarize (in case you want to bring it to the Austin group):
Arguments in favour ofnan,inf:
- For NaN, there is no indication of a sign or base; for Inf, there is
no indication
Ralf Wildenhues [EMAIL PROTECTED] writes:
So I gather that `fold', `cut', and `paste' stand no chance of ending up
listed in make-stds.texi?
I'm not the one making that decision, but I suspect the probability is
low, yes, unless there's a stronger case than I've heard so far.
I sense a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 3/14/2007 7:16 AM:
Revisiting this thread with a new question, and adding bug-gnulib to cc...
When using %a and %A, is it worth tightening the specification to require
the leading hex digit be smaller than FLT_RADIX
On Thu, 05 Apr 2007 18:30:06 -0600, Eric Blake wrote:
However, he also raised the question as to whether %010f and %010a are
supposed to outputinf (glibc does this) or 000inf (FreeBSD
does this). Personally, I think that FreeBSD has a bug in this regard,
C99+TC1+TC2: 7.19.6.1 The
Paul Eggert wrote:
How about this instead? It seems like a more-complete check.
int check_WINT: (((wint_t) -1 0
? WINT_MIN + WINT_MAX - 1 0
: WINT_MIN == 0 WINT_MAX == (wint_t) -1)
? 1 : -1);
The checks in the autoconf
On 5 Apr 2007, at 17:43, Paul Eggert wrote:
One dumb question:
Does the Tru64 compiler define __GNUC__, or some other similar symbol?
No, it doesn't.
For the case of overriding standard headers I am thinking that this
concern might be overdone. If someone installs a gnulib-generated
13 matches
Mail list logo
