kwh@bentley.UUCP (KW Heuer) (04/05/86)
In article <678@bentley.UUCP> I wrote: >On the 3b2, neither text or data space is anywhere near address zero, >page zero has no interesting contents, yet it is readable. Apparently >this is so that programs that dereference NULL can be ported! (I wish >they'd at least make it a loader option, so it could be turned off...) I've been informed by e-mail that there may be such a loader option (-z). After much searching I found a manual in which it was documented. The acid test failed, though. On my 3b2/300 running SVR2.0 (swapping), the -z flag was silently ignored (the a.out files compared identical except for timestamp). Apparently this has been implemented in the paging version. (I still think it should be the default.) Incidentally, *NULL bugs are especially elusive on a vax, since address zero normally contains (short)0 (the entry mask for start). Bonus question: Why does tabs.c call strcmp(set_tab,"f(") ? Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
guy@sun.uucp (Guy Harris) (04/07/86)
> I've been informed by e-mail that there may be such a loader option (-z). > ... (I still think it should be the default.) YES! ABSOLUTELY! At the very least, ALL utilities for System V should be built with this flag, and the system NOT considered to pass QA unless these utilities do NOT drop core as a result of dereferencing a null pointer. (4.2BSD has fewer of these problems, but that's only because it has to run on a Sun which gives you no choice about getting errors on dereferencing null pointers. John Bruner posted some kernel and loader changes to give 4.2BSD a "-Z" option which functions like the S5 "-z" option - it makes an executable image which, when run, causes location 0 not to be mapped into the address space of the process. VAX/VMS, of course, does this by default.) > Incidentally, *NULL bugs are especially elusive on a vax, since address > zero normally contains (short)0 (the entry mask for start). Which fact caused some turkeys to write code for 4.1BSD which DEPENDED on this; it used NULL as the name of a null string! Needless to say, by the time this got running on a Sun, it was fixed.... > Bonus question: Why does tabs.c call strcmp(set_tab,"f(") ? Because "f(" happens to be at location 0 on the machine that the implementor was developing it on, and said implementor was too stupid to realize that the CORRECT test was "set_tab == NULL", and not 'strcmp(set_tab, "f(") == 0)'? Sometimes I think that every C language course should include a section on "The Use and Abuse of Null Pointers"... unfortunately, I have yet to see this mentioned in any such course's syllabus. > Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint Given the quality of too many C programs (and programmers), that title sounds like a thankless task at best.... -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.arpa (yes, really)
rbj@icst-cmr (Root Boy Jim) (04/07/86)
Sometimes I think that every C language course should include a section
on "The Use and Abuse of Null Pointers"... unfortunately, I have yet to
see this mentioned in any such course's syllabus.
Hey, even *I* don't dereference NULL pointers! However I do think that
software should be tolerant when passed such items. I seem to remember
that `printf' would say `<null>' or something to that effect when invoked
as `printf("%s",0)' (Guy would say `printf("%s",(char *) 0)').
> Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
Given the quality of too many C programs (and programmers), that title
sounds like a thankless task at best....
--
Guy Harris
{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
guy@sun.arpa (yes, really)
Perhaps we should call you `The Talking Lint' :-)
(Root Boy) Jim Cottrell <rbj@cmr>