15 May
2005
15 May
'05
8:49 p.m.
[quoting botches fixed, and vertically compressed, manually -dM]
That's REALLY weird, endian issue or is that just undefined behavior
in the C spec?
It's undefined behaviour, in the strict sense of "undefined" used in
the C spec. "3.1 d00d j00 l0se" would be just as conformant to the C
spec, as would a segfault (or whatever the equivalent is under the OS
in use). Of course, each implementation can be looked on as a spec
that defines behaviour for all the stuff that's undefined in the C
standard, but from that point of view there are as many specs as there
are implementations, so there is no "the" spec.
The difference observed in gcc-compiled code between x86 and MIPS is
probably related more to argument-passing conventions than endianness
issues, especially since that report didn't say whether the MIPS was
running LE or BE (MIPS can be either).
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
>>> int i = 0; printf("%d %d
%d\n",i++,i++,i++);
>> IIRC it should output: 2 1 0
> Not on my system: 0 1 2
GCC produces 2 1 0 on x86 and 0 1 2 on MIPS.