On 04/11/2016 12:23 AM, Paul Eggert wrote:
>
> I don't observe a problem with my clang installation (clang 3.7.0 on
> Fedora 23 x86-64).
I managed to reproduce the problem in Gnulib by artificially pretending
to 'configure' that clang's stdint.h was busted, using './configure
gl_cv_header_working_stdint_h=no'. I installed a fix for the problem
into Gnulib here:
http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=705764b377ebeef7bdba1a87fafd99cd56b6f3c9
I ran 'admin/merge-gnulib' to propagate the fix into emacs-25, and then
merged emacs-25 into master using the procedure described in
'admin/notes/git-workflow'.
Please give this a try on your setup.
Thanks, the relevant warning messages are now gone.
Do a 'make clean' before running
'make'. If 'make' is still building lib/stdint.h, please investigate why
'./configure' decides that clang's stdint.h is buggy.
Because I think there's an actual bug in stdint.h on OS X. UINT8_C(n) is required to expand to a constant that should be promoted to the same type that uint8_t(0) gets promoted to, which is int. However, on OS X, UINT8_C(n) expands to n##U, which gets promoted to unsigned int. By contrast, the definition in GCC 5.3 is just 'n'.
The question here is whether Gnulib should really redefine all macros if only a small subset (here: UINT8_C and UINT16_C) are incorrect.