Re: rethinking #if and 64-bit numbers (inttypes.h on Sun platforms)

Bruno Haible <[EMAIL PROTECTED]> writes: > Can you document this limitation in doc/headers/stdint.texi please? > Possibly also in autoconf.texi section "Portable C and C++ Programming"? I did the former by installing the following. I'll look at the latter next. 2007-11-12 Paul Eggert <[EMAIL P

Re: config.charset support for OpenBSD

Bruno Haible <[EMAIL PROTECTED]> writes: > Who says that OpenBSD 4.2 does not have more locales than NetBSD 3.0? I cannot make this claim, because I know little about either one. >> It's really not clear to me what the canonical source of >> config.charset is; mine comes from gnulib. > > config.

Re: rethinking #if and 64-bit numbers (inttypes.h on Sun platforms)

Hi Paul, > The Solaris compiler has a buggy > preprocessor which misevaluates "#if -9223372036854775807LL < 0", I > suspect because it treats the constant as being unsigned. Based on the results from [1] I guess the preprocessor looks for the sign in bit 31 instead of in bit 63. > I considered w

Re: config.charset support for OpenBSD

Ben Pfaff wrote in : > Thus, the following patch against config.charset seems > appropriate: > > --- config.charset~ 2007-11-04 13:03:10.0 -0800 > +++ config.charset 2007-11-10 11:16:07.0 -0800 > @@ -3

rethinking #if and 64-bit numbers (inttypes.h on Sun platforms)

Coreutils 'nl' dumps core on 32-bit Solaris sparc due to a mismatch between types and formats. The Solaris compiler has a buggy preprocessor which misevaluates "#if -9223372036854775807LL < 0", I suspect because it treats the constant as being unsigned. This causes 'configure' to decide that 'lon

Unicode character classification functions

Here comes the sixth part of the Unicode string library: classification functions for Unicode characters. This includes functions for category, properties, scripts, blocks, etc., and extrapolations of the 12 functions from . 2007-11-12 Bruno Haible <[EMAIL PROTECTED]> Unicode character

Re: new module 'gperf'

Benoit Sigoure wrote: > > gllib/Makefile.am:579: GPERF multiply defined in condition TRUE ... > > gllib/Makefile.am:548: ... `GPERF' previously defined here > ... > Do you think it would be an improvement if automake did not complain > because it could be clever enough to detect that even though

Re: new module 'gperf'

On Nov 12, 2007, at 1:39 AM, Bruno Haible wrote: Hi, When several modules have the same line GPERF = gperf in their module description, automake complains like this: gllib/Makefile.am:579: GPERF multiply defined in condition TRUE ... gllib/Makefile.am:548: ... `GPERF' previously defined