Originally, functions assumed that the current location in the
file was correct and did not seek before reads. The Check
functions would seek back to the start after the read, so the
next function would have its expectation met. The file info
functions did not seek after the read, because mop and a.out
file data always starts immediately after the header.
CheckElfFile() broke this convention, seeking before the read,
and not after. The previous commit changes a.out functions to
seek before reading, and not after. Now this changes mop file
functions similarly, so all three work together.
mopFileRead() still assumes the current location in the file is
correct for reading data from a.out and mop files, and does reads
without seeking.
- Rework over complicated getMID with its double parameters and
unnecessary assignments to a simple badMID, modelled on N_BADMAG
- Both CheckAOutFileInfo & GetAOutFileInfo now always rewind the
fd before reading. They currently both leave the fd pointing
directly after the in file exec struct header, but that matches
the behaviour of similar methods
- Consistently handle swapped MID and AOUT magic values
We still have unnecessarily duplicated code here, but what is
here should be cleaner
The second stage of Ultrix loading is a struct which tells the
kernel things it needs for netbooting. Ultrix needs this and can't
use other servers like rarpd, bootparamd and bootpd. The only
other server needed is NFS.
I don't like how I wrote so much code to create a simple struct.
There should be a better way. But this works.
Ultrix 4.00 netload requires transfers to end with Memory Load
with Transfer Address. The load address must be present, though
image data doesn't have to be present.
GCC_NO_FORMAT_TRUNCATION -Wno-format-truncation (GCC 7/8)
GCC_NO_STRINGOP_TRUNCATION -Wno-stringop-truncation (GCC 8)
GCC_NO_STRINGOP_OVERFLOW -Wno-stringop-overflow (GCC 8)
GCC_NO_CAST_FUNCTION_TYPE -Wno-cast-function-type (GCC 8)
use these to turn off warnings for most GCC-8 complaints. many
of these are false positives, most of the real bugs are already
commited, or are yet to come.
we plan to introduce versions of (some?) of these that use the
"-Wno-error=" form, which still displays the warnings but does
not make it an error, and all of the above will be re-considered
as either being "fix me" (warning still displayed) or "warning
is wrong."
