Path: utzoo!utgpu!water!watmath!clyde!burl!codas!mtune!whuts!homxb!ho7cad!wjc
From: wjc@ho5cad.ATT.COM
Newsgroups: comp.bugs.sys5
Subject: Re: awk bug
Message-ID: <273@ho7cad.ATT.COM>
Date: 10 Feb 88 14:19:20 GMT
References: <672@pttesac.UUCP> <3748@megaron.arizona.edu> <2161@ttrdc.UUCP> <3763@megaron.arizona.edu>
Sender: nuucp@ho7cad.ATT.COM
Lines: 51
In-reply-to: rupley@arizona.edu's message of 8 Feb 88 10:49:58 GMT

In article <3763@megaron.arizona.edu> rupley@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