Sujet : Re: What is your opinion about unsigned int u = -2 ?
De : tr.17687 (at) *nospam* z991.linuxsc.com (Tim Rentsch)
Groupes : comp.lang.cDate : 12. Aug 2024, 07:07:32
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <86le12ff4r.fsf@linuxsc.com>
References : 1 2 3 4
User-Agent : Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Vir Campestris <
vir.campestris@invalid.invalid> writes:
On 11/08/2024 20:33, Tim Rentsch wrote:
>
Ick. That choice is exactly backwards IMO. Converting -1 to
an unsigned type always sets all the bits. Converting -1u to
an unsigned type can easily do the wrong thing, depending
on the target type.
>
"Converting -1 to an unsigned type always sets all the bits"
>
In any normal twos complement architecture that's the case. But there
are a few oddballs out there where -1 is +1, except that the dedicated
sign bit is set.
What you say is right if the transformation occurs by means of
type punning, as for example if we had a union with both a
signed int member and an unsigned int member. Reading the
unsigned int member after having assigned to the signed int
member depends on whether signed int uses ones' complement,
two's complement, or signed magnitude.
My comment though is about conversion, not about type punning.
The rules for conversion (both explicit conversion, when a cast
operator is used, and implicit conversion, such as when an
assignment is performed (and lots of other places)) are defined
in terms of values, not representations. Thus, in this code
signed char minus_one = -1;
unsigned u = minus_one;
unsigned long bigu = minus_one;
unsigned long long biggeru = minus_one;
printf( " printing unsigned : %u\n", (unsigned) minus_one );
in every case we get unsigned values (of several lengths) with
all value bits set, because of the rules for how values are
converted between a signed type (such as signed char) and an
unsigned type.