Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!cbosgd!ihnp4!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: comp.unix.wizards
Subject: Re: HELP! File status checking in C
Message-ID: <2041@ttrdc.UUCP>
Date: 18 Dec 87 00:16:42 GMT
References: <10869@brl-adm.ARPA> <142700021@occrsh.ATT.COM>
Organization: AT&T, Skokie, IL
Lines: 38
Summary: buf better point to some storage!

In article <142700021@occrsh.ATT.COM>, rjd@occrsh.ATT.COM writes:
>  The syntax is
> 
> stat(filepathname, buf);
> or
> fstat(filedescriptor, buf);
> 
> buf is defined as "struct stat *buf;" after #include'ing <sys/types.h> and
> <sys/stat.h>

Ahem, "buf" in this case had better point to some storage, e.g.

	struct stat *buf;
	struct stat buff;
	buf = &buff;

	retval=stat(name,buf);

or better yet omit the pointer and

	retval=stat(name,&buff);

If you just declare

	struct stat *buf;

and that's it, buf will "point" to an undefined place.  When stat() sees this,
if you're lucky buf will contain an address outside of your process space and
your program will immediately core dump, saving you from further harm.  
Or, more mysteriously, the program may seem to work correctly but quite likely
will subtly corrupt other data in the program.

N.B.: Lint will catch this error, saying that buf has been used before set.
-- 
|------------Dan Levy------------|  Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
|         an Engihacker @        |  	<most AT&T machines>}!ttrdc!ttrda!levy
| AT&T Computer Systems Division |  Disclaimer?  Huh?  What disclaimer???
|--------Skokie, Illinois--------|