Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mcgill-vision.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!ulysses!allegra!mit-eddie!think!harvard!bbnccv!bbncca!linus!philabs!micomvax!musocs!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: net.lang.c
Subject: Re: how has C bitten you?
Message-ID: <140@mcgill-vision.UUCP>
Date: Sat, 7-Sep-85 04:16:19 EDT
Article-I.D.: mcgill-v.140
Posted: Sat Sep  7 04:16:19 1985
Date-Received: Tue, 10-Sep-85 05:18:47 EDT
References: <228@investor.UUCP> <132@mcgill-vision.UUCP> <2702@sun.uucp>, <797@kuling.UUCP>
Organization: McGill University, Montreal
Lines: 60

>> ... so the two procedure calls in
>>	bar(0);
>>	bar((struct frobozz *)0);
>>are very definitely *not* equivalent.
>>	Guy Harris

>Is it also possible to give a NULL-pointer to a procedure as a parameter,
>if for example the procedure would return several values, and we are not
>interested in all of them?
>
>wait(0) works at least here (4.2BSD), but something like this does not:
>
>skip(fd, n)	/* skip n bytes om streams that don't allow lseek() */
>int fd, n;
>{
>	(void)read(fd, 0, n);
>}

     Let me be the 18th of  69 netters (we are a  leaf node so there's a
k-day delay, for some small integer k, between you and us)  to point out
that....

     Wait(0) works  because  the wait code *specifically* checks for a 0
argument.  I believe the code reads something like

	wait(stpointer)
	struct status *stpointer;
	{
	 ....
	 if (stpointer)
	  { *stpointer = ststruct;
	  }
	 ....
	}

     A lot of code (sigvec, for instance) works this way.  However,  for
calls like read(), where the lack  of interest  is a *very*  exceptional
case,  this  check  is  omitted.  Some machines, notably the 68K family,
will  catch  a  zero pointer  because  there's  no memory there.   Some,
notably VAXen,  will not.  However, for  syscalls involving writing into
memory, for most (-z format, see ld(1)) executable files,  attempting to
write into  address 0 will  fault (syscalls return EFAULT, user code get
SEGV errors).

     Read(fd,0,n)  *should* give you  a memory error  (EFAULT returned).
The only case I know  of in which it won't is when  you are running on a
VAX, so there is memory  at address 0  (it's usually the C startup  code
from crt0.o), and the executable file is in the old old old format which
doesn't do sharing of  text segments, so the text segment  is writeable.
In this case, read will happily overwrite the first n bytes  of the text
segment.   Normally (because that *is* the crt0 code, which  doesn't get
reentered), you won't notice unless n is big.
-- 
					der Mouse

{ihnp4,decvax,akgua,etc}!utcsri!mcgill-vision!mouse
philabs!micomvax!musocs!mcgill-vision!mouse

Hacker: One responsible for destroying /
Wizard: One responsible for recovering it afterward