Re: [bug-gnulib] Re: [bug-grep] length of dec. representation of a number

[Paul Jarc]

I didn't know these macros were already there.  I've only used
mundane, unsurprising systems myself.  I imagine there are some out
there where this would break, but I agree it's just as well to keep
them until trouble strikes.  That said...

Stepan Kasal <address@hidden> wrote:
> (I cannot see how TYPE_MINIMUM could work with sign+magnitude.)

(t)~(t)0 would probably work for sign+magnitude, although it's not
strictly conforming C for types narrower than int.  (The operand of ~
gets promoted to int, and the result is int, but that value (INT_MIN)
won't fit in type t, so the result of the outer cast is
implementation-defined, and the standard even allows it to raise a
signal.)

> But that means that signed TYPE_MINIMUM is always 100..00 in binary, so we
> can use:
> #define TYPE_MAXIMUM(t) ((t) (~ TYPE_MINIMUM (t)))

I'd still cast the result to t; the operand of ~ is promoted, and the
result is the promoted type.

> /* The extra casts work around common compiler bugs.  */
> #define TYPE_SIGNED(t) (! ((t) 0 < (t) -1))

The negation seems unnecessarily complicated to me; OOC, is there
anything wrong with ((t)0>=(t)-1)?  (I've used ((t)1>(t)-1) in my
code.)

> /* - The outer cast is needed to work around a bug in Cray C 5.0.3.0.
>      It is necessary at least when t == time_t.
>    - We cannot use (1 << ...), because << could mean signed shift.  */
> #define TYPE_MINIMUM(t) ((t) (TYPE_SIGNED (t) \
>                             ? ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1) : (t) 0))

Actually, the outer cast is needed, because the operands of ~ and <<
are subject to promotion.  Maybe moving the cast inward would be would
be clearer: (t)(~(t)0<<...), but I don't know if it would work on
Crays.

I think the comment would be clearer as "sign-preserving shift"
instead of "signed shift".

Theoretical dangers: if t has padding bits, then the right operand of
<< is too large, so it gives undefined behavior - probably the result
would be 0 for unsigned types.  Also, << is undefined when the left
operand is negative, or even when it's positive if any set bits are
shifted off the end.


paul