You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Graham Leggett <mi...@sharp.fm> on 2010/01/16 10:11:20 UTC

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

On 15 Dec 2009, at 8:52 PM, William A. Rowe Jr. wrote:

> Hold off... it is not incompatible (well, you can slide *errfn to the
> last element of the structure, but otherwise)...
>
> What we need is a way to document *and validate* incomplete C types
> into complete C types with structures.  The approach in apr_general.h
> or somewhere similar would be;
>
> #if APR_HAVE_VOID_INCOMPLETE_TYPES
> #define APR_TYPEDEF_STRUCT(type, incompletion) \
> typedef struct type {
>    incompletion
>    void unk[];
> } type;
> #else
> typedef struct type type;
> #endif
>
> and then within apr_foo.h, an particular example;
>
> APR_TYPEDEF_STRUCT(apr_foo_t, \
>    apr_pool_t    *pool;      \
>    apr_foo_ctx_t *ctx;       \
> )
>
> or something very closely resembling this.  Need to work out the exact
> mechanics that aren't subject to macro problems, and the autoconf  
> magic
> to detect the availability.
>
> 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?

Regards,
Graham
--


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

Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
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 ;-)

Bill