🚀 go-pugleaf

In article <8904040510.AA15711@thor.acc.stolaf.edu> mike@THOR.STOLAF.EDU (Mike Haertel) writes:
>In the various binutil programs, reading just an int from the
>beginning of a file to get its magic number is idiotic.  What
>if the magic number isn't an int, or isn't right at the beginning?
>If the programs were properly written they would read a struct exec,
>rather than making a kludgy assumption about its internal format.

I agree.  Along similar lines, I was horrified to learn while hacking
"strip" that its error-checking malloc interface returned an int!  I
mean, dang!  Also, from what I've seen, porting a lot of these things
to a 16-bit int environment would be almost a lost cause (though probably
possible for the dedicated).

Then again, it is free.


-- 
Mike McNally                                    Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5                    phone: 408 370 2233

            Where equal mind and contest equal, go.

From article <8904040510.AA15711@thor.acc.stolaf.edu>, by mike@THOR.STOLAF.EDU (Mike Haertel):
> In the various binutil programs, reading just an int from the
> beginning of a file to get its magic number is idiotic.  What
> if the magic number isn't an int, or isn't right at the beginning?
> If the programs were properly written they would read a struct exec,
> rather than making a kludgy assumption about its internal format.

Concrete example time:

Assume the following architecture:  9-bit bytes.  (Yes Virginia, these
						   things *do* exist!)

				    int is 2 bytes (18 bits).

Now, assume a file is written on a machine with 8-bit bytes.  A *assumption*
is that two adjacent bytes (properly aligned) are equivalent to, and in 
fact *are*, an int (assuming 16-bit ints).  On a machine like this, one
can read a file, and be fairly assured that the first two characters (bytes)
in the file are *punning* an int.  Apparently considerable code makes
just this assumption.  However, this is *highly* non-portable code.

The actual example, taken from "real life":

        8-bit byte machine                     9-bit byte machine

 .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.     .-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.
 |7|6|5|4|3|2|1|0|7|6|5|4|3|2|1|0|     |x|7|6|5|4|3|2|1|0|x|7|6|5|4|3|2|1|0|
 `-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-'     `-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-'
 |               |               |     |                 |                 |
 |<--  Byte 1 -->|<-- Byte 2  -->|     |<--  Byte 1   -->|<--   Byte 2  -->|


Now, it is obvious that *assuming* a 16-bit int is equivalent to two
adjacent chars is not portable.  If it were, then

		7654321076543210  would be equivalent to
		x76543210x76543210, which is obviously not the case.

I have a machine that does exactly this (the 9-bit char case).
(Another issue, not mentioned here, is that on this machine
 0xff...ff != -1.   In fact, -1 == 0xff...fe.  Yes, that's one's
 compliment.)

The moral of this story, boys and girls, is 
	     "It's not (yet) a two's compliment, 8-bit world!"
or perhaps
	     "Portability is a bit more complicated than you think!"

-- 
John G Dobnick
Computing Services Division @ University of Wisconsin - Milwaukee
INTERNET: jgd@csd4.milw.wisc.edu
UUCP: <backbone>!uwvax!uwmcsd1!jgd

"Knowing how things work is the basis for appreciation,
and is thus a source of civilized delight."  -- William Safire