>

>> So how this is going to work then?

>

>> uint32value = ( buf[ipos] << 24 ) |
>> ( buf[ipos+1] << 16 ) |
>> ( buf[ipos+2] << 8 ) |
>> buf[ipos+3] ;

>

>> With CHAR_BIT = 32 and sizeof(u_int32_t) = 1 (buf + ipos)
>> and (buf + ipos + 1) will point 32 bits apart, not 8, right?

>
> Yes, that is correct.
> And probably, each element of buf will have a value in the range [0,255]
> (or possibly [-128,127]).
>
> For reference, I am currently working on a platform with CHAR_BIT == 16.
> When I do serial communications (octet oriented), each incoming octet
> gets stored in its own (16-bit wide) byte.
> If I want to reconstruct a 16-bit or 32-bit value, I need to use the
> shifting method shown above.
>

>> Or your 32 bit chars overlap?
>> And just for giggles, with CHAR_BIT = 64, is sizeof(u_int32_t) == 1/2?

>
> That depends on how you round-off the result of the division. :-)
> Either you round up, and you have a type u_int32_t that is actually 64
> bits wide, or you round down and you have a zero-width type that can't
> exist.
>
> Bart v Ingen Schenau