Re: reporting typedef errors automatically

[Szabolcs Borsanyi]

On Thu, May 29, 2008 at 02:04:16PM -0700, vippstar@gmail. com wrote:

If intN_t types are available, they are two's complement no padding
signed integers with exact width N.
Reference, 7.18.1.1 Exact-width integer types.
These tests are not needed.

That's strange. 7.18.1.1 says

1 The typedef name intN_t designates a signed integer type with width N, no
padding bits, and a two's complement representation. Thus, int8_t denotes a
signed integer type with a width of exactly 8 bits.

and also:

3 These types are optional. However, if an implementation provides integer
types with widths of 8, 16, 32, or 64 bits, it shall define the corresponding
typedef names.

Does that imply that if an implementation provides 32 or 16-bit int with
one's complement representation, that it has to define int32_t, which has,
in turn, two's component representation.


Szabolcs

[Harald van =?UTF-8?b?RMSzaw==?=]

Re: reporting typedef errors automatically

On Thu, 29 May 2008 21:28:00 +0000, Szabolcs Borsanyi wrote:

That's strange. 7.18.1.1 says
>
1 The typedef name intN_t designates a signed integer type with width N,
no padding bits, and a two's complement representation. Thus, int8_t
denotes a signed integer type with a width of exactly 8 bits.
>
and also:
>
3 These types are optional. However, if an implementation provides
integer types with widths of 8, 16, 32, or 64 bits, it shall define the
corresponding typedef names.
>
Does that imply that if an implementation provides 32 or 16-bit int with
one's complement representation, that it has to define int32_t, which
has, in turn, two's component representation.

You are correct, and the text has already been changed to

3 These types are optional. However, if an implementation provides integer
types with widths of 8, 16, 32, or 64 bits, no padding bits, and (for the
signed types) that have a two's complement representation, it shall define
the corresponding typedef names.

in an attempt to address precisely that issue. It doesn't manage to do so
entirely, though: if an implementation provides a 32-bit ones' complement
signed int, and a 32-bit unsigned int, both without padding bits, then
7.18.1.1p3 requires that the implementation define uint32_t, and 7.18.1p1
states that if an implementation provides uint32_t, it must also provide
int32_t.