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... 
>: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