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
