GNU bug report logs -
#7928
mktime test in configure: UB resulting in infinite loop
Previous Next
Reported by: Rich Felker <dalias <at> aerifal.cx>
Date: Thu, 27 Jan 2011 06:44:02 UTC
Severity: normal
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7928 in the body.
You can then email your comments to 7928 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Thu, 27 Jan 2011 06:44:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Rich Felker <dalias <at> aerifal.cx>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Thu, 27 Jan 2011 06:44:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The configure test for mktime (m4/mktime.m4) contains the following
code:
for (;;)
{
t = (time_t_max << 1) + 1;
if (t <= time_t_max)
break;
time_t_max = t;
}
This code has undefined behavior on signed integer overflow; at least
some versions of gcc, and any sane compiler, will optimize out the
exit condition since algebraically 2x+1>x for any nonnegative x. The
result is an infinite loop and failure of the test after the 60-second
timeout.
Finding the max possible value for a signed integer type is actually a
very hard problem in C. As far as I know it's impossible at
compile-time and might even be impossible at runtime unless you make
some assumptions (either the absence of padding bits, or the
well-definedness of converting larger/unsigned types to signed types).
The approach I would take is just:
time_t_max = (time_t)1 << 8*sizeof(time_t)-2;
If this test comes from higher-up (gnulib?) please forward my bug
report to the relevant upstream.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Thu, 27 Jan 2011 15:07:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 7928 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[adding bug-gnulib, as requested]
On 01/26/2011 10:21 PM, Rich Felker wrote:
> The configure test for mktime (m4/mktime.m4) contains the following
> code:
>
> for (;;)
> {
> t = (time_t_max << 1) + 1;
> if (t <= time_t_max)
> break;
> time_t_max = t;
> }
>
> This code has undefined behavior on signed integer overflow; at least
> some versions of gcc, and any sane compiler, will optimize out the
> exit condition since algebraically 2x+1>x for any nonnegative x. The
> result is an infinite loop and failure of the test after the 60-second
> timeout.
Thanks for the report.
> Finding the max possible value for a signed integer type is actually a
> very hard problem in C. As far as I know it's impossible at
> compile-time and might even be impossible at runtime unless you make
> some assumptions (either the absence of padding bits, or the
> well-definedness of converting larger/unsigned types to signed types).
Agreed that padding bits make it impossible - but in reality, how many
porting targets have such a signed type? Here's what we do in gnulib's
"intprops.h" for a compile-time designation that's accurate for every
integer type on every platform that gnulib targets:
/* True if negative values of the signed integer type T use two's
complement, ones' complement, or signed magnitude representation,
respectively. Much GNU code assumes two's complement, but some
people like to be portable to all possible C hosts. */
# define TYPE_TWOS_COMPLEMENT(t) ((t) ~ (t) 0 == (t) -1)
# define TYPE_ONES_COMPLEMENT(t) ((t) ~ (t) 0 == 0)
# define TYPE_SIGNED_MAGNITUDE(t) ((t) ~ (t) 0 < (t) -1)
/* True if the arithmetic type T is signed. */
# define TYPE_SIGNED(t) (! ((t) 0 < (t) -1))
/* The maximum and minimum values for the integer type T. These
macros have undefined behavior if T is signed and has padding bits.
If this is a problem for you, please let us know how to fix it for
your host. */
# define TYPE_MINIMUM(t) \
((t) (! TYPE_SIGNED (t) \
? (t) 0 \
: TYPE_SIGNED_MAGNITUDE (t) \
? ~ (t) 0 \
: ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))
# define TYPE_MAXIMUM(t) \
((t) (! TYPE_SIGNED (t) \
? (t) -1 \
: ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))))
and no one has complained yet, so we might as well just use this same
logic in m4/mktime.m4.
> The approach I would take is just:
>
> time_t_max = (time_t)1 << 8*sizeof(time_t)-2;
8 is a magic number; it would be better to use CHAR_BIT, as was done in
intprops.h.
> If this test comes from higher-up (gnulib?) please forward my bug
> report to the relevant upstream.
Forwarded; and the patch should be applied shortly.
--
Eric Blake eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Thu, 27 Jan 2011 17:11:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 7928 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jan 27, 2011 at 08:14:56AM -0700, Eric Blake wrote:
> # define TYPE_MINIMUM(t) \
> ((t) (! TYPE_SIGNED (t) \
> ? (t) 0 \
> : TYPE_SIGNED_MAGNITUDE (t) \
> ? ~ (t) 0 \
> : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))
> # define TYPE_MAXIMUM(t) \
> ((t) (! TYPE_SIGNED (t) \
> ? (t) -1 \
> : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))))
The last line of this macro has UB due to signed integer overflow in
the << operation. Replace it with
(( (t)1 << CHAR_BIT*sizeof(time_t)-2 ) - 1) * 2 + 1
Which for a 32-bit type would expand as:
(0x40000000 - 1) * 2 + 1
0x3fffffff *2 + 1
0x7ffffffe + 1
0x7fffffff
With no overflows.
> and no one has complained yet, so we might as well just use this same
> logic in m4/mktime.m4.
Well apparently no one complained about the overflow in coreutils
either. Perhaps later gcc versions are more forgiving; I found it
building on a system where I have to use gcc 3.2.3, which, being one
of the earlier versions to utilize the UB of signed overflow, might be
less diplomatic about it. Anyway to avoid future trouble, I would
strive to remove all signed overflow UB from the tests even if it
doesn't presently hurt anyone.
> 8 is a magic number; it would be better to use CHAR_BIT, as was done in
> intprops.h.
As you wish. This code (coreutils) is sufficiently POSIX-like-system
dependent that I thought using POSIX's requirement CHAR_BIT==8 was
reasonable.
> > If this test comes from higher-up (gnulib?) please forward my bug
> > report to the relevant upstream.
>
> Forwarded; and the patch should be applied shortly.
Thanks!
Rich
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Thu, 27 Jan 2011 17:50:03 GMT)
Full text and
rfc822 format available.
Message #14 received at 7928 <at> debbugs.gnu.org (full text, mbox):
On 01/27/11 09:28, Rich Felker wrote:
> On Thu, Jan 27, 2011 at 08:14:56AM -0700, Eric Blake wrote:
>> > # define TYPE_MINIMUM(t) \
>> > ((t) (! TYPE_SIGNED (t) \
>> > ? (t) 0 \
>> > : TYPE_SIGNED_MAGNITUDE (t) \
>> > ? ~ (t) 0 \
>> > : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))
>> > # define TYPE_MAXIMUM(t) \
>> > ((t) (! TYPE_SIGNED (t) \
>> > ? (t) -1 \
>> > : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))))
> The last line of this macro has UB due to signed integer overflow in
> the << operation.
No it doesn't. ~ (t) 0 evaluates to -1, and -1 << 31 does not
overflow.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Thu, 27 Jan 2011 18:08:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 7928 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 01/27/2011 10:57 AM, Paul Eggert wrote:
>>>> # define TYPE_MAXIMUM(t) \
>>>> ((t) (! TYPE_SIGNED (t) \
>>>> ? (t) -1 \
>>>> : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))))
>> The last line of this macro has UB due to signed integer overflow in
>> the << operation.
>
> No it doesn't. ~ (t) 0 evaluates to -1, and -1 << 31 does not
> overflow.
C99 states this (6.5.7 paragraph 4)
The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits
are filled with zeros. If E1 has an unsigned type, the value of the
result is E1 × 2^E2 , reduced modulo one more than the maximum value
representable in the result type. If E1 has a signed type and
nonnegative value, and E1 × 2^E2 is representable in the result type,
then that is the resulting value; otherwise, the behavior is undefined.
In other words, the problem is not about overflow, but about undefined
behavior.
--
Eric Blake eblake <at> redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Thu, 27 Jan 2011 18:17:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 7928 <at> debbugs.gnu.org (full text, mbox):
On 01/27/11 10:15, Eric Blake wrote:
> In other words, the problem is not about overflow, but about undefined
> behavior.
You're right that the behavior is not defined, but this should
not be a problem in practice, any more than the * CHAR_BIT business
should be a problem in practice (that also relies a not-guaranteed-
by-the-standard assumption).
Currently the code assumes that if time_t values are signed,
then they use either two's complement, ones' complement,
or signed magnitude representation internally, that left shift
shifts those bits left, and that there are no padding bits. The
assumptions about left-shift and no padding bits are not guaranteed
by the C standard, but they are portable in practice, even when using
the latest GCC with all the optimization bells and whistles enabled.
It's unlikely that GCC will ever break expressions
like -1 << 1 merely because the C standard lets it do that.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Thu, 27 Jan 2011 18:35:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 7928 <at> debbugs.gnu.org (full text, mbox):
Rich Felker wrote:
> > # define TYPE_MAXIMUM(t) \
> > ((t) (! TYPE_SIGNED (t) \
> > ? (t) -1 \
> > : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))))
>
> The last line of this macro has UB due to signed integer overflow in
> the << operation.
No there is no overflow here. The ~ operator has higher syntactic precedence
than the << operator, therefore the expression in the last line consists of
4 steps:
1. Take a zero.
2. Invert all bits.
3. Shift left by n-1 bits.
4. Invert all bits.
Taking <http://en.wikipedia.org/wiki/Signed_number_representations> as
reference, in all three cases (two's complement, one's complement, signed
magnitude) the results are:
- after step 1: 000...00
- after step 2: 111...11
- after step 3: 100...00 (and no overflow here, in two's complement)
- after step 4: 011...11
ISO C 99 says about the << operator:
"The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
bits are filled with zeros. If E1 has an unsigned type, the value of
the result is E1 × 2^E2 , reduced modulo one more than the maximum
value representable in the result type. If E1 has a signed type and
nonnegative value, and E1 × 2^E2 is representable in the result type,
then that is the resulting value; otherwise, the behavior is undefined."
If you take the first sentence as a mandatory description of what <<
does, then ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)) is the bit pattern
011...11 on all systems and with all compilers.
If you take the last sentence as more relevant than the first one, then
any shift of any negative value is undefined behaviour.
Do you mean to say that GCC produces undefined behaviour for shifts of
negative values, even those where the result is negative (no overflow)?
I've never seen a sign of that.
Bruno
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Thu, 27 Jan 2011 21:51:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 7928 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jan 27, 2011 at 07:42:10PM +0100, Bruno Haible wrote:
> Do you mean to say that GCC produces undefined behaviour for shifts of
> negative values, even those where the result is negative (no overflow)?
> I've never seen a sign of that.
I mean to say that left-shifting a negative value *at all* is
undefined behavior. I doubt gcc will ever break it, but why not use my
version of the code that's 100% safe and never invokes undefined
behavior?
Rich
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Fri, 28 Jan 2011 07:35:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 7928 <at> debbugs.gnu.org (full text, mbox):
On 01/27/2011 02:08 PM, Rich Felker wrote:
> I mean to say that left-shifting a negative value *at all* is
> undefined behavior. I doubt gcc will ever break it, but why not use my
> version of the code that's 100% safe and never invokes undefined
> behavior?
Your version of the code provokes similar undefined behavior
when computing TYPE_MINIMUM, which means that overall it's
no more reliable than what's there now. An advantage of
the current approach is that there's a clear relationship
between TYPE_MINIMUM and TYPE_MAXIMUM, and this aids understanding.
If it could be done just as clearly by other means, that would
be OK too.
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Fri, 28 Jan 2011 17:20:03 GMT)
Full text and
rfc822 format available.
Message #32 received at 7928 <at> debbugs.gnu.org (full text, mbox):
On Thu, Jan 27, 2011 at 11:42:25PM -0800, Paul Eggert wrote:
> On 01/27/2011 02:08 PM, Rich Felker wrote:
> > I mean to say that left-shifting a negative value *at all* is
> > undefined behavior. I doubt gcc will ever break it, but why not use my
> > version of the code that's 100% safe and never invokes undefined
> > behavior?
>
> Your version of the code provokes similar undefined behavior
> when computing TYPE_MINIMUM, which means that overall it's
> no more reliable than what's there now. An advantage of
> the current approach is that there's a clear relationship
> between TYPE_MINIMUM and TYPE_MAXIMUM, and this aids understanding.
> If it could be done just as clearly by other means, that would
> be OK too.
My version only computes the maximum. The minimum is -max if the type
is sign/magnitude or ones complement and -max-1 if the type is twos
complement. Testing which of the three allowable signed integer
representations is used is easy: compare ~(t)1 against and -(t)1 and
-(t)2.
Rich
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Fri, 28 Jan 2011 17:50:03 GMT)
Full text and
rfc822 format available.
Message #35 received at 7928 <at> debbugs.gnu.org (full text, mbox):
Rich Felker wrote:
> Testing which of the three allowable signed integer
> representations is used is easy: compare ~(t)1 against and -(t)1 and
> -(t)2.
Testing which of the three signed integer representations is in use
is not even needed: Your formula
((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1)
yields the correct result in all three cases.
Bruno
Information forwarded
to
owner <at> debbugs.gnu.org, bug-coreutils <at> gnu.org:
bug#7928; Package
coreutils.
(Fri, 28 Jan 2011 18:56:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 7928 <at> debbugs.gnu.org (full text, mbox):
On Fri, Jan 28, 2011 at 06:57:22PM +0100, Bruno Haible wrote:
> Rich Felker wrote:
> > Testing which of the three allowable signed integer
> > representations is used is easy: compare ~(t)1 against and -(t)1 and
> > -(t)2.
>
> Testing which of the three signed integer representations is in use
> is not even needed: Your formula
> ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1)
> yields the correct result in all three cases.
It yields the correct max. However, getting the min requires knowing
whether min is -max or -max-1. This depends on which of the
representations is used:
min = ~(t)1 == -(t)2 ? -max-1 : -max;
Rich
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Sun, 30 Jan 2011 07:57:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Rich Felker <dalias <at> aerifal.cx>:
bug acknowledged by developer.
(Sun, 30 Jan 2011 07:57:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 7928-done <at> debbugs.gnu.org (full text, mbox):
On 01/27/2011 11:42 PM, Paul Eggert wrote:
> If it could be done just as clearly by other means, that would
> be OK too.
To try to do that, I installed the following:
---
ChangeLog | 13 +++++++++++++
lib/intprops.h | 4 ++--
lib/mktime.c | 2 +-
lib/strtol.c | 4 ++--
m4/mktime.m4 | 7 ++++---
m4/nanosleep.m4 | 4 ++--
m4/parse-datetime.m4 | 8 +++++---
m4/stdint.m4 | 8 +++++---
8 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index fdaf383..ded04f7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,18 @@
2011-01-29 Paul Eggert <eggert <at> cs.ucla.edu>
+ TYPE_MAXIMUM: avoid theoretically undefined behavior
+ * lib/intprops.h (TYPE_MINIMUM, TYPE_MAXIMUM): Do not shift a
+ negative number, which the C Standard says has undefined behavior.
+ In practice this is not a problem, but might as well do it by the book.
+ Reported by Rich Felker and Eric Blake; see
+ <http://lists.gnu.org/archive/html/bug-gnulib/2011-01/msg00493.html>.
+ * lib/strtol.c (TYPE_MINIMUM, TYPE_MAXIMUM): Likewise.
+ * m4/mktime.m4 (AC_FUNC_MKTIME): Likewise.
+ * m4/nanosleep.m4 (gl_FUNC_NANOSLEEP): Likewise.
+ * m4/parse-datetime.m4 (gl_PARSE_DATETIME): Likewise.
+ * m4/stdint.m4 (gl_STDINT_H): Likewise.
+ * lib/mktime.c (TYPE_MAXIMUM): Redo slightly to match the others.
+
mktime: #undef mktime before #defining it
* lib/mktime.c (mktime) [DEBUG]: #undef mktime before #defining it.
diff --git a/lib/intprops.h b/lib/intprops.h
index 511a5aa..58b1b3f 100644
--- a/lib/intprops.h
+++ b/lib/intprops.h
@@ -49,11 +49,11 @@
? (t) 0 \
: TYPE_SIGNED_MAGNITUDE (t) \
? ~ (t) 0 \
- : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))
+ : ~ TYPE_MAXIMUM (t)))
# define TYPE_MAXIMUM(t) \
((t) (! TYPE_SIGNED (t) \
? (t) -1 \
- : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))))
+ : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1)))
/* Return zero if T can be determined to be an unsigned type.
Otherwise, return 1.
diff --git a/lib/mktime.c b/lib/mktime.c
index d35bdd0..2486514 100644
--- a/lib/mktime.c
+++ b/lib/mktime.c
@@ -113,7 +113,7 @@ typedef long long int long_int;
#define TYPE_MAXIMUM(t) \
((t) (! TYPE_SIGNED (t) \
? (t) -1 \
- : (((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) << 1) + 1)))
+ : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1)))
#ifndef TIME_T_MIN
# define TIME_T_MIN TYPE_MINIMUM (time_t)
diff --git a/lib/strtol.c b/lib/strtol.c
index 747d70e..b6a761e 100644
--- a/lib/strtol.c
+++ b/lib/strtol.c
@@ -141,11 +141,11 @@
? (t) 0 \
: TYPE_SIGNED_MAGNITUDE (t) \
? ~ (t) 0 \
- : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))
+ : ~ TYPE_MAXIMUM (t)))
# define TYPE_MAXIMUM(t) \
((t) (! TYPE_SIGNED (t) \
? (t) -1 \
- : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))))
+ : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1)))
# ifndef ULLONG_MAX
# define ULLONG_MAX TYPE_MAXIMUM (unsigned long long)
diff --git a/m4/mktime.m4 b/m4/mktime.m4
index 7836b76..56b2416 100644
--- a/m4/mktime.m4
+++ b/m4/mktime.m4
@@ -1,4 +1,4 @@
-# serial 18
+# serial 19
dnl Copyright (C) 2002-2003, 2005-2007, 2009-2011 Free Software Foundation,
dnl Inc.
dnl This file is free software; the Free Software Foundation
@@ -175,12 +175,13 @@ main ()
time_t_max = (! time_t_signed
? (time_t) -1
- : ~ (~ (time_t) 0 << (sizeof (time_t) * CHAR_BIT - 1)));
+ : ((((time_t) 1 << (sizeof (time_t) * CHAR_BIT - 2)) - 1)
+ * 2 + 1));
time_t_min = (! time_t_signed
? (time_t) 0
: time_t_signed_magnitude
? ~ (time_t) 0
- : ~ (time_t) 0 << (sizeof (time_t) * CHAR_BIT - 1));
+ : ~ time_t_max);
delta = time_t_max / 997; /* a suitable prime number */
for (i = 0; i < N_STRINGS; i++)
diff --git a/m4/nanosleep.m4 b/m4/nanosleep.m4
index 233f1c1..34493bb 100644
--- a/m4/nanosleep.m4
+++ b/m4/nanosleep.m4
@@ -1,4 +1,4 @@
-# serial 32
+# serial 33
dnl From Jim Meyering.
dnl Check for the nanosleep function.
@@ -58,7 +58,7 @@ AC_DEFUN([gl_FUNC_NANOSLEEP],
#define TYPE_MAXIMUM(t) \
((t) (! TYPE_SIGNED (t) \
? (t) -1 \
- : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))))
+ : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1)))
static void
check_for_SIGALRM (int sig)
diff --git a/m4/parse-datetime.m4 b/m4/parse-datetime.m4
index 2341de9..e665ef3 100644
--- a/m4/parse-datetime.m4
+++ b/m4/parse-datetime.m4
@@ -1,4 +1,4 @@
-# parse-datetime.m4 serial 18
+# parse-datetime.m4 serial 19
dnl Copyright (C) 2002-2006, 2008-2011 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -41,9 +41,11 @@ AC_DEFUN([gl_PARSE_DATETIME],
#include <time.h> /* for time_t */
#include <limits.h> /* for CHAR_BIT, LONG_MIN, LONG_MAX */
#define TYPE_MINIMUM(t) \
- ((t) ((t) 0 < (t) -1 ? (t) 0 : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))
+ ((t) ((t) 0 < (t) -1 ? (t) 0 : ~ TYPE_MAXIMUM (t)))
#define TYPE_MAXIMUM(t) \
- ((t) ((t) 0 < (t) -1 ? (t) -1 : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))))
+ ((t) ((t) 0 < (t) -1 \
+ ? (t) -1 \
+ : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1)))
typedef int verify_min[2 * (LONG_MIN <= TYPE_MINIMUM (time_t)) - 1];
typedef int verify_max[2 * (TYPE_MAXIMUM (time_t) <= LONG_MAX) - 1];
]])],
diff --git a/m4/stdint.m4 b/m4/stdint.m4
index 43e1f70..26654c6 100644
--- a/m4/stdint.m4
+++ b/m4/stdint.m4
@@ -1,4 +1,4 @@
-# stdint.m4 serial 36
+# stdint.m4 serial 37
dnl Copyright (C) 2001-2011 Free Software Foundation, Inc.
dnl This file is free software; the Free Software Foundation
dnl gives unlimited permission to copy and/or distribute it,
@@ -145,9 +145,11 @@ uintmax_t j = UINTMAX_MAX;
#include <limits.h> /* for CHAR_BIT */
#define TYPE_MINIMUM(t) \
- ((t) ((t) 0 < (t) -1 ? (t) 0 : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))
+ ((t) ((t) 0 < (t) -1 ? (t) 0 : ~ TYPE_MAXIMUM (t)))
#define TYPE_MAXIMUM(t) \
- ((t) ((t) 0 < (t) -1 ? (t) -1 : ~ (~ (t) 0 << (sizeof (t) * CHAR_BIT - 1))))
+ ((t) ((t) 0 < (t) -1 \
+ ? (t) -1 \
+ : ((((t) 1 << (sizeof (t) * CHAR_BIT - 2)) - 1) * 2 + 1)))
struct s {
int check_PTRDIFF:
PTRDIFF_MIN == TYPE_MINIMUM (ptrdiff_t)
--
1.7.3
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sun, 27 Feb 2011 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 14 years and 176 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.