Re: Bytes' order with different C++ compilers

On May 22, 9:58 pm, nickf3 <nic...@[EMAIL PROTECTED]
> wrote:
> > Ok, thanks to everybody for enlightenment. From all this I
> > gather that the only thing you are complaining about wrt
> > ntoh functions (at least the interface) is argument passed
> > by value instead of by ptr to uchar?

Exactly.
>
> And just to make sure this horse is dead - one last kick :)

You have to be joking.  This horse will be back and full of life
within the next two years :-)

> As far as I understand the standard the following should be true:
>
> 255 <= UCHAR_MAX <= 2**CHAR_BIT - 1

Yes.  Except that unsigned char is special (it isn't allowed padding
bits), so I /believe/ UCHAR_MAX==2**CHAR_BIT - 1.  (This being usenet,
somebody will be along to correct me shortly if I'm wrong).
>
> with both UCHAR_MAX and CHAR_BIT being defined by implementation.

YES!
>
> Then shouldn't ****table version be
>
>   uint32value = (( buf[ipos]   & 0xff ) << 24 ) |
>                 (( buf[ipos+1] & 0xff ) << 16 ) |
>                 (( buf[ipos+2] & 0xff ) <<  8 ) |
>                  ( buf[ipos+3] & 0xff );
> instead?

The idea is that you don't need the masking because buf will have been
filled by a communications function that will put an octet (range
0..255) into each element.  On some implementations, buf[ipos] will be
big enough to hold a value greater than 255, but such a value will
never be stored by the communications library.

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