Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <059001c19ebc$cddae6c0$d49151d1@v505>
From: "William A. Rowe, Jr." <wrowe@covalent.net>
To: "Sander Striker" <striker@apache.org>,
	<dev@apr.apache.org>
References: <JLEGKKNELMHCJPNMOKHOEEIFFCAA.striker@apache.org>
Subject: Re: Passing file/line ALL the time WAS: RE: [PATCH] Default tagging
 of pools in debug mode [2]
Date: Wed, 16 Jan 2002 12:37:02 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

From: "Sander Striker" <striker@apache.org>
Sent: Wednesday, January 16, 2002 12:28 PM


> > From: William A. Rowe, Jr. [mailto:wrowe@covalent.net]
> > Sent: 16 January 2002 15:45
> > 
> > Ok... Now that I've followed this conversation a while...
> > 
> > I'm entirely -1 on any function changing arguments based on dev/release
> > builds.
> 
> Technically we have two functions.  A normal version and a debug version.
> At debug time, both functions will exist.  A macro is used to override
> the callers of the normal function at debug time.

Irrelevant...

> > That means we can have the file/line arg of NULL if we simply _don't care_,
> > so we don't waste const string heap, but there will be a char* argument
> > always, or never.
> 
> Why?  The extra argument is completely useless in a release build.
> Why bother a user with an extra argument?

Because without identical arg passing semantics, release and development 
versions are binary-incompatible, and that's what I find unacceptable
in the first place.

> > Pushing an extra NULL in a release build to the infrequently called
> > apr_pool_create is trivial.  And painless.
> 
> It's not only apr_pool_create.  It's also clear and destroy.  These are
> the operations you wish to track.  And, I know there is some demand
> for output that can be used to replay what happened.  Then, apr_palloc
> and apr_pcalloc will be added to this list aswell.

Ok... so create/clear/destroy.  It is still negligable to do an extra
  xor ax,ax
  push ax
in order to maintain binary compatibility.

Bill