Re: POSIX and 8-bit bytes

From: Brian Inglis (Brian.Inglis_at_SystematicSw.Invalid)
Date: 08/17/04 

Date: Tue, 17 Aug 2004 09:38:13 GMT

On Tue, 17 Aug 2004 04:21:31 GMT in comp.std.c, David Hopwood
<david.nospam.hopwood@blueyonder.co.uk> wrote:

>Jack Klein wrote:
>> Keith Thompson <kst-u@mib.org> wrote in comp.lang.c:
>>>David Hopwood <david.nospam.hopwood@blueyonder.co.uk> writes:
>>>>David Hopwood wrote:
>>>>>Clive D. W. Feather wrote:
>>>>>
>>>>>>I came across this old article by Doug Gwyn:
>>>>>>
>>>>>>Douglas A. Gwyn <DAGwyn@null.net> writes
>>>>>>
>>>>>>>Yet another example (starting with the "feature test" macros
>>>>>>>in 1988) where the POSIX people have not understood what was
>>>>>>>suggested by the Standard C people. The networking functions
>>>>>>>certainly should be using uint8_t since they explicitly deal
>>>>>>>with octet streams, and POSIX can reasonably require support
>>>>>>>for that typedef in the C implementation.
>>>>>
>>>>>Requiring support for that typedef is of course equivalent to only
>>>>>allowing 8 bit bytes, so Gywn's argument here is not self-consistent.
>>>>
>>>>Sorry, I was mistaken. It is possible to support uint8_t even though
>>>>the size of a byte is larger.
>>>
>>>It looks to me like you're right (in your last statement). If
>>>CHAR_BIT > 8, then uint8_t has to have (at least) CHAR_BIT-8 padding
>>>bits. ("At least" because uint8_t could be bigger than one byte.)
>>>The "width" of an integer type excludes padding bits.
>>
>> The C99 definition of the exact-width integer types does not allow for
>> this possibility in a (strictly?) conforming implementation.
>>
>> ========
>> 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.
>>
>> 2 The typedef name uintN_t designates an unsigned integer type with
>> width N. Thus, uint24_t denotes an unsigned integer type with a width
>> of exactly 24 bits.
>>
>> 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.
>
>If I'm reading this correctly, it is possible to support uint8_t when
>CHAR_BIT > 8, but not int8_t.

The section heading "Exact-width integer types" has certain
implications, and it says both u/int8_t must have exactly 8 bits.

If CHAR_BIT > 8, the implementation can support u/int_least8_t, as JK
also stated, in the part you snipped.

>What was the motivation for requiring that signed integer types have
>no padding bits, but not imposing the same requirement for unsigned
>integer types?

ICBW but are unsigned types allowed to have any padding bits?

>> The vast majority of CHAR_BIT > 8 platforms in active development
>> today are DSPs. Most that do not offer octet addressing are either
>> 16- or 32-bit, although I remember an old Motorola family that was
>> 24-bit that is probably still around.
>>
>> I don't know of a single hosted implementation for any DSP, and I
>> would be very surprised if anyone developing for them was dying for a
>> UNIX or Linux port, so it's pretty much of a moot point.
>
>I was once involved with a project that tried to port a TCP/IP stack
>to a DSP with 32-bit words, though. No fun at all.

Hosted implementations are not likely, but that just makes support of
as much as useful of the standard library a QoI issue.
Porting network stacks is likely, and u/int_least8_t could help. 

-- 
Thanks. Take care, Brian Inglis 	Calgary, Alberta, Canada
Brian.Inglis@CSi.com 	(Brian dot Inglis at SystematicSw dot ab dot ca)
    fake address		use address above to reply

Relevant Pages

  • Re: Four or Two Bytes?
    ... Not on the DS9K. ... unsigned short can have INT_MAX padding bytes on the DS9K. ... For unsigned integer types other than unsigned char, ... the bits of the object representation shall be divided into ...
    (comp.lang.c)
  • Re: Differences between pointers
    ... >> rlb@xxxxxxxxxxxxxxxxxxxxxx (Richard Bos) writes: ... >>> must contain padding bits, ... >> sanity.] ... on any other types besides integer types. ...
    (comp.lang.c)
  • Re: byte order
    ... casting objects to arrays of bytes, and guarantees that such an array ... The standard also gives the possibility of integer types containing ... padding bits, and it is not specified how such bits can be detected. ... code that cares about endianness, so it's not really an issue. ...
    (comp.lang.lisp)
  • Re: Invalid values for integers
    ... representation of value zero in all integer types (signed and ... padding bits in an integer type, it must be valid to have padding = 0 ... implemention to define int_t so they match (in fact ... IF the implementation chooses to make plain char like unsigned char, ...
    (comp.lang.c)
  • Re: Four or Two Bytes?
    ... Not on the DS9K. ... unsigned short can have INT_MAX padding bytes on the DS9K. ... For unsigned integer types other than unsigned char, ... the bits of the object representation shall be divided into ...
    (comp.lang.c)