Re: Anyone object to the following change in libc?

On Fri, Oct 31, 2003 at 06:20:17PM +0100, Stefan Farfeleder wrote:
> On Fri, Oct 31, 2003 at 04:43:37PM +0100, Erik Trulsson wrote:
> 
> > Perhaps not smaller in terms of the sizeof operator, but why can't one
> > have a 16-bit char, and an int8_t which occupies 16 bits, but only uses
> > 8 of them - the other 8 being padding?
> 
> 7.18.1.1 Exact-width integer types
> 
> 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.

I see.  My confusion stems from the fact that n869.txt (the last
publically available draft of the C99 standard) says

       7.18.1.1  Exact-width integer types

       [#1] The typedef name intN_t  designates  a  signed  integer
       type  with  width  N.  Thus, int8_t denotes a signed integer
       type with a width of exactly 8 bits.

The ", no padding bits" part is apparently one of the things that were changed
between n869.txt and the final standard.

Note to self: I really need to get a copy of the final C99 standard as
soon as I can afford one.

> 
> > Where in C99 does it say that uint8_t can't have padding bits?
> > I can't find anything in n869.txt to that effect.
> > As far as I can tell, the only type that is not allowed to have any
> > padding bits or trap representations is unsigned char.
> 
> uint8_t is int8_t's corresponding unsigned type.  This means
> sizeof(uint8_t) == sizeof(int8_t), thus uint8_t can't have padding bits
> either.

Yes, with the quote from the standard you supplied above, that becomes
clear.


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013_at_student.uu.se