Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #400272

Re: Representing signed values in corresponding unsigned types

Show all headers | View raw

NS <ns@2b.here> writes:

> Can all the values of a signed int be represented in an unsigned
> int (or signed long in an unsigned long, etc.)?

Not guaranteed.

> If INT_MIN is now 0 and
> all values are arithmetically increased by -INT_MIN, is it
> guaranteed that every signed value can be represented?

No.

> In other words:  is UINT_MAX >= INT_MAX - INT_MIN?

Not guaranteed.  The case of UINT_MAX == INT_MAX is allowed.

> It seems obvious, but the standard appears to imply that this is
> not guaranteed.  It states:

The standard allows implementations where UINT_MAX == INT_MAX.

>> 6.2.5.6
>>
>> For each of the signed integer types, there is a corresponding (but
>> different) unsigned integer type that uses the same amount of storage
>> (including sign information) and has the same alignment requirements.
>
> So, same amount of storage including sign bit implies
> UINT_MAX == INT_MAX*2

It doesn't, because integer types (other than unsigned char) are
allowed to have padding bits, and unsigned types may have more
padding bits than signed types have.

> But:
>
>> 6.2.6.2
>>
>> For unsigned integer types, the bits of the object representation
>> shall be divided into two groups:  value bits and padding bits.
>> [...]

>> For signed integer types, the bits of an object representation
>> shall be divided into three groups:  value bits, padding bits and
>> the sign bit.  [...]  (if there are M value bits in the signed type
>> and N in the unsigned type, then M <= N).
>
> But shouldn't it be M < N?

The standard means what it says.  The case of M == N is allowed.

> Otherwise, if M == N, there are the same
> amount of value bits in both signed and unsigned (implying the
> unsigned has more padding bits), and UINT_MAX == INT_MAX.

That's right.

> I doubt that this is ever done,

It has been.

> but the standard seems to permit it.

Yes, deliberately so.

> Although "The range of nonnegative values of a signed integer type
> is a subrange of its corresponding unsigned integer type" [6.2.5.9]
> the use of 'subrange' implies that M < N?

Normal usage for "subrange" includes the case where the two ranges
are the same.

> So, is it actually portable to represent signed integers as
> unsigned?

Not fully portable, no.  If it's important that this be true then
somewhere there should be a test that INT_MAX < UINT_MAX, etc.

(Note that as of C23 there are different rules, and indeed the newer
standard requires, IIUC, that unsigned types have the same number of
padding bits as their corresponding signed types, and consequently
that INT_MAX < UINT_MAX, etc.)

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Representing signed values in corresponding unsigned types NS <ns@2b.here> - 2026-06-28 10:11 +0000
  Re: Representing signed values in corresponding unsigned types ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-28 12:07 +0000
  Re: Representing signed values in corresponding unsigned types Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-06-28 06:52 -0700
    Re: Representing signed values in corresponding unsigned types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 18:27 -0700
      Re: Representing signed values in corresponding unsigned types cross@spitfire.i.gajendra.net (Dan Cross) - 2026-06-29 12:13 +0000
      Re: Representing signed values in corresponding unsigned types Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 02:19 -0700
        Re: Representing signed values in corresponding unsigned types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-15 05:48 -0700
  Re: Representing signed values in corresponding unsigned types James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-06-28 22:23 -0400
    Re: Representing signed values in corresponding unsigned types Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-06-28 20:24 -0700

csiph-web