Re: [PATCH] libtrivfs variable -> functions

[Neal H Walfield]

Looking through old mail, I see that I never replied to this.

> > This patch turns the variables in libtrivfs into function calls. Thus,
> > when writing a translator, it is no longer required to say: 
>
> I'm trying to understand your patch (espcially since I'm trying to get 
> trivfs sorted out in my head).

I am not sure if trivfs is the best place to start.  Although trivfs has
trivial in its name, it is far from the truth.  In fact, it is designed
to provide for a translator that is listening on multiply port sets; a
fairly advanced, non-unix, non-filesystem concept.  Thus, consider
starting with libnetfs and nfs.

> It appears to:
> 
> 1) Clean up the syntax a little bit.

Exactly.

> 2) Avoid the runtime overhead of dereferencing a pointer.

Nope.  In a shared library, we have to call the function indirectly
anyway (recall, -fPIC => position independent code).

> I'm curious as to why you went through the effort. =)  #2 doesn't seem 
> like it would be worth it, so I'm wondering if the former syntax was 
> prone to typing errors, or if I've completely missed the point.

The former seemed way too inconsistent with other interfaces and was
prone to errors.  Specifically, we were doing the following:

        if (trivfs_open_hook)
          (*trivfs_open_hook) (...)
        else
          {
            ...
          }

As we promise the user a default implementation, the else branch must
always be the same _every_ time that we would have called
trivfs_open_hook.  However, there is one place in the library that we do
forget to do this.

pgpObXzN8FbZT.pgp
Description: PGP signature