apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@apache.org>
Subject Re: Opaque types [was apr_mmap_t]
Date Mon, 25 Nov 2002 13:46:21 GMT


On Mon, 25 Nov 2002, William A. Rowe, Jr. wrote:

> At 11:51 PM 11/24/2002, rbb@apache.org wrote:
> >On Sun, 24 Nov 2002, William A. Rowe, Jr. wrote:
> >>
> >> Obviously, this is skeletal.  It provides that all functions are exported,
> >> and some simple functions may be inlined.
> >
> >I tried to snip some of this, but I couldn't.  This is bogus.  Your header
> >with the inline header needs information that is private to the APR
> >internals.  That means that it can never be included from any file that is
> >public.  At the end of the day, what you are describing above is
> >completely impossible.
>
> Obviously it marries the app to the explicit version of APR.  That is the
> downside of inlining otherwise innocuous operations.

No, it does much more than that.  It completely removes the incompleteness
of the type.  Think it through.  The header that has the inline function
(the private header) needs to have full access to the internals of the
type.  The public header CAN'T have access to the internals of the type.
In order for the inlining to work, the private header needs to be included
from an external file (or the public header, which is the same thing).
This means that once you track it all back, the app has access to the
definition of the incomplete type, making it no longer incomplete.

If you can somehow make this work without removing the incompleteness of
APR, then cool.  But, AFAICS, it isn't possible, because what you want to
do can't be done with incomplete types.

> >> I don't believe what you suggest is portable.  Of course my VC is very happy
> >> to parse a struct def with a pointer to an incomplete type anywhere within
> >> the structure, or an undefined array at the *end* of the structure.  But since
> >
> >Will, please, that is just completely bogus.  Are you honestly telling me
> >that you believe that there is a compiler that doesn't know how to put a
> >pointer to an incomplete type inside of a structure?  If so, then Apache
>
> No, I'm stating that having a partially complete structure is not portable.
>
> The question of an embedded pointer to the apr_foo_internal_t isn't an
> issue, except that the user can allocate an apr_foo_t.  Since I just got
> done earlier today expressing that we don't care that users can shoot
> themselves in the foot, I really don't have any argument to that side
> of your proposal.

So in other words, the idea that I have expressed is completely portable.
Cool, then what was your problem with it?????

> >2.0 isn't portable to that platform.  What I am suggesting is 100%
> >identical to what Apache does by putting an apr_file_t inside the
> >request_rec.  Add to that, we are ALREADY doing what I suggest, this model
> >was used in apr_poll_t, and it works just find.
>
> And it implies that apr_foo_t could be allocated by the user, although they
> cannot create the pointer to apr_foo_internal_t.  Let me digest what you are
> proposing so I can comment on it further.

Yep, and without the pointer to the internal structure, APR is essentially
useless.  So, while it would be possible to allocate the public portion of
the structure, it wouldn't get the user anywhere.  Which means, that
binary compat remains, because APR remains the only valid way to allocate
an APR structure.

The only place that binary compat becomes a problem, is that people can
now pass the structure instead of a pointer to the structure.  But if
somebody wants to shoot themselves in the foot, then go ahead.  All they
will be losing is binary compat, which isn't the end of the world,
especially since we provide an easy way for them to regain it.

> You are suggesting two structures.  I spelled out in the prior message
> and a paragraph above why that was a half-way solution.  The real
> answer is a partially complete structure; which is not ANSI C or any
> flavor thereof.

I obviously missed your explanation of why that is a half-way solution.
I'll try to go back and read it again to find the reasoning, but it may
take a day or two.

Ryan



Mime
View raw message