apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject RE: Only ONE back-compat hole discovered.
Date Thu, 27 Jun 2002 16:18:08 GMT
At 02:42 AM 6/27/2002, Sander Striker wrote:

>The offending file is include/apr_allocator.h, a relative youngster, 
>introduced
>on 15 march 2002.

I ment to back up and retitle the post ... thanks for pointing that out...

> >  85                  apr_memnode_t *next;
> >
> >  86 striker  1.6     apr_memnode_t **ref;
> >
> >  87 jwoolley 1.3     apr_uint32_t   index;
> >
> >  88 striker  1.6     apr_uint32_t   free_index;
> >
> >  89 jwoolley 1.3     char          *first_avail;
> >  90                  char          *endp;
> >  91              };
> >  92
> >  93              #define APR_MEMNODE_T_SIZE 
> APR_ALIGN_DEFAULT(sizeof(apr_memnode_t))
>
>The options on this are:
>
>   1) move the parts of apr-util that are dependent on apr's private types 
> to apr.
>      [bucket allocator, which implies moving buckets to apr]

Nak.  I think we like that segregation.  apr-util is a moving target, while 
apr seems
to have settled into even growth.

>   2) loose the dependency altogether, ending the short life of, the 
> current implementation
>      of, the bucket allocator.

No.  All I'm suggesting is accessor functions.  With accessors, you can add new
ones for new members, and safely return a pointer to an opaque type when a new
memnode is created.  The size is simple too, return it in a function.  I 
had to create
some overhead sizing functions for apr_rmm for exactly that reason.

>   3) I could have appended the new fields at the end of the structure.
>      *slaps self for not having done that*

:-)

>      Then, if we would choose to have a function to return the size of 
> apr_memnode_t,
>      instead of a macro, it would have just worked.  The only fields the 
> bucket allocator,
>      and any other allocator, rely on are first_avail and endp.  If we 
> export that as
>      a public type and have a private type with the rest of the fields, 
> combined with
>      a size function, we won't face this problem again.

Bingo... add to the end if we must, and if it must remain a transparent type.
But the size of the structure better come from a function that knows the 
current
allocator implementation.

>   4) require apr and apr-util to be version dependent.

No, that wouldn't be unreasonable either.  The point of the exercise was to 
decide
that I could replace, say, some broken apr_proc or apr_mutex code, and nobody
would be harmed in the process :-)

But if we presume that they could be disjoint, we will do a better job with 
version
compatibility for 3rd party authors.

>      *puts on asbestos suit...*

The point of the original post is that we are nearly there, we can start 
enforcing
version compatibility.  That is something to cheer, and the allocator 
issues is
just an example of what can bit us as we move forward (and something to mop
up a bit :0)

Bill



Mime
View raw message