C++ Logo


Advanced search

Re: [ub] [c++std-ext-14592] Re: Re: Sized integer types and char bits

From: Ion Gaztańaga <igaztanaga_at_[hidden]>
Date: Mon, 28 Oct 2013 22:19:59 +0100
El 28/10/2013 1:07, Lawrence Crowl escribió:
>> ------------------------------------------------
>> Char Types
>> Characters are 8 bits wide. The plain char type is unsigned by
>> default. This default can be changed to be signed by the
>> $PORT (SIGNEDCHAR) option. This affects all variables of type
>> char, even in arrays and structures.
>> Signed characters are stored in two’s-complement format. The>> values 0 through have the same bit pattern for signed and
>> unsigned types. Unsigned characters are stored in two’s
>> complement format if the $PORT (CHAR2) option is enabled.
> How would the representation of an unsigned number change with this
> option?

I think the option controls how a negative number can be assigned or
compared with an unsigned type:

Signed and Unsigned Type Comparisons

The comparison of negative numbers with unsigned types may behave
differently on A Series systems than on other platforms. Platforms that
store arithmetic values in one’s or two’s complement form store the sign
when assigning to an unsigned type. On A Series systems, the sign is not
stored when assigning to an unsigned type. On A Series systems,
comparing a negative value with the value in an unsigned type will never
be true unless the CHAR2 or UNSIGNED subordinate options of the PORT
compiler control option are used to emulate two’s complement arithmetic
on unsigned types. Another workaround is to change negative literals to
their one’s complement values (for example, -1 becomes 0xFF).


>> Bit operations (bitwise AND, OR, exclusive OR, and NOT) on signed
>> values affect only the 40 bits used by integers. Bit operations on
>> unsigned values conform to the mathematical definitions given in the
>> ANSI C standard. Because the sign bit is not adjacent to the other
>> bits, it is not possible to shift into or out of the sign bit.
> Which, I think conflicts with the recent change we made to allow
> shifting into the sign bit. I was never comfortable with that change
> because it broke the model of shift being isomorphic to multiplication
> by a power of two.

Yes, that's why requiring shifting into the sign bit could be allowed
only for (two's complement?) types with no padding bits.

> In other words, they have implemented the "overflow undefined
> unsigned integer" type that I have been wanting.
> Porting a program with a global option like that is likely not
> trivial. We really need two separate types.

Or maybe an attribute, but things start to complicate when trying to
define mixed arithmetic between overflow undefined and wraparound
unsigned types.



Received on 2013-10-28 22:20:17