Re: How do I get around this?
Re: How do I get around this?
- Subject: Re: How do I get around this?
- From: John Draper <email@hidden>
- Date: Sun, 28 Nov 2004 18:41:18 -0800
Brendan Younger wrote:
On Nov 28, 2004, at 12:56 AM, John Draper wrote:
I have to do an insane convoluted way of dealing with odd-sized packet
fields, and when I define it as a struct, the expected struct size
should be
95 bytes in length, but instead it is 100 bytes in length. WTF?
You can never count on specific sizes for struct's, that's just one of
the rules of the game; the compiler is free to pad to get "good" data
alignment.
But I thought it was possible to get the compiler to make packed
structures using the
#pragma directive.
Ok, so time for plan B... I'm just going to use a character array of
8 bit bytes, and MOVE the variables into the proper offset.... I know
it's a serious kludge, but I got no other choice,
It's not a kludge, it's how everyone else has to do it too. Myself,
I've defined quite a few macros to get big/little endian data out of
packed data. Something like:
value = getLittleEndianInt16(byte_array, offset);
I leave the implementation as an exercise to the reader.
Do I need something like this? Do you have this implemented?
Of course I did the
#pragma option align=packed
Ran some tests, and (sigh), I just cannot start on an odd-byte
boundary for
a field.... is there any other way?
Also tried:
#pragma pack(1)
But (sigh) that don't work either.... is there ANY hope?
Most modern computer architectures will raise an exception for
unaligned loads and stores. Some operating systems will handle the
exception and make it look like you can load and store from an
unaligned address, but it's dog-slow and really only useful for older
code that just assumes you can do this. The most efficient and easy
way to get data from strange offsets is just to have an enum with all
the offsets and then just define some macros to grab the data from an
arbitrary offset.
Yes - that is the way I'm doing it now.... But (sigh) I have to ditch
well tested code and re-write everything.
John
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden