httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Ralf S. Engelschall)
Subject Re: [PATCH] Hide symbols to avoid namespace conflicts (take 2)
Date Tue, 03 Mar 1998 12:06:47 GMT

In article <> you wrote:
> On Monday, March 02, 1998 11:51 AM, Ralf S. Engelschall wrote:
>> In article <> you wrote:
> Developers should check the output of the script against the repository when
> they update to avoid letting things Apache didn't define slip in.

I'll add a message to Makefile.tmpl to make this clear.

>> >[...]
>> >    00002020 T start
>> >[...]
> Is it good, bad, or whatever that start is being redefined as AP_start?

Hmmm... I don't know what 'start' actually is. Seems it is together with 'end'
one of the standard compiler symbols, because I found them under Solaris, too.
I've added it to the exclusion list. BUT, nevertheless it doesn't make
problems or hurts something. Because as long as we do not use this symbol in
our sources it doesn' hurt is.

> (a) Right now there are entries of the form:
>   #define ap_md5 AP_ap_md5
> I'd lean toward removing those.

Because this is a double definition, you think? Hmmm... yes it is but on the
other hand when we exclude those this leads to a total confusion, for instance
when you debug such a httpd.  Because then you have to think about twice: If
its ap_ then its in there exactly with this name and if not ap_ then AP_..
Hmmm... not nice. Instead we should consider the HIDE feature to be used only
in those cases where you really have to link Apache with a third-party library
and get namespace conflicts. Then HIDE=yes should be enabled to easily resolve
the conflict.

> (b) It wouldn't be hard to make the mistake of getting:
>   #define AP_ind  AP_AP_ind
> by running the thing twice with the facility turned on.
> Both of these appears easy to avoid.

No, it is hard because my helpers/UpdateHide script checks for this situation.
It first strips off any already existing AP_ prefix.

>> > This adds perl to the tools required of the Apache 
>> > developer.
> As I'm sure your all aware many end users must expend political capital to
> get any software installed by their corp. information technology
> departments.  For example I can't  get the same version of perl installed on
> N machines since it opens issues of risk in "stable" (aka unsupported) parts
> of the software used around the building.

While you point is ok in general, it doesn't apply to the HIDE feature.
Because first Perl here is only required for the developers and not for end
users and secondly even when the end user would need Perl, it already needs it
for other existing scripts in support/.

                                       Ralf S. Engelschall

View raw message