Paul Eggert wrote:
> It seems a bit cleaner to me to have
> the inttypes module be the only module that needs to figure out
> the absolute name of .
Maybe a bit cleaner, but also a little more complex... But I don't mind.
Both codes look equally safe.
Bruno
Paul Eggert wrote:
> Bootstrapping coreutils found one minor glitch: inttypes now relies on
> gl_HEADER_INTTYPES_H indirectly via gt_INTTYPES_PRI but doesn't list
> the file containing it.
Thanks for noticing it! It was certainly not intended. I'll clean it up.
> While we're on the subject we sho
Bruno Haible clisp.org> writes:
> --- gnulib-20060823-modified/m4/inttypes.m4 2006-07-27 03:12:58.0
+0200
...
> + #ifdef INT32_MAX
> + PRId32 PRIi32
> + #endif
> + #ifdef UINT32_MAX
> + PRIo32 PRIu32 PRIx32 PRIX32
> + #ifdef INT64_MAX
> + PRId64 PRIi64
> + #endif
Oops - missing
Bruno Haible <[EMAIL PROTECTED]> writes:
> If our replacement includes simply , not
> @ABSOLUTE_INTTYPES_H@, then a simple
> #include
> will do the wrong thing: It will
>
>- start including our stdint.h,
>- include the system's stdint.h,
>- start including our inttypes.h,
>
Thanks for doing that.
Bootstrapping coreutils found one minor glitch: inttypes now relies on
gl_HEADER_INTTYPES_H indirectly via gt_INTTYPES_PRI but doesn't list
the file containing it. I installed the following obvious patch.
While we're on the subject we should remove gl_HEADER_INTTYPES_H.
Au
Eric Blake wrote:
> One more issue - when the replacement is needed,
> inttypes-pri.m4 AC_SUBST's PRI_MACROS_BROKEN as the empty string when they
> work, rather than defining it to 0; which resulted in lots of preprocessor
> compilation errors:
>
> make[2]: Entering directory `/home/eblake/tar/
Bruno Haible clisp.org> writes:
> Oops. I missed the fact that the PRI* and SCN* macros are not symmetric.
> SCNX* makes no sense (as you can parse hexadecimal numbers without knowing
> in advance whether to look for uppercase or lowercase hexadecimal digits).
> I remove the SCNX* from the inttyp
Eric Blake wrote:
> Cygwin is currently failing the inttypes check because it does not provide
> SCNX8, among others. POSIX does not require the existence of SCNX*, so
> cygwin
> does not provide them.
Oops. I missed the fact that the PRI* and SCN* macros are not symmetric.
SCNX* makes no sens
Bruno Haible clisp.org> writes:
> --- gnulib-20060823-modified/m4/inttypes.m4 2006-07-27 03:12:58.0
+0200
...
> + const char *l = /* implicit string concatenation */
> + #ifdef INT8_MAX
> + SCNd8 SCNi8
> + #endif
> + #ifdef UINT8_MAX
> + SCNo8 SCNu8 SCNx8 SCNX8
Cygwin is currently
Bruno Haible clisp.org> writes:
>
> So here's the patch I'm committing.
>
> 2006-08-26 Bruno Haible clisp.org>
>
> * modules/inttypes (Files): Add lib/inttypes_.h, remove lib/inttypes.h.
> Add m4/inttypes.m4, remove m4/_inttypes_h.m4 and m4/include_next.m4.
> (Makefile.am)
Paul Eggert wrote a month ago:
> I was worried about the case where an implementation provides a
> conforming stdint.h but not a conforming inttypes.h. Such an
> implementation might have 64-bit int. There are a few ILP64 hosts,
> e.g., GCC on MIPS with the -mint64 option. Currently, I suspect t
Bruno Haible <[EMAIL PROTECTED]> writes:
> Here, as well as in many other places (including 'stdint'), we assume that
> int and int32_t are the same. I don't wish to add more #ifdefs for cases
> that are hypothetical.
I was worried about the case where an implementation provides a
conforming stdi
Paul Eggert wrote:
> C99 says macro definitions like this should be skipped if C++, unless
> __STDC_FORMAT_MACROS is defined.
You're right. I missed this footnote in the standard.
> Also, the macro should be defined
> only if the corresponding type exists (this is relevant only on weird,
> perhap
Thanks very much for tackling this! It will
clean up quite a bit of code. Some comments:
Bruno Haible <[EMAIL PROTECTED]> writes:
> + #if !defined PRId8 || PRI_MACROS_BROKEN
> + # undef PRId8
> + # define PRId8 "d"
> + #endif
C99 says macro definitions like this should be skipped if C++, unles
14 matches
Mail list logo
