Adriaan van Os wrote:
Frank Heckenbach wrote:
It would be nice if GPC were to allow i:=word32( 'abcd') also (e.g. in --macpascal mode), but this is not a necessity.
This would have to make an implicit decision about endianness,
Can't the compiler just look at __BYTES_BIG_ENDIAN__ and __BYTES_LITTLE_ENDIAN__ ?
Sure. But I mean we'd have to make a decision first how to handle it. Should it be always big-endian (like Peter's macro), or use the actual target's endianness (so it gets the same memory layout as the character array)? With the macro, this decision is left to the programmer. (Though it might not actually matter if the same conversion is used for all values.)
and it might be problematic if in the future GPC will work with Unicode (or any other >8 bit charset), since 4 characters won't fit in a 32 bit integer.
That would give rise to some very interesting problems anyway. For binary compatibility with existing API's (on many platforms), we will always need some 8-bit char type. Then, how do you indicate that a string constant is composed of either 8-bit or (e.g.) 16-bit characters ?
I haven't spent many thoughts about it (and don't plan to implement it soon). Perhaps just another option (but I'm not sure yet of the implications).
Frank