httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ralf S. Engelschall)
Subject Re: cvs commit: apache-1.3/src/test/rename apapi.h
Date Mon, 06 Apr 1998 17:33:29 GMT

In article <> you wrote:
> Ralf S. Engelschall wrote:
>> > Are we then saying that all API functions have the ap_ prefix?
>> > Why? AFAIK, I vetoed that. I also recall that before Dean said that
>> > apapi_ was just too long to type, we all were voting on the "correct"
>> > prefixes for all functions...
>> > If we are going to do this, let's do it right, and not half-arsed.
>> > I'll be quiet now.
>> Don't be quiet Jim ;-) 
>> But when you look into my you see that not all functions get just
>> the ap_ prefix. Instead currently is configured to use ap_, apx_ and
>> apm_, i.e. different prefixes for different symbol spaces.  The apapi.h file
>> just holds the _REAL_ (=public) API functions.  All cross-object files still
>> get a different prefix. But these are not listed in the apapi.h file. For the
>> complete mapping please read
>> Or did you mean a different point, Jim?

> As far as I know, the use of ap_ for API functions was the "alternate"
> method, and I had vetoed that on the grounds that it clashes with
> the use of ap_ for "generic, non-API" functions (like ap_snprintf).
> Unless we say that the present ap_ functions (those in libap.a) are
> now part of the API, I think it's confusing to use the same prefix
> for both "classes" of functions. If so, then I would rescind my
> veto, but not until that's all agreed.

ap_ is part of both variants in STATUS: Once for the real API functions in the
first variant and as the general prefix in the second variant. In the first
variant ap_ is there because apapi_ is really too long and I personally really
think the libap stuff should be threated as API stuff. So, ap_ for all public
API stuff is best: It's Apache specific and its short.

                                       Ralf S. Engelschall

View raw message