[M.-A. Lemburg]
> ...
> Also new in this snapshot is configuration code which figures
> out the byte order on the installation machine... I looked
> everywhere in the Python source code but couldn't find any
> hint whether this was already done in some place,
[Tim]
> There's a tiny bit of inline code for this in the "host byte
> order" case of structmodule.c's function whichtable. ...
[MAL]
> I looked there, but only found that it uses native byte order
> by means of "letting the compiler do the right thing" -- there
> doesn't seem to be any code which actually tests for it.
Here's the "tiny bit of (etc)":
int n = 1;
char *p = (char *) &n;
if (*p == 1)
...
> The autoconf stuff is pretty simple, BTW. The following code
> is used for the test:
>
> main() {
> long x = 0x34333231; /* == "1234" on little endian machines */
> char *y = (char *)&x;
> if (strncmp(y,"1234",4))
> exit(0); /* big endian */
> else
> exit(1); /* little endian */
> }
No, no, no -- that's one "no" for each distinct way I know of that can fail
on platforms where sizeof(long) == 8 <wink>. Don't *ever* use longs to test
endianness; besides the obvious problems, it also sucks you into illusions
unique to "mixed endian" architectures. "ints" are iffy too, but less so.
Test what you're actually concerned about, as directly and simply as
possible; e.g., if you're actually concerned about how the machine stores
shorts, do what structmodule does but use a short instead of an int. And if
it's important, explicitly verify that sizeof(short)==2 (& raise an error if
it's not).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4