Re: [PATCH] intprops, mktime, strtol: assume two's complement

[Eric Blake]

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