By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,192 Members | 855 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,192 IT Pros & Developers. It's quick & easy.

byte order problem

P: n/a
Hi,

when porint apps to powerpc the byte order get's swapped to
low-endian. Now, what problems can occur and what should I take care
of when porting to mac e.g.?

--
-Gernot
int main(int argc, char** argv) {printf
("%silto%c%cf%cgl%ssic%ccom%c", "ma", 58, 'g', 64, "ba", 46, 10);}

________________________________________
Looking for a good game? Do it yourself!
GLBasic - you can do
www.GLBasic.com
Jul 22 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
> when porint apps to powerpc the byte order get's swapped to
low-endian. Now, what problems can occur and what should I take care
of when porting to mac e.g.?


Anything like:
- Reading binary files,
- Type casts to access parts of variables,
- Reading of unicode packed in UTF16 or similar,
- Bit operations; for example for graphics.

Niels Dybdahl
Jul 22 '05 #2

P: n/a

"Niels Dybdahl" <nd*@fjern.detteesko-graphics.com> schrieb im
Newsbeitrag news:40*********************@dtext02.news.tele.dk. ..
when porint apps to powerpc the byte order get's swapped to
low-endian. Now, what problems can occur and what should I take care of when porting to mac e.g.?
Anything like:
- Reading binary files,


How about:
struct
{
long a;
long b;
}s;

fread(&s, sizeof(s), file); ??

- Type casts to access parts of variables,
unsigned long a = 0xFFFF0000;
unsigned char b = (unsigned char) a;
Does this cause a problem?

- Reading of unicode packed in UTF16 or similar,
Oh, OK. I use 8bit characters, but thank you.
- Bit operations; for example for graphics.


long a = 0xffff;
long b = a& 0xff ??

How do developers handle these problems?
-Gernot


Jul 22 '05 #3

P: n/a
Gernot Frisch wrote:
<snip>
How about:
struct
{
long a;
long b;
}s;

fread(&s, sizeof(s), file); ??
That'll indeed read each long according to the platform byte-order. See
below.
- Type casts to access parts of variables,

unsigned long a = 0xFFFF0000;
unsigned char b = (unsigned char) a;
Does this cause a problem?


No. Casts between integer types always work from the little end,
regardless of byte order.

<snip>
- Bit operations; for example for graphics.

long a = 0xffff;
long b = a& 0xff ??


No problem there. Hexadecimal literals are specified in standard
hexadecimal notation.
How do developers handle these problems?
-Gernot


The only problem you've addressed is reading data from a binary file.
Assuming that you want to be able to share data files between platforms,
you need to decide on a byte order as part of the file format. Then use
some functions to convert endianness as needed.

Here's a bit of some code I used for this:

----------
union ByteOrderer {
char b[4];
short s;
long l;
};

short LEShort(short s) {
union ByteOrderer le;

le.b[0] = (char) (s & 0xFF);
le.b[1] = (char) ((s & 0xFF00) >> 8);

return le.s;
}
----------

LEShort converts a short from little-endian to native BO or vice versa.
It's trivial to write LELong, BEShort and BELong on the same basis.
Of course, chances are you won't need both LE and BE functions in the
same program, unless you're reading/writing a variety of formats that
use different orders.

The other kind of problem you're likely to encounter is if you try to
access the same contents of memory as different types, either by casting
a pointer or using a union. (OK, so my snippet does this, but that's
because the whole point is to convert endianness.) If you want
portability here, you'll probably need to rewrite the code e.g. to use
shifts instead.

Stewart.

--
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment. Please keep
replies on the 'group where everyone may benefit.
Jul 22 '05 #4

P: n/a

The other kind of problem you're likely to encounter is if you try to access the same contents of memory as different types, either by casting a pointer or using a union. (OK, so my snippet does this, but that's because the whole point is to convert endianness.) If you want
portability here, you'll probably need to rewrite the code e.g. to use shifts instead.

Ah, OK. So if I'll use long as long and pointer to something as
pointer to something and not as pointer to somethins else, everything
is likely to work good. How about std c++ library's fstream clasS?
Does it already take care of this?
But it's not really a problem since I'm using my own
"WriteToFile_long(long data)", since I already expected this kind of
problems.

-Gernot
Jul 22 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.