Re: apr_stat

[Jim Jagielski <ji...@jaguNET.com>]

Wilfredo Sanchez wrote:
> 
> >
> > Well since it's a public type, we are screwed on binary compatibity if
> > we wait for those decisions until later.  Love reading that sys/stat.h
> > header :-/  I'm actually interested in any feedback from Fred or Brian,
> > if there are other things we should have our eyes on.
> 
>    You can pad the structure with some reserved field space.  We do that
> with device driver API, and it's saved us a few times.
> 

+1 on this. reserved is your friend :)

-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
          "Casanova will have many weapons; To beat him you will
              have to have more than forks and flatulence."

extending finfo (was: Re: apr_stat)

[Greg Stein <gs...@lyra.org>]

On Sat, Jan 20, 2001 at 09:32:39AM -0500, Jim Jagielski wrote:
> Wilfredo Sanchez wrote:
> > > Well since it's a public type, we are screwed on binary compatibity if
> > > we wait for those decisions until later.  Love reading that sys/stat.h
> > > header :-/  I'm actually interested in any feedback from Fred or Brian,
> > > if there are other things we should have our eyes on.
> > 
> >    You can pad the structure with some reserved field space.  We do that
> > with device driver API, and it's saved us a few times.
> 
> +1 on this. reserved is your friend :)

Actually, "reserved" can be troublesome because it might not be enough
space, the alignments of the fields could off (e.g. reserve a long, want a
short), we may reserve too much, etc.

Microsoft actually handled this very well. You pass the size of your
structure (as a param, or as the first field of the structure). Based on the
size of the structure, APR can determine what the app was compiled against
and what it can accept.

For example, let's say we ship 1.0 with:

  struct foo {
      int a;
      int b;
  };

Some app (call it A1) compiles against that, and passes sizeof(struct foo)
to the call (let's say it is 8 bytes).

In V2, we extend the structure:

  struct foo {
      int a;
      int b;
      char *c;
      long d;
  };

A1 is still passing 8, so APR knows it was built against the V1 structure
and just fills in "a" and "b".

Along comes A2 and it passes 16 for the size. APR fills in all four fields.

In our apr_stat case, note that the size of the structure also tells APR
whether/how to interpret the "wanted" bits and whether to even *bother* with
fetching the data for "c" and "d".

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/