awk bug

[wjc at ho5cad.ATT.COM]

In article <3763 at megaron.arizona.edu> rupley at arizona.edu (John Rupley) writes:
>This is a bit off the thread of the awk bug, but if the 3B20 can't 
>handle a NULL pointer in awk, how does it handle C code like:
>	   .
>	   cmpstr(strchr("abcdef", 'g'), "hijk")
>	   .
>cmpstr(s, t)
>char *s, *t;
>{
>	   [standard stuff]
>}
>

I  think you've misinterpreted   slightly the earlier poster's  (Levy)
remark about why dereferencing a null pointer caused a problem in awk.
It's  not that the  machine can't handle it.   In fact, it goes beyond
the call of C, so to speak.

A pointer whose value is zero is defined  as a  pointer which does not
point at any  valid object.   It  just   so happens  that   if you  do
erroneously reference it  on a  3b20, you get   its  famous "f(".  For
example, if your "[standard stuff]" was a

	printf ("|%s|\n", s);

it would yield

	|f(|

Of course, your code would contain  a portability  bug in such a case,
since it would be illegal  to try to  use that  null pointer.  Usually
fixed by this timeworn macro: #define VIS(s) ((s)?(s):"").

Contrast this with doing  the same thing  on (a) original  VAX series,
which happened to always have a null character at location zero, so it
general worked out (but left you with a portability  time bomb), (b) a
Sun, which dumps core if you dereference a null at  all (think of this
as  runtime  validity checking  :-); (c)  VAX 86xx, where  you find at
location zero  a string something   like "}^A^C"  (which   looks quite
attractive when it spills out on the screen).

(I'm beating a dead horse now ...)  There are a  couple of helpers for
this null pointer business some places.  Some C compilers  have a flag
which makes  the low bytes  of the program  unreadable.  This sort  of
acts  like a  Sun in this  respect, but  with less trauma.  Also, some
implementations of the printf() family explicity convert null pointers
to null strings for %s.

	Bill Carpenter
	(AT&T gateways)!ho5cad!wjc
	HO 1L-410, (201)949-8392, OCW x4367