I wrote it and i edited wikipedias article which had a terrible code and added mine, but i'm still not sure about my code, is it SCALABLE ENOUGH?
#include <stdio.h>
int main() {
union {
int s;
char c[sizeof(int)];
} un;
const char *endianess[[] = { "big endian", "little endian" };
>>12
Not with line buffering, but not even yoshi can save your data if you're on a system that doesn't have that behavior and you hit ^C instead of ^D.
>>13
Unless you're on Windows, then it's ^Z-Enter. (Stupid Windows.)
Name:
Anonymous2007-06-27 20:13 ID:K2AuVMv6
oh, missed >>11
Suppose you're doing this during an auto-configuration script to test which platform to build an executable with.
>>15
What kinds of shitty compiler needs you to tell it the byteorder of the current machine?
(Also, show me a 'scripting' language that allows pointer/union tricks, but doesn't have a constant that tells you the byteorder.)
Name:
Anonymous2007-06-27 21:59 ID:2m8+eLJ2
makefile/build-process should provide a preprocessor macro of what endianness a long with all the other platform-dependant nonsense
Name:
Anonymous2007-06-27 23:39 ID:K2AuVMv6
>>16
Lots of algorithms are byte-order-dependent, and moreover, they need to be compiled with different compilers on different systems with different endianness. Sure, many compilers identify endianness in some manner, but it's far from portable, and often the simplest route to take is to figure it out for yourself.
It might seem stupid to start with, but every once in a while, it proves to be an extremely handy tool to have strapped on your hacker belt.
Name:
Anonymous2007-06-27 23:43 ID:mnQcz8y0
It still doesn't make any sense to do it at runtime, since the machine isn't going to change its endianness depending on whether it's executing the compiler or your program.
Name:
Anonymous2007-06-27 23:44 ID:ysL8Ns/j
>>18
no, none are... just the implementations might be.