Re: [somewhat OT] portable C under OjbC
Re: [somewhat OT] portable C under OjbC
- Subject: Re: [somewhat OT] portable C under OjbC
- From: Raphael Sebbe <email@hidden>
- Date: Fri, 8 Feb 2002 10:02:33 +0100
Also, alignment is sometimes an issue when working on different
platforms/compilers.
This means that the size of structures and the address offsets of its
fields can vary between architectures. This is only a problem if data is
going to be shared across different architectures (files, socket...).
Note there are sometimes ways to force alignment, but this is
compiler-dependent.
Raphael
On Thursday, February 7, 2002, at 10:33 PM, Clark S. Cox III wrote:
On Thursday, February 7, 2002, at 12:52 , Boz Jennings wrote:
Thanks for all the replies!
The portability I'm looking for relates to things like the size of
primitives, endian issues and such.
For example, as I write my code happily away on my TiBook all my int
variables have a whopping 32 bits. There could easily be times where I
use large int values that would blow out a 16 bit int machine. If this
problem came up a year after writing the code it'd be a major hassle
to debug. I'd like to have a tool that looks at the code and checks it
against a lowest-common-denominator ANSI C system.
Well, as for a "lowest-common-denominator ANSI C system", you are
guaranteed the following:
signed char can hold at least [ -127, 127 ]
unsigned char can hold at least [ 0, 255 ]
char can hold the same as either signed or unsigned char
short can hold at least [ -32767, 32767 ]
unsigned short can hold at least [ 0, 65535 ]
int can hold at least the same as short
unsigned int can hold at least the same as unsigned short
long can hold at least [ -2147483647, 2147483647 ], and cannot have a
smaller range than int
unsigned long can hold at least the same as unsigned int or [ 0,
4294967295 ], and cannot have a smaller range than unsigned int
long long can hold at least the same as long or [ -9223372036854775807,
9223372036854775807 ], and cannot have a smaller range than long
unsigned long long can hold at least the same as long or [ 0,
18446744073709551616 ], and cannot have a smaller range than unsigned
long
... I don't know enough about endian issues to give an example.
Well, here's one (Assumes that long is 32-bit for simplicity):
unsigned char arr[] = { 0xAA, 0xBB, 0xCC, 0xDD };
unsigned long num = *(unsigned long*)arr;
// On some platforms, num will equal 0xAABBCCDD, while on
others, it could equal 0xDDCCBBAA
Basically, an endianess problem can potentially crop up any time
you interpret larger types as a series of bytes (i.e. writing out to
disk, sending over a network, etc). So make sure that any time it is
possible for your data to leave your computer, and be used on a
different platform,
you must take extra precautions.
A more general thing to check might be non-portable char assignment.
That is, "char ch = 0x41" could show a warning but "char ch = 'A'"
would not.
Another one could be comparing a char to EOF. This works fine on 16
bit chars but not on 8 bit chars....
It might not even work on a platform with 16-bit chars.
These are all ANSI C compliant things that could cause trouble if code
is ported.
Sorry I couldn't be of any help suggesting a specific tool, you
may want to try posting to comp.lang.c.
--
Clark S. Cox, III
email@hidden
http://www.whereismyhead.com/clark/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.