Re: Bytes' order with different C++ compilers

nickf3 wrote:

> ...
>>
>> The problem is that sane communications libraries deal in sequences
>> of octets stored in unsigned char (which are then packed up in the
>> correct order).  ntohl is based on an approach where you store bytes
>> into the memory of a struct, and then fix-up the byte order.  It
>> doesn't work if your platform has CHAR_BIT == 64; it requires you to
>> control padding between member variables of a struct; it requires you
>> to declare the structure with specific-sized members (rather than a
>> natural "int" or "long").
>>
>> Just Say No.
> 
> No :)
> 
> 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
****fting 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.

> 
> --
>   Nikolai
> 
Bart v Ingen Schenau
-- 
a.c.l.l.c-c++ FAQ: http://www.comeaucomputing.com/learn/faq
c.l.c FAQ: http://c-faq.com/
c.l.c++ FAQ: http://www.para****ft.com/c++-faq-lite/

      [ See http://www.gotw.ca/resources/clcm.htm
for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]