An Ubiquitous C bug

[Alvin "the Chipmunk" Sylvain]

In article <s64421.664471332 at zeus> s64421 at zeus.usq.EDU.AU (house ron) writes:
> Here's a bug which exists in every single DOS C compiler I can find,
> and may also exist on others:
> 
> In the small memory model, it is possible for a function to have the
> address NULL.  E.G.:
[... example nuked ...]
> This sort of program CAN print the message if x() happens to be
> loaded by the linker at the start of the code segment (address 0).
> The compiler seems unable to prevent the linker from loading
> functions at that address.  Perhaps on some machines, NULL should
> _not_ be 0?  After all, it would be easy to prevent functions being
> loaded at address 1 (for example) on a DOS machine.

I think it would be more correct and portable if the DOS linker avoided
loading the function at address 0.  Maybe there should be a way the C
compiler can inform the linker to avoid this practice.  There are too
many implementations that joyfully interchange NULL with 0 with no thot
to this problem.  (Altho, the compiler is supposed to be smart enuff to
recognize a 0 in a pointer context and convert it to a "null pointer",
whatever it happens to be.)

In fact, unless I'm mistaken, I think NULL is *defined* to be 0.  NULL
and 0 are *defined* to be an invalid address.  Therefore, if the func-
tion (or anything else) happens to actually have a valid address of 0,
then _something_ is _broken_.

(Altho, again, this doesn't really impact the internal representation.
The compiler should do the conversion.  But I don't trust a compiler to
recognize {ptr1 = 0; ptr2 = ptr1;} and know somehow that at run-time the
0 must be changed to an internal value for NULL.  I've seen compilers
that would recognize {y = 5/0;} and flag it: but {x = 0; y = 5/x;} will
work every time.)

Put another way: "valid address == 0" is a contradiction in terms.
--
asylvain at felix.UUCP (Alvin "the Chipmunk" Sylvain)
=========== Opinions are Mine, Typos belong to /usr/ucb/vi ===========
"We're sorry, but the reality you have dialed is no longer in service.
Please check the value of pi, or see your SysOp for assistance."
=============== Factual Errors belong to /usr/local/rn ===============
UUCP: uunet!{hplabs,fiuggi,dhw68k,pyramid}!felix!asylvain
ARPA: {same choices}!felix!asylvain at uunet.uu.net