Re: [somewhat OT] portable C under OjbC
Re: [somewhat OT] portable C under OjbC
- Subject: Re: [somewhat OT] portable C under OjbC
- From: "Clark S. Cox III" <email@hidden>
- Date: Thu, 7 Feb 2002 16:33:41 -0500
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.