Paul Eggert <eggert@cs.ucla.edu> schrieb am Mo., 11. Apr. 2016 um 18:18 Uhr:

> 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.