Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 6522 invoked by uid 6000); 2 Mar 1998 16:43:53 -0000 Received: (qmail 6515 invoked from network); 2 Mar 1998 16:43:51 -0000 Received: from slarti.muc.de (193.174.4.10) by taz.hyperreal.org with SMTP; 2 Mar 1998 16:43:51 -0000 Received: (qmail 28727 invoked by uid 66); 2 Mar 1998 16:42:11 -0000 Received: by en1.engelschall.com (Sendmail 8.8.8) for new-httpd@apache.org id RAA15468; Mon, 2 Mar 1998 17:40:49 +0100 (MET) Message-Id: <199803021640.RAA15468@en1.engelschall.com> Subject: Re: [PATCH] Hide symbols to avoid namespace conflicts (take 2) To: new-httpd@apache.org Date: Mon, 2 Mar 1998 17:40:49 +0100 (MET) From: rse@engelschall.com (Ralf S. Engelschall) Organization: Engelschall, Germany. X-Home: http://www.engelschall.com/ X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org In article <9803021509.AA12325@gensym1.gensym.com> 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 hidden and there is no need to hide them. There is only need to hide all symbols Apache defines itself. > What is the pattern for when this is to be used? > ? developers should run it when ever they add > a new external symbol. To make sure all Apache symbols are contained in hide.h > ? it will be run as part of the release ritual. Not as part of the release steps itself, but it would be wise to check hide.h before each release to be sure we have a mostly complete one. > ? it will be run from time to time, not running it > is no big deal. Yes, because even when we have added a function foo() which is not covered by hide.h this is no harm unless foo really exists in the third-party objects linked to Apache. The important point is just that hide.h has to hide at least all those functions which could lead to namespace conflicts. Hiding more is better, but no essential requirement. > ? <> modules MUST be linked into httpd when this > is run. Because when modules are missing, symbols are missing and this the UpdateHide script cannot insert them into hide.h. So the "updatehide" target of Makefile.tmpl first compiles a httpd with all modules and then extracts the symbols. This way our hide.h is nearly complete. > 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? > 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 HIDE=yes all functions are prefixed with AP_ and thus you cannot nicely debug Apache, etc. Hmmm... I think HIDE=no should be kept. It is better this way. > This adds perl to the tools required of the Apache > developer. The scripts log_server_status, dbmmanage, phf_abuse_log.cgi and printenv already require Perl, so another one named UpdateHide will not cause problems. At least not for the developers which are all hackers and every hacker should have a Perl interpreter installed ;-) Greetings, Ralf S. Engelschall rse@engelschall.com www.engelschall.com