httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject RE: [PATCH] Hide symbols to avoid namespace conflicts (take 2)
Date Mon, 02 Mar 1998 18:43:32 GMT
On Monday, March 02, 1998 11:51 AM, Ralf S. Engelschall
[] wrote:
> In article <> you wrote:
> >[...]
> > What I don't understand is how do we know this works
> > out in practice.  For example from my nm -g output on
> > sunos.
> >    00064a24 T _isalnum
> >    00002020 T start
> > isalnum is in there with all it's friends of course this
> > makes it choke when it gets to "#define isalpha(c) ..."
> > in ctype.  I guess I ought to track down where it came
> > from.
> Sure, the system functions should remain, because they both cannot be
> and there is no need to hide them. There is only need to hide all
> Apache defines itself. 

Developers should check the output of the script against the repository
they update to avoid letting things Apache didn't define slip in.

Is it good, bad, or whatever that start is being redefined as AP_start?

> > It might be easy to enhance it so it can be used
> > when HIDE=yes.
> Sorry, my english seems too bad to be able to understand this. What
exactly do
> you mean?  That it doesn't work correctly or something is missing?
What do you
> want to enhance?

My fault.  I was trying to point out two things in one sentence.  

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

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

> > Should HIDE=yes be the default?  I'd lean toward yes
> > since I prefer things to "on" so they get tested
> > going forward.
> Hmmm... yes and no. I personally would leave it HIDE=no because with
> all functions are prefixed with AP_ and thus you cannot nicely debug
> etc. Hmmm... I think HIDE=no should be kept. It is better this way.

Another reason I'd lean toward yes: the trend toward dynamicly loading
modules - I don't want to build my module twice for each platform.

Debugging something that isn't the "standard" configuration is bogus.
The RSI downside of three more characters when debugging is painful.  No
happy outcome.

> > This adds perl to the tools required of the Apache 
> > developer.
> The scripts log_server_status, dbmmanage, phf_abuse_log.cgi and
> already require Perl, so another one named UpdateHide will not cause
> At least not for the developers which are all hackers and every hacker
> have a Perl interpreter installed ;-)

As I'm sure your all aware many end users must expend political capital
get any software installed by their corp. information technology
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.

   - ben hyde

View raw message