• Serge K (15/15) Aug 28 2001 Just a little idea about more portable code with less conditional compil...
• Chris Friesen (11/28) Aug 29 2001 The problem I see with this is that if you do any kind of manipulation o...

"Serge K" <skarebo programmer.net> writes:

Just a little idea about more portable code with less conditional compilation...

In >90% cases little-endian / big-endian conversions are used to access
external data with predefined format.
In such cases it's more clear and portable to specify byte order explicitly as
a type attribute.
By default everything has byte order native for the target platform.
This attribute can be changed locally if necessary:

// something like this:

big_endian  uint32  *p; // pointer to big-endian data

little_endian
struct  SomeData
{
    int32  a_little-endian;
    big_endian  int16  b_big-endian;
    uint16  c_little-endian;
...
}

Chris Friesen <cfriesen nortelnetworks.com> writes:

Serge K wrote:

 In >90% cases little-endian / big-endian conversions are used to access
external data with predefined format.
 In such cases it's more clear and portable to specify byte order explicitly as
a type attribute.
 By default everything has byte order native for the target platform.
 This attribute can be changed locally if necessary:
 
 // something like this:
 
 big_endian  uint32  *p; // pointer to big-endian data
 
 little_endian
 struct  SomeData
 {
     int32  a_little-endian;
     big_endian  int16  b_big-endian;
     uint16  c_little-endian;
 ...
 }

The problem I see with this is that if you do any kind of manipulation of
b_big-endian on a little-endian machine you'll end up doing a lot of endian
conversion unnecessarily.

By specifying it explicitly you can leave all the endian conversion until it
really has to be done.



-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen nortelnetworks.com