[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] intprops, mktime, strtol: assume two's complement
From: |
Eric Blake |
Subject: |
Re: [PATCH] intprops, mktime, strtol: assume two's complement |
Date: |
Wed, 13 Apr 2016 08:30:06 -0600 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 |
On 04/13/2016 01:13 AM, Paul Eggert wrote:
> These macros were not portable to every conforming C11 ones'
> complement platform. It's not worth the hassle of porting to some
> platforms that use ones' complement or signed magnitude, as such
> platforms are almost purely theoretical nowadays and porting even
> to some of them makes the code harder to review for little
> practical benefit. Problem reported by Florian Weimer in:
> https://sourceware.org/ml/libc-alpha/2016-04/msg00295.html
> * lib/intprops.h (TYPE_TWOS_COMPLEMENT, TYPE_ONES_COMPLEMENT)
> (TYPE_SIGNED_MAGNITUDE, _GL_INT_TWOS_COMPLEMENT):
> * lib/mktime.c (TYPE_TWOS_COMPLEMENT):
> * lib/strtol.c (TYPE_TWOS_COMPLEMENT, TYPE_ONES_COMPLEMENT)
> (TYPE_SIGNED_MAGNITUDE):
> Remove. All uses rewritten to assume two's complement, which is
> all we can reasonably test nowadays anyway.
> * top/maint.mk (_intprops_names): Remove the removed macros.
Worth adding a compile-time assertion that the types are indeed
twos-complement in behavior?
>
> -/* 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 signed integer expression E uses two's complement. */
> -#define _GL_INT_TWOS_COMPLEMENT(e) (~ _GL_INT_CONVERT (e, 0) == -1)
> -
> /* True if the real type T is signed. */
> #define TYPE_SIGNED(t) (! ((t) 0 < (t) -1))
>
> @@ -55,18 +44,13 @@
> #define EXPR_SIGNED(e) (_GL_INT_NEGATE_CONVERT (e, 1) < 0)
>
>
> -/* Minimum and maximum values for integer types and expressions. 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. */
> +/* Minimum and maximum values for integer types and expressions.
> + These macros have undefined behavior for signed types that either
> + have padding bits or do not use two's complement. If this is a
> + problem for you, please let us know how to fix it for your host. */
That is, rather than having undefined behavior, wouldn't it be nicer to
force a compiler error in the (unlikely) case that TYPE_TWOS_COMPLEMENT
doesn't hold? Maybe just once in the header for a couple of
representative types like 'int' and 'long', rather than on every
expansion of the remaining macros?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature