* bug#23261: 25.0.92; Undefined behavior in lib/stdint.h
@ 2016-04-10 13:51 Philipp Stephani
2016-04-10 15:05 ` Eli Zaretskii
2016-04-11 7:23 ` Paul Eggert
0 siblings, 2 replies; 6+ messages in thread
From: Philipp Stephani @ 2016-04-10 13:51 UTC (permalink / raw)
To: 23261
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))
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#23261: 25.0.92; Undefined behavior in lib/stdint.h
2016-04-10 13:51 bug#23261: 25.0.92; Undefined behavior in lib/stdint.h Philipp Stephani
@ 2016-04-10 15:05 ` Eli Zaretskii
2016-04-11 7:23 ` Paul Eggert
1 sibling, 0 replies; 6+ messages in thread
From: Eli Zaretskii @ 2016-04-10 15:05 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 23261
> From: Philipp Stephani <p.stephani2@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#23261: 25.0.92; Undefined behavior in lib/stdint.h
2016-04-10 13:51 bug#23261: 25.0.92; Undefined behavior in lib/stdint.h Philipp Stephani
2016-04-10 15:05 ` Eli Zaretskii
@ 2016-04-11 7:23 ` Paul Eggert
2016-04-11 16:17 ` Paul Eggert
1 sibling, 1 reply; 6+ messages in thread
From: Paul Eggert @ 2016-04-11 7:23 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 23261
> 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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#23261: 25.0.92; Undefined behavior in lib/stdint.h
2016-04-11 7:23 ` Paul Eggert
@ 2016-04-11 16:17 ` Paul Eggert
2016-04-17 13:48 ` Philipp Stephani
0 siblings, 1 reply; 6+ messages in thread
From: Paul Eggert @ 2016-04-11 16:17 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 23261
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#23261: 25.0.92; Undefined behavior in lib/stdint.h
2016-04-11 16:17 ` Paul Eggert
@ 2016-04-17 13:48 ` Philipp Stephani
2016-04-18 4:30 ` Paul Eggert
0 siblings, 1 reply; 6+ messages in thread
From: Philipp Stephani @ 2016-04-17 13:48 UTC (permalink / raw)
To: Paul Eggert; +Cc: 23261
[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2215 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#23261: 25.0.92; Undefined behavior in lib/stdint.h
2016-04-17 13:48 ` Philipp Stephani
@ 2016-04-18 4:30 ` Paul Eggert
0 siblings, 0 replies; 6+ messages in thread
From: Paul Eggert @ 2016-04-18 4:30 UTC (permalink / raw)
To: Philipp Stephani; +Cc: 23261
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-04-18 4:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-04-10 13:51 bug#23261: 25.0.92; Undefined behavior in lib/stdint.h Philipp Stephani
2016-04-10 15:05 ` Eli Zaretskii
2016-04-11 7:23 ` Paul Eggert
2016-04-11 16:17 ` Paul Eggert
2016-04-17 13:48 ` Philipp Stephani
2016-04-18 4:30 ` Paul Eggert
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.