bug-gnu-emacs
[Top][All Lists]
Advanced

[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:

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.

reply via email to

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