learning dragonfly or C...
George Georgalis
george at galis.org
Thu Nov 11 14:23:10 PST 2004
On Thu, Nov 11, 2004 at 02:04:48PM -0800, Matthew Dillon wrote:
>:
>:> This brings up an interesting ancillary issue in that you might also
>:> see a very experienced C programmer use a slightly different sort
>:> of construction, like this:
>:>
>:> struct vnode *vp;
>:> struct vnode *nvp;
>:>
>:> if ((error = ckpt_fhtovp(&vnh->vnh_fh, &nvp)) != 0)
>:> return error;
>:> vp = nvp;
>:> /* nvp ignored, vp used from here on */
>:>
>:> Care to take a guess at why advanced C programmers use this construction
>:> instead of simply passing &vp ?
>:>
>:> -Matt
>:
>:well not knowing what vnh_fh or ckpt_fhtovp is, sets me back a bit, but
>:I'll guess:
>:
>:...need more info...
>:http://fxr.watson.org/fxr/source/sys/ckpt.h?v=DFBSD
>:
>:is it a buffer to throw out illegal file handles inherited by NFS?
>:
>:// George
>
> Nope. Ignore the actual function names and ignore the function of
> the code, its irrelevant. Just focus on the question: Why is
> &nvp being passed to a function and then vp assigned to nvp when
> one could simply pass &vp to the function and get rid of nvp entirely?
>
> Let me modify the example a little:
>
> struct fubar *blah;
> struct fubar *nblah;
>
> getmafubar(&nblah);
> blah = nblah;
>
> blech = blah->this + blah->that - somefunction(blah);
> and_other_random_things_using(blah);
>
> blah blah blah...
>
> Ok, so, the question is, why would an advanced C programmer every
> want to create a separate variable to pass the address to a function
> and then simply assign the result back to the first variable and never
> use the second variable again?
>
> -Matt
If it's not to protect *blah memory from illegal getmafubar() data,
then my next guess is a debugging trap, so if getmafubar() fails, &blah
will retain state data from before the error? (not so subtle hint at
checkpt.c line 487)
// George
--
George Georgalis, systems architect, administrator Linux BSD IXOYE
http://galis.org/george/ cell:646-331-2027 mailto:george at xxxxxxxxx
More information about the Kernel
mailing list