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: svn commit: r890580 - in /apr/apr-util/branches/1.4.x: crypto/apr_crypto.c crypto/apr_crypto_nss.c crypto/apr_crypto_openssl.c include/apr_crypto.h include/private/apr_crypto_internal.h test/testcrypto.c
Date Sun, 17 Jan 2010 12:01:53 GMT
On 1/16/2010 3:11 AM, Graham Leggett wrote:
> On 15 Dec 2009, at 8:52 PM, William A. Rowe Jr. wrote:
>> My gut says hold off releasing apr-1.4.1 for just a bit to see if this
>> feature would be the solution.
> I've come up with r899910, and it seems to work. Can you give it the
> once over for me if possible?

Ok; I'm 100% convinced this doesn't go into apr-1.4, once we sort that whole
hash/pool lifetime problem, 1.4 apr is baked.

But I'll review your trunk commit... I note you didn't do any autoconf tests
so you aren't thinking in the same direction as I was.

Essentially, An incomplete structure type looks like;

struct apr_foo_t
    apr_pool_t    *foo;
    apr_foo_ctx_t *bar;
    char          incomplete[];

Whoops - indeterminate length; the user can't get sizeof(apr_foo_t), can't
allocate one themselves, etc etc.  The program fills out the rest of the
structure in include/private/ declarations, so everything is fine.

Now to retrieve foo, we need to either be on a compiler where the above
does not fault, or provide an accessor that knows the platform alignment.
E.g. downcast to a complete type, but don't do so in a dangerous way.

I will take a close look at your patch, and contribute the implementation
that determines if it's a modern or classic K&R compiler, and work out
how to resolve the first few members of a struct.  It's not easy but I'm
beginning to believe it's absolutely necessary for performance and the
code integrity.  It might not be implemented until rev 2, given that we
want to expose all our apr_xxx_t's to this introspection ;-)


View raw message