Marco van de Voort wrote:

...

The above code should compile, I translated it from the BP code. The

only difference is in the type declarations; mByteOrder must always be 32-bits, and mByte must always be an array of 4 elements with 8-bits each, hence the use of Cardinal(x). The way it works is simple, and the code does not depend on any compiler specific syntax (except for type declarations) so it should compile correctly in the long run. AFAIK, constants are compiled in the native byte order of the target architecture. By comparing the long value as bytes, one-by-one, the byte order can be determined, hence the endianess can also be determined. I have tested this code on a Macintosh computer (which is the only big-endian machine I currently have access to), and have of course tested this on a PC. The results displayed are correct in both architectures.

This is very nice, but will require runtime testing (and checking of the bigendian flag *each* time)

True. Of course, you could do the test once per program and save the result in a static variable, but still I don't quite see the need for runtime endianness checking...

Maybe it is smarter to let the above program output something to an includefile.

The makefile should then always compile the above program prior to the actual compilation.

This way one would have the flexibility AND the compiletime decision between little and big endian?

This would make the build process more complicated and, worse, wouldn't work at all for cross-compiles where you usually can't run a program on the target machine (Linux->Dos with DosEmu perhaps being an exception ;-).

But fortunately this isn't necessary because GPC also provides the information, both as pre-defines and as constants -- look for `endianness' in gpc.pas.

I'd recommend to use the constants when possible and the defines only when necessary (e.g., when type declarations depend on them) because `ifdef' etc. is generally unsafer (e.g., you won't even detect syntax errors in the version of the code not for your current working system).

BTW, that's also how I wrote the endian conversion routines, to answer Orlando's question.

Frank