stat(), lstat() again.

[William Roberts]

In <4038 at ursa-major.SPDCC.COM> dyer at spdcc.COM (Steve Dyer) writes:

>In article <3422 at dftsrv.gsfc.nasa.gov> jim at jagmac2.gsfc.nasa.gov (Jim Jagielski) writes:
>]Well... if I do the following, lstat() doesn't work:
>]	struct stat *sbuf;
>]	lstat("/unix", sbuf);
>]But this DOES:
>]	struct stat sbuf;
>]	lstat("/unix", &sbuf);
>]
>]It looks like in case #1, sbuf is pointing somewhere dangerous and when lstat
>]is called, memory is destroyed... 

>OK, so where's the bug?  You've not understood the C language.
>Just where do you think sbuf is pointing to in the first example?
>If you don't assign a value to a variable, how can you expect to
>use its value as something meaningful?

Or, slightly less harshly, you have some further nuances to learn about how
to read the UNIX section2 & 3 manual pages.

In particular, when you see pointers being used you must ask yourself
"Who is allocating the memory for this?" - in the case of pointers
passed as arguments, the answers is ALWAYS that the caller allocates the
memory since C uses call by value. When you see pointers to pointer as
arguments, or pointers as return values then there is a possibility that 
the called routine will do the memory allocation (e.g. getpwuid).

True system calls ALWAYS use pointers (because they are small and easy to
pass into the kernel) and ALWAYS require the user process to provide the
memory. 
-- 

William Roberts                 ARPA: liam at cs.qmw.ac.uk
Queen Mary & Westfield College  UUCP: liam at qmw-cs.UUCP
Mile End Road                   AppleLink: UK0087
LONDON, E1 4NS, UK              Tel:  071-975 5250 (Fax: 081-980 6533)