26 Jul
2024
26 Jul
'24
1:44 a.m.
(resending with the correct HECnet address)
On Jul 25, 2024, at 12:16 AM, Chris Hanson
<cmhanson(a)eschatologist.net> wrote:
I haven’t successfully used SIMH networking on macOS yet but one of the things that I’ve
seen in building SIMH with an Xcode project that I created was that there is *a lot* of
type confusion in the codebase nowadays: It has lots of use of int, int32, etc. that
should actually be one of ptrdiff_t, ssize_t, size_t, off_t, and so on.
While I appreciate the desire to be compatible with older C89 compilers, this is one of
those things that opens one up to subtle bugs on 64-bit platforms—especially when trying
to build for a mix of LP64 and ILP64 platforms. I think the better way to handle that
would be to provide cover definitions for pre-C99 compilers and pre/non-POSIX systems, so
the codebase can use the correct types throughout.
I suppose, but Mark P has a point: it doesn't make a whole lot of sense to do major
editing on the codebase if it isn't broken.
Clearly, ptrdiff and ssize are not issues, because nothing in the SIMH suite creates data
structures that are more than 32 bits in size. If we had Alpha emulation for machines
that support more than 4 GB of physical memory (if there are any Alphas for which that is
true) then for that case the use of size_t would matter, but clearly not for anything
else.
Off_t is unlikely to be an issue either, unless you needed a virtual disk bigger than 4
GB. Those might, just barely, be supported on VAX (MSCP) and maybe some PDP-11 OS as
well, though I know for a fact that RSTS/E tops out right at 4 GB and probably never
actually had real disks that big.
Another pretty serious problem is that a lot of
platforms set USE_SHARED rather than just USE_NETWORK and wind up “wrapping” the libpcap
API, loading the library with dlopen(3) and calling through stubs that have their own
prototypes defined. This is extremely dangerous because something like libpcap can adjust
its signatures and headers simultaneously to manage source and binary compatibility while
changing behavior at the same time. This is especially important when something like
libpcap is provided by the OS.
Um, the dlopen stuff seems to be an option, and it's only there on Linux as far as I
can tell. Is it actually a problem? I'm not sure why it's there, I'll admit
that.
...
Similarly, the conflation of the various different integer types risks becoming a field
full of land mines. While one can argue that SIMH is never dealing with enough data to run
into 32-bit truncation on 64-bit systems so it’s not worth worrying about, this is another
area where “it works fine, don’t change it” is just fine right up until the point where it
isn’t. It’d be best to be consistent with POSIX here (rather than self-consistent) and to
provide a thin adapter layer for pre-POSIX systems.
It does seem that you're hypothesizing possible breakage but I don't see any way
that it can happen in reality.
Remember that SIMH works on 32 bit systems. It follows that the 32-bit types should not
be a problem even if new code would not do it that way.
paul