jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) (09/18/90)
Well, 1st of all I want to apologize for the hubbub I created with my
premature posting about the behavior of stat() and lstat(). 10 minutes
after my posting, I figured out that the problem was in the way some
of the compilers I'm used to return struct's and unions. I quote
from one:
"For compatibility with the pcc implementation of C, returning a structure
or union from a function is performed in a 'non-reentrant' fashion. A struct
or union return value is returned by copying the return value into a static
variable in the fucntion. A pointer to this variable is then returned. If a
pointer was used as an argument to the function, then the pointer is set
equal to the returned value. If the argument was a structure, the calling
function will use the returned pointer to copy the static variable."
Hence, it made no difference WHERE the pointer pointed, it was set equal
to the struct that stat and lstat return. So the pointing to NULL is
not it at all, but in the way the compiler returns structs.
I've used this compiler for a while and was used to this way of doing it.
When I starting porting to A/UX cc, this behavior (which is compiler
dependant) the problem arose. Before really thinking about the code,
I wrote the posting to comp.unix.aux... 10 minutes after the posting
I started figuring out what was going on... of course, by then it was
too late.
It was a long time since using lstat() and stat() which return int
and the struct in the argument list. Anyway, this has reopened my eyes
to how tricky C is as far as portability... Even old dogs can (re)learn
(not so new) tricks.
--
=======================================================================
#include <std/disclaimer.h>
=:^)
Jim Jagielski NASA/GSFC, Code 711.1
jim@jagmac2.gsfc.nasa.gov Greenbelt, MD 20771
"Kilimanjaro is a pretty tricky climb. Most of it's up, until you reach
the very, very top, and then it tends to slope away rather sharply."dyer@spdcc.COM (Steve Dyer) (09/19/90)
In article <3437@dftsrv.gsfc.nasa.gov> jim@jagmac2.gsfc.nasa.gov (Jim Jagielski) writes: ]"For compatibility with the pcc implementation of C, returning a structure ] or union from a function is performed in a 'non-reentrant' fashion. A struct ] or union return value is returned by copying the return value into a static ] variable in the fucntion. A pointer to this variable is then returned. If a ] pointer was used as an argument to the function, then the pointer is set ] equal to the returned value. If the argument was a structure, the calling ] function will use the returned pointer to copy the static variable." Sigh. This has nothing to do with stat or lstat. *NEITHER* returns a struct-- both return ints, like all system calls. They take a pointer to a struct as their second argument. This is NOT addressed by the paragraph you quote here. The "reentrancy" problem refers to subroutines which have a struct as their returned value. stat and lstat and all system calls do not behave that way. >Hence, it made no difference WHERE the pointer pointed, it was set equal >to the struct that stat and lstat return. So the pointing to NULL is >not it at all, but in the way the compiler returns structs. No. You're wrong. You're confusing what "return" means. >10 minutes after the posting I started figuring out what was going on... Not yet you haven't. >of course, by then it was too late. Still is. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu