GNU bug report logs - #23261
25.0.92; Undefined behavior in lib/stdint.h

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 23261 in the body.
You can then email your comments to 23261 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.92; Undefined behavior in lib/stdint.h
Date: Sun, 10 Apr 2016 15:51:31 +0200

Clang finds the following undefined behavior in lib/stdint.h:

./lisp.h:3705:3: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
  XSETPVECTYPE (XVECTOR (v), PVEC_SUB_CHAR_TABLE);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./lisp.h:1124:24: note: expanded from macro 'XSETPVECTYPE'
  ((v)->header.size |= PSEUDOVECTOR_FLAG | ((code) << PSEUDOVECTOR_AREA_BITS))
                       ^~~~~~~~~~~~~~~~~
./lisp.h:763:43: note: expanded from macro 'PSEUDOVECTOR_FLAG'
# define PSEUDOVECTOR_FLAG (PTRDIFF_MAX - PTRDIFF_MAX / 2)
                                          ^~~~~~~~~~~
../lib/stdint.h:520:5: note: expanded from macro 'PTRDIFF_MAX'
    _STDINT_MAX (1, 64, 0l)
    ^~~~~~~~~~~~~~~~~~~~~~~
../lib/stdint.h:126:8: note: expanded from macro '_STDINT_MAX'
   ? ~ _STDINT_MIN (signed, bits, zero) \
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../lib/stdint.h:122:31: note: expanded from macro '_STDINT_MIN'
  ((signed) ? (- ((zero) + 1) << ((bits) ? (bits) - 1 : 0)) : (zero))
               ~~~~~~~~~~~~~~ ^

Could we maybe just remove stdint.h completely?  It should always be
provided by the standard C library.



In GNU Emacs 25.0.92.3 (x86_64-apple-darwin15.4.0, NS appkit-1404.46 Version 10.11.4 (Build 15E65))
 of 2016-04-10 built on p
Repository revision: c8b868b1e2532aa07dbf4959798dbdc52ea9b5d5
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
 'configure --without-xml2 --with-modules'

Configured features:
RSVG IMAGEMAGICK DBUS NOTIFY ACL GNUTLS ZLIB TOOLKIT_SCROLL_BARS NS
MODULES

Important settings:
  value of $LANG: de_DE.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel ns-win ucs-normalize term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind kqueue cocoa ns multi-tty
make-network-process emacs)

Memory information:
((conses 16 196096 6054)
 (symbols 48 19783 0)
 (miscs 40 43 131)
 (strings 32 15118 5931)
 (string-bytes 1 441818)
 (vectors 16 32893)
 (vector-slots 8 652477 6669)
 (floats 8 162 19)
 (intervals 56 196 0)
 (buffers 976 11))

Message #8 received at 23261 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 23261 <at> debbugs.gnu.org
Subject: Re: bug#23261: 25.0.92; Undefined behavior in lib/stdint.h
Date: Sun, 10 Apr 2016 18:05:46 +0300

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Sun, 10 Apr 2016 15:51:31 +0200
> 
> Could we maybe just remove stdint.h completely?  It should always be
> provided by the standard C library.

If you have lib/stdint.h, it means the configure script found the one
that came with your library deficient in some sense; look in
config.log to see why.  E.g., on my system lib/stdint.h is not
generated and not used.

Message #11 received at 23261 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 23261 <at> debbugs.gnu.org
Subject: Re: 25.0.92; Undefined behavior in lib/stdint.h
Date: Mon, 11 Apr 2016 00:23:15 -0700

> Could we maybe just remove stdint.h completely?  It should always be
> provided by the standard C library.

Unfortunately stdint.h is not portable in practice, as many C implementations 
don't conform to C11 or even to C99. It sounds like your platform has a problem 
in this area. Emacs provides a replacement stdint.h on platforms that don't 
conform to the standards.

I don't observe a problem with my clang installation (clang 3.7.0 on Fedora 23 
x86-64). I configured with './configure CC=clang', and on my platform the system 
stdint.h was fine so lib/stdint.h was not created. Perhaps you could look in 
your config.log near the strings "checking whether stdint.h ..." and see why 
your clang has problems with its stdint.h, and debug what went wrong. Another 
possibility is to futz with your CFLAGS to cajole clang into not issuing the 
bogus warning. Yet another possibility is to switch to GCC.

Message #14 received at 23261 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 23261 <at> debbugs.gnu.org
Subject: Re: 25.0.92; Undefined behavior in lib/stdint.h
Date: Mon, 11 Apr 2016 09:17:23 -0700

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

Message #17 received at 23261 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 23261 <at> debbugs.gnu.org
Subject: Re: bug#23261: 25.0.92; Undefined behavior in lib/stdint.h
Date: Sun, 17 Apr 2016 13:48:10 +0000

[Message part 1 (text/plain, inline)]

Paul Eggert <eggert <at> 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.

[Message part 2 (text/html, inline)]

Message #22 received at 23261 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 23261 <at> debbugs.gnu.org
Subject: Re: bug#23261: 25.0.92; Undefined behavior in lib/stdint.h
Date: Sun, 17 Apr 2016 21:30:22 -0700

Philipp Stephani wrote:
> The question here is whether Gnulib should really redefine all macros if
> only a small subset (here: UINT8_C and UINT16_C) are incorrect.

Why not, as long as Gnulib does so correctly?

Platforms that are buggy in one part of stdint.h tend to be buggy in others, and 
I'd rather not waste maintenance effort worrying about individual stdint.h bugs.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.