Anyone object to the following change in libc?
Erik Trulsson
ertr1013 at student.uu.se
Fri Oct 31 09:30:11 PST 2003
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
More information about the freebsd-current
mailing list