From: "Sander Striker" <[EMAIL PROTECTED]> Sent: Wednesday, January 16, 2002 12:28 PM
> > From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED] > > 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
