This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Add <limits.h> integer width macros
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, <libc-alpha at sourceware dot org>
- Date: Tue, 4 Oct 2016 15:51:12 +0000
- Subject: Re: Add <limits.h> integer width macros
- Authentication-results: sourceware.org; auth=none
- References: <alpine.DEB.2.20.1609131749040.9352@digraph.polyomino.org.uk> <2bbcd0d5-c2c2-d1ba-c685-e8eb49910970@cs.ucla.edu> <alpine.DEB.2.20.1609141956250.14953@digraph.polyomino.org.uk> <9b238824-7969-1a46-cc5f-ebc3c07db1d6@cs.ucla.edu> <82bfb295-b8d9-52b2-82d1-5a4c290ec34e@cs.ucla.edu> <f87e6b71-229d-e2d3-c1ac-45e9dd0f4e23@redhat.com>
On Tue, 4 Oct 2016, Florian Weimer wrote:
> On 10/04/2016 05:07 PM, Paul Eggert wrote:
> > On 09/16/2016 05:32 PM, Paul Eggert wrote:
> > > the patch looks good; thanks.
> >
> > Unfortunately I did not check the patch thoroughly enough, as the patch
> > turns out to define LONG_WIDTH incorrectly on i686 with
> > gcc-6.2.1-2.fc26.i686, and this causes grep's 'make check' to fail
> > (luckily these are side tests; grep itself works fine). See:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1381582
>
> See comment 5 there. The problem seems to be that GCC <limits.h> is included
> first, followed by glibc <limits.h>, which then tries to get the definitions
> from GCC. But at this point, nothing happens because the GCC include guards
> cause the GCC header to be skipped.
Presumably this is an area where include ordering with installed headers
differs from include ordering when building the glibc testsuite. Does
this patch work in the installed header context to fix the reported issue?
(I'm running tests of it in the normal glibc testsuite context.)
Fix LONG_WIDTH, ULONG_WIDTH include ordering issue.
As described in
<https://sourceware.org/ml/libc-alpha/2016-10/msg00047.html>, there is
an include ordering issue with the integer width macros in glibc's
<limits.h>, where definitions conditional on LONG_MAX do not work as
intended because when the headers are installed, this part of glibc's
<limits.h> is processed before the part of GCC's <limits.h> that will
define LONG_MAX. This patch changes the definitions just to use
__WORDSIZE for the expansion of LONG_WIDTH and ULONG_WIDTH rather than
making those definitions conditional on LONG_MAX.
2016-10-04 Joseph Myers <joseph@codesourcery.com>
* include/limits.h [__GLIBC_USE (IEC_60559_BFP_EXT)] (LONG_WIDTH):
Define to __WORDSIZE, not conditional on [LONG_MAX ==
0x7fffffffL].
[__GLIBC_USE (IEC_60559_BFP_EXT)] (ULONG_WIDTH): Likewise.
diff --git a/include/limits.h b/include/limits.h
index 93cac49..dd601d5 100644
--- a/include/limits.h
+++ b/include/limits.h
@@ -164,20 +164,11 @@
# ifndef UINT_WIDTH
# define UINT_WIDTH 32
# endif
-# if LONG_MAX == 0x7fffffffL
-# ifndef LONG_WIDTH
-# define LONG_WIDTH 32
-# endif
-# ifndef ULONG_WIDTH
-# define ULONG_WIDTH 32
-# endif
-# else
-# ifndef LONG_WIDTH
-# define LONG_WIDTH 64
-# endif
-# ifndef ULONG_WIDTH
-# define ULONG_WIDTH 64
-# endif
+# ifndef LONG_WIDTH
+# define LONG_WIDTH __WORDSIZE
+# endif
+# ifndef ULONG_WIDTH
+# define ULONG_WIDTH __WORDSIZE
# endif
# ifndef LLONG_WIDTH
# define LLONG_WIDTH 64
--
Joseph S. Myers
joseph@codesourcery.com