Re: stdint_.h vs intmax_t & uintmax_t

"Mark D. Baushke" <[EMAIL PROTECTED]> writes: > There is one remaining interaction with stdint_.h and config.h > which arises from m4/size_max.m4 > > % grep SIZE_MAX config.h > config.h:#define SIZE_MAX 4294967295U > % grep lib/stdint_.h > #define SIZE_MAX (~(size_t)0) Thanks for mentioning that

Re: stdint_.h vs intmax_t & uintmax_t

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Eggert <[EMAIL PROTECTED]> writes: > Does the following (untested) patch fix things for you? Yes. Thank you. > 2005-11-14 Paul Eggert <[EMAIL PROTECTED]> > > * lib/stdint_.h (intmax_t) [defined intmax_t]: Do not declare. > (uintm

Re: stdint_.h vs intmax_t & uintmax_t

Does the following (untested) patch fix things for you? 2005-11-14 Paul Eggert <[EMAIL PROTECTED]> * lib/stdint_.h (intmax_t) [defined intmax_t]: Do not declare. (uintmax_t) [defined uintmax_t]: Do not declare. This works around a problem if intmax_t.m4 and/or uintmax_t.

stdint_.h vs intmax_t & uintmax_t

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have run into a quirk of GNULIB building CVS on a FreeBSD 4.2 host. It seems that CVS is using m4/intmax.m4 which generate these lines into the config.h file: /* Define if you have the 'uintmax_t' type in or . */ /* The size of a `intmax_t', as co

Re: Maintenance of config.rpath and lib-link.m4

Hrvoje Niksic <[EMAIL PROTECTED]> writes: > Which is the correct address to report bugs in config.rpath and > lib-link.m4 and the related library currently shipped with gettext? > Some weeks ago I reported a problem with static linking, >

Re: mkstemp-safer.c must include

Jim Meyering <[EMAIL PROTECTED]> wrote: > The problem is that on systems for which m4/mkstemp.c > would normally make an application use the replacement > function, an application calling mkstemp_safer would end up > using the buggy version, because mkstemp-safer.c didn't > include (for the mkstem