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
