apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: Passing file/line ALL the time WAS: RE: [PATCH] Default tagging of pools in debug mode [2]
Date Wed, 16 Jan 2002 18:37:02 GMT
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.


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


View raw message