Mail Archives: djgpp/1997/06/06/06:04:38
Chris Croughton (crough45 AT amc DOT de) wrote:
: OK, it's only (in the above case) 5 out of 65536 times, but
: if you're using it to index an array you can guarantee those
: cases will occur and cause a SEGV at exactly the wrong time.
Or, more likely, alter the value of some critical variable completely
transparently - harder to debug than a segmentation fault :)
I always make a point of checking, double checking, triple checking
anything like this as I write it into the code, and if something weird
happens, this sort of array indexing would be the first place I'd look.
--
George Foot <mert0407 AT sable DOT ox DOT ac DOT uk>
Merton College, Oxford
xual". There're a few like that. Not all Unices
run on bytesexual machines. (In fact a unix of some kind or other can be
found for nearly every modern CPU type.) 68K machines and Intel machines
are stuck with one endianness.
Unix manages to handle bigendian networks and big and little endian
machines because Unix compilers, including notably GCC, define endianness
in an endian.h header file, and these compilers compile code, including
themselves, correctly for either kind of machine.
Look in your DJGPP directory, somewhere deep deep in the include directory
hierarchy, for an endian.h, it defines something as LITTLE_ENDIAN
because DJGPP is run on Intel CPUs. In fact, it has macros LITTLE_ENDIAN,
BIG_ENDIAN, and even some for unusual mixed-endian 32-bit machines that
order the bytes of an lword funny ways like "4132". Then it defines
MACHINE_ENDIAN(?) as LITTLE_ENDIAN on intel CPUs.
>> I'm sure it's possible too *override* the natural order for the
>> processor, but whether a particular system is big or little endian is
>> determined by the processor - ALWAYS.
>
> No, it is not directly possible to "override" the endianness of the CPU.
Unless it's a bytesexual CPU.
> It is _always_ possible to use functions to store and retrieve data in a
> fixed endianness, e.g.
>
> void
> store_little_16(short i, char *p)
> {
> p[0] = i & 0xff;
> p[1] = (i >> 8) & 0xff;
> }
>
> short
> load_little_16(char *p)
> {
> return (p[0] & 0xff) | ((p[1] & 0xff) << 8);
> }
>
> Although both functions work properly regardless of the endianness of
> the CPU, they might be replaced by simple macros on little-endian CPUs:
> # define store_little_16(i,p) *((short *)(p)) = (i)
> # define load_little_16(p) *(short *)(p)
> Replacing the functions above by macros is not feasable, because both
> functions evaluate their arguments more than once, i.e.
> store_little_16(*sp++, *lesp++) will not work correctly.
>
> It may be this what you mean.
These are needed to get machines of different endianness to read each
others' files, e.g. by Internet. This is particularly common for unices,
which run on many CPUs and can read each others' files. This doesn't
matter for text files but it does for binary files with integers and longs
stored in them. On the other hand, this endianness issue is likely why
most files intercommunicated among unix boxes are ASCII text, ranging from
.newsrcs to scripts and the like.
--
.*. Where feelings are concerned, answers are rarely simple [GeneDeWeese]
-() < When I go to the theater, I always go straight to the "bag and mix"
`*' bulk candy section...because variety is the spice of life... [me]
Paul Derbyshire ao950 AT freenet DOT carleton DOT ca, http://chat.carleton.ca/~pderbysh
- Raw text -