[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23261: 25.0.92; Undefined behavior in lib/stdint.h

From: Philipp Stephani
Subject: bug#23261: 25.0.92; Undefined behavior in lib/stdint.h
Date: Sun, 17 Apr 2016 13:48:10 +0000

Paul Eggert <address@hidden> 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:


I ran 'admin/merge-gnulib' to propagate the fix into emacs-25, and then
merged emacs-25 into master using the procedure described in

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]