Re: support for bitwise comparison of floats

Eric Blake wrote: > You can also assume IEEE rules, and compare against signed infinity: > 1 / +0. => +infinity > 1 / -0. => -infinity Nice trick :-) But here you depend on the IEEE rules for exceptions upon division by zero. - On Alpha processors, division by zero (and even overflow!) leads to

Re: gnulib support for st_birthtime

On 3/25/07, Bruno Haible <[EMAIL PROTECTED]> wrote: This is Paul's domain; nevertheless I'd like to mention that native Woe32 platforms (mingw, msvc, but not Cygwin) implementation of stat() and fstat() store the "file creation time" in st_ctime. This is even documented on msdn.microsoft.com. The

Re: support for bitwise comparison of floats

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 3/25/2007 4:54 AM: > Eric Blake wrote: >> You can also assume IEEE rules, and compare against signed infinity: >> 1 / +0. => +infinity >> 1 / -0. => -infinity > > Nice trick :-) Thanks for correcting my typo; which I real

Re: add limited support for Solaris 10 ZFS-style ACLs to gnulib

Paul Eggert wrote: > Index: lib/acl-internal.h > === > RCS file: lib/acl-internal.h > diff -N lib/acl-internal.h > --- /dev/null 1 Jan 1970 00:00:00 - > +++ lib/acl-internal.h19 Mar 2007 21:58:54 - > @@ -0,0 +1,90 @@ ..

Re: support for bitwise comparison of floats

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 3/25/2007 4:54 AM: > Eric Blake wrote: >> You can also assume IEEE rules, and compare against signed infinity: >> 1 / +0. => +infinity >> 1 / -0. => -infinity > > Nice trick :-) > > But here you depend on the IEEE rules f

Re: support for bitwise comparison of floats

PS: I wrote: > - On Alpha processors, division by zero (and even overflow!) leads to a > SIGFPE > signal by default. And it requires the use of a system call to change > the FP exceptions control mask (the routines in glibc >= 2.1, > the __setfpucw function in glibc 2.0). memcmp is

time: invalid Makefile syntax

Hi, When editing a gnulib generated Makefile, emacs told me about "suspicious lines". Action lines should start with a tab, not a space. I'm applying this: 2007-03-25 Bruno Haible <[EMAIL PROTECTED]> * modules/time (Makefile.am): Ensure all rule action lines start with a tab.

Re: support for bitwise comparison of floats

Eric Blake wrote: > Is this any more portable, by avoiding floating point division altogether? > > /* return true iff the representation of d needs a leading '-' */ > bool > is_negative (long double d) > { > if (d == 0) > { > union { > long double d; > long l; > }

Re: gnulib support for st_birthtime

James Youngman wrote: > this is a change which I cannot test since I > have no Woe32 system. I will push the change into findutils (instead > of using it indirectly in gnulib) and test it there for a bit. On the contrary, pushing the change into gnulib will make testing easier: If you provide a u

argp: fix __restrict for older compilers

On BeOS, which has a gcc compiler older than 2.95, one gets syntax errors in gnulib's due to 'restrict'. The reason is that - configure does a "#define restrict __restrict", since gcc supports that keyword. - argp.h does "#define __restrict restrict", since it sees that 'restrict' is d

warning in sincosl.c

Hi Paolo, On Solaris 10 with "cc", I get this warning: "./sincosl.c", line 233: warning: identifier redeclared; ANSI C requires "static": sincosl_table and on HP-UX 11 with "cc": cc: "sincosl.c", line 233: warning 562: Redeclaration of "sincosl_table" with a different storage class specifier:

trigl.c warning

HP-UX cc gives this warning: cc: "trigl.c", line 427: warning 562: Redeclaration of "kernel_rem_pio2" with a different storage class specifier: "kernel_rem_pio2" will have internal linkage. I'm applying this fix. 2007-03-25 Bruno Haible <[EMAIL PROTECTED]> * lib/trigl.c (kernel_rem_p

lib/regexec.c warning

HP-UX cc gives this warning: cc: "regexec.c", line 2343: warning 562: Redeclaration of "merge_state_with_log" with a different storage class specifier: "merge_state_with_log" will have internal linkage. This fixes it. I hope this patch is not too hard to push back to glibc, Paul? 2007-03-25

glob: fix warnings on AIX

On AIX 5.1, the compiler shows these warnings: "glob.c", line 666.47: 1506-280 (E) Function argument assignment between types "struct stat*" and "struct stat64*" is not allowed. "glob.c", line 1016.42: 1506-280 (E) Function argument assignment between types "struct stat*" and "struct stat64*" is

isnan: work around a DEC C compiler bug

The DEC C 6.4 compiler on Tru64 fails with an error message when it encounters the expression 0.0 / 0.0, even in a context where no constant expression is required. Strangely enough, it groks 0.0L / 0.0L with just a warning. Here is a workaround: 2007-03-25 Bruno Haible <[EMAIL PROTECTED]>

EX_OK collision

Warning seen on IRIX 6.5: "///usr/include/unistd.h", line 43: warning(1047): macro redefined differently IRIX 6.5 has two definitions of EX_OK: - one in , protected with "#if _SGIAPI", as a flag that can be passed to the access() function, with value 020, - one in , always active, as an e

[Bug-gne] Dewitt Symantec site

Autodesk AutoCAD 2007Retail Price $3995.00Our Price $129.95You save $3865.05 Adobe Creative Suite 2 Premium for WindowsRetail Price $1199.00Our Price $149.95You save $1049.05 CorelDraw Graphics Suite X3Retail Price $399.00Our Price $59.95You save $339.05 Macromedia Studio 8Retail Price $999.00Our

mathl and NaN

Hi Paolo, The mathl module uses the idiom x != x to test for a NaN. The IRIX 6.5 cc compiler, however, simplifies this expression to false, both for 'double' and 'long double' variables. The two workarounds that I found are: - Use the isnanl function, - Copy one of the operands into a 'volat

frexp: avoid bug on IRIX

frexp(Infinity) on IRIX 6.5 does not return Infinity, as it should according to POSIX/MX. I'm adding a configure check against it: 2007-03-25 Bruno Haible <[EMAIL PROTECTED]> * m4/frexp.m4 (gl_FUNC_FREXP_WORKS): Add check whether frexp(inf) returns inf. Needed on IRIX 6.5. ***

frexpl: avoid bug on IRIX

frexpl(Infinity) on IRIX 6.5 does not return Infinity, as it should according to POSIX/MX. I'm adding a configure check against it: 2007-03-25 Bruno Haible <[EMAIL PROTECTED]> * m4/frexpl.m4 (gl_FUNC_FREXPL_WORKS): New macro. (gl_FUNC_FREXPL): Invoke it. Set REPLACE_FREXPL to 1

getaddrinfo: fix crash on IRIX

Hi Simon, On IRIX 6.5, the replacement getaddrinfo is used, and since the testsuite exercises calling it will a hints = NULL pointer, it crashes in line 182. Here is a proposed patch. 2007-03-25 Bruno Haible <[EMAIL PROTECTED]> * lib/getaddrinfo.c (getaddrinfo): Don't access hints->a

Re: support for bitwise comparison of floats

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 3/25/2007 9:57 AM: > Eric Blake wrote: >> Is this any more portable, by avoiding floating point division altogether? >> >> /* return true iff the representation of d needs a leading '-' */ >> bool >> is_negative (long doubl

getaddrinfo: test failures

Hi Simon, The getaddrinfo test fails on most machines I tried. But since I am not a networking expert, and don't know how getaddrinfo is supposed to work, its output is chinese to me. For example I don't know whether it's ok or not if https://www.ibm.com cannot be looked up. Can you go through th

frexpl: avoid bug on AIX

The function frexpl() on AIX doesn't return reasonable values at all. It has to be disabled in a configure test. I'm applying this: 2007-03-25 Bruno Haible <[EMAIL PROTECTED]> * m4/frexpl.m4 (gl_FUNC_FREXPL_WORKS): Test also finite numbers. *** m4/frexpl.m425 Mar 2007 21:35:38

Re: support for bitwise comparison of floats

Eric Blake <[EMAIL PROTECTED]> writes: > According to Bruno Haible on 3/25/2007 9:57 AM: >> Eric Blake wrote: >>> /* return true iff the representation of d needs a leading '-' */ >>> bool >>> is_negative (long double d) >>> { >>> if (d == 0) >>> { >>> union { >>> long double d

Re: EX_OK collision

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 3/25/2007 2:22 PM: > Warning seen on IRIX 6.5: > > "///usr/include/unistd.h", line 43: warning(1047): macro redefined differently > > IRIX 6.5 has two definitions of EX_OK: > - one in , protected with "#if _SGIAPI", as

Re: support for bitwise comparison of floats

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 3/24/2007 7:04 PM: > > 2007-03-24 Bruno Haible <[EMAIL PROTECTED]> > > * lib/float+.h: New file. Is + a reasonable file name character these days? On the one hand, it is not listed in the "portable filename char

sysexits: test failure on HP-UX

The sysexits test that I wrote verifies that all values from EX_OK to EX_CONFIG are present and have distinct values. This fails on HP-UX. It has a file which contains only te values up to EX_NOPERM. The values are the same, though (at least :-)). Here is a proposed patch to extend the HP-UX wi

Re: support for bitwise comparison of floats

Eric Blake wrote: > recent coreutils snapshots have used it, and no one has complained so far. Plenty of packages have used it for 10 years or longer: GCC installs or installed files in $prefix/include/g++, and a library called libstdc++. binutils has a program called 'c++filt'. gettext is using a

Re: add limited support for Solaris 10 ZFS-style ACLs to gnulib

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 3/25/2007 8:24 AM: > Paul Eggert wrote: >> Index: lib/acl-internal.h >> === >> RCS file: lib/acl-internal.h >> diff -N lib/acl-internal.h >> --- /dev/null

Re: support for bitwise comparison of floats

Clarification: > > - On Alpha processors, division by zero (and even overflow!) leads to a > > SIGFPE > > signal by default. And it requires the use of a system call to change > > the FP exceptions control mask (the routines in glibc >= 2.1, > > the __setfpucw function in glibc 2.0

new module 'fpieee'

The code needed for isnan() needs to construct a NaN or Inf object. But doing so leads to a SIGFPE by default on Alpha systems. There's only one way to get IEEE compliant behaviour of elementary arithmetic operations on this platform: instruct the compiler to emit different (more expensive) floatin

Re: new module 'fpieee'

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 3/25/2007 5:59 PM: > alpha*) > # On Alpha systems, a compiler option provides the behaviour. > # See the ieee(3) manual page, also available at > # >

Re: new module 'fpieee'

Bruno Haible <[EMAIL PROTECTED]> writes: > The code needed for isnan() needs to construct a NaN or Inf object. But > doing so leads to a SIGFPE by default on Alpha systems. There's only one > way to get IEEE compliant behaviour of elementary arithmetic operations on > this platform: instruct the c

vasnprintf: support %jd on all platforms

So far, vasnprintf had support for the 'j' size specifier only on platforms which have intmax_t. OSF/1 5.1 is a platform which doesn't have intmax_t and where the intmax_t comes from gnulib's or from gettext's intmax_t.m4. The testsuite caught it. This patch should fix it. 2007-03-25 Bruno Haibl

Re: new module 'fpieee'

Ben Pfaff wrote: > Is this also necessary on SH systems? The GCC manual has this in > the page specific to SH: > > `-mieee' > Increase IEEE-compliance of floating-point code. At the moment, > this is equivalent to `-fno-finite-math-only'. When generating 16 > bit

Re: use of thread-unsafe localeconv in vasprintf

After testing on a few platforms, I applied this patch now. 2007-03-25 Bruno Haible <[EMAIL PROTECTED]> * lib/vasnprintf.c: Include langinfo.h. (VASNPRINTF): Prefer nl_langinfo over localeconv, since it's more multithread-safe. * m4/vasnprintf.m4 (gl_PREREQ_VASNP

Re: mathl and NaN

> So, your opinion about the following patch? Ok; at the time i wrote mathl, there was (as you know) no isnanl package. I think ==, !=, isordered, isunordered comparisons are the sole operations you can safely perform on a SNaN. Paolo

Re: use of thread-unsafe localeconv in vasprintf

Hello Bruno, * Bruno Haible wrote on Mon, Mar 26, 2007 at 04:18:35AM CEST: > After testing on a few platforms, I applied this patch now. > > 2007-03-25 Bruno Haible <[EMAIL PROTECTED]> > > * lib/vasnprintf.c: Include langinfo.h. > (VASNPRINTF): Prefer nl_langinfo over localeconv, si