apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: Opaque types [was apr_mmap_t]
Date Mon, 25 Nov 2002 06:16:23 GMT
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.

>> 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.

>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.

>I am not going to respond to the rest of this message, it is nothing but
>flame bait.

Glad we are having a discussion and not a debate, then.

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.

>We are still waiting for the real labor to begin.  I has been two days,
>and I am wasting time on the computer.

I hear that ... no rest for the expectant mother -or- father :-) 

Bill


Mime
View raw message