This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PROPOSED PATCH] Fix integer overflow when adjusting posixrules
- From: Florian Weimer <fweimer at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, libc-alpha at sourceware dot org
- Date: Wed, 13 Apr 2016 07:26:15 +0200
- Subject: Re: [PROPOSED PATCH] Fix integer overflow when adjusting posixrules
- Authentication-results: sourceware.org; auth=none
- References: <1460317379-31635-1-git-send-email-eggert at cs dot ucla dot edu>
On 04/10/2016 09:42 PM, Paul Eggert wrote:
+/* intprops.h -- properties of integer types
I'm afraid I have serious doubts about the maintainability of this file.
I have picked just one example.
+/* 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)
I don't these macros perform what the comment claims. The ~ operator
promotes the argument to type int, so these macros do not always check
the supplied type. In this case, the argument for the outer cast is not
within the range of type t, so the result of the cast is
implementation-defined. For ones' complement, ~0 can be undefined, it
does not have to be 0.
(We don't build glibc with -fwrapv, in case this isn't clear.)
Florian