APLOG_NOERRNO useless

[Jeff Trawick <tr...@attglobal.net>]

We never do anything with errno in our logging functions.

We can figure out whether or not there is an apr_status_t to deal with
by comparing the appropriate parameter with 0/APR_SUCCESS only, with
no regard to APLOG_NOERRNO.

APLOG_NOERRNO made sense before because errno wasn't an explicit
parameter.

The only conceivable use is so the caller can pass non-zero for the
apr_status_t but turn on the APLOG_NOERRNO flag so that no error
information is logged.  No sleep would be lost here over that
feature.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: APLOG_NOERRNO useless

[Jeff Trawick <tr...@attglobal.net>]

Justin Erenkrantz <je...@apache.org> writes:

> On Thu, May 16, 2002 at 11:37:26AM -0400, Jeff Trawick wrote:
> > I wouldn't remove APLOG_NOERRNO within the same release.  Most MMN
> > bumps don't require a source code change for any particular module.
> > I don't see a compelling reason to make modules remove the symbol from
> > their code until there is a new level of Apache where it is understood
> > that modules will have to be seriously revisited.
> 
> But, we should remove it from all of our core modules when we change
> it.  

You bet...  I just didn't want to unnecessarly break 3rd-party
modules.  For binary-only modules it might not matter much but for
open source modules this isn't important enough to force them to make
a new release.

> Oh, +1 for removing it.  I spent way too much time last night adding
> APLOG_NOERRNO to a bunch of places.  Why didn't you suggest this LAST
> night?  *sigh*  -- justin

I had worked through one ssl module and didn't use APLOG_NOERRNO
myself...  I didn't expect that the elves would come in overnight and
take care of everything.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: APLOG_NOERRNO useless

[Justin Erenkrantz <je...@apache.org>]

On Thu, May 16, 2002 at 11:37:26AM -0400, Jeff Trawick wrote:
> I wouldn't remove APLOG_NOERRNO within the same release.  Most MMN
> bumps don't require a source code change for any particular module.
> I don't see a compelling reason to make modules remove the symbol from
> their code until there is a new level of Apache where it is understood
> that modules will have to be seriously revisited.

But, we should remove it from all of our core modules when we change
it.  

Oh, +1 for removing it.  I spent way too much time last night adding
APLOG_NOERRNO to a bunch of places.  Why didn't you suggest this LAST
night?  *sigh*  -- justin

Re: APLOG_NOERRNO useless

[Jeff Trawick <tr...@attglobal.net>]

Brian Pane <bp...@pacbell.net> writes:

> My vote presumes, by the way, that the removal is really
> a backward-compatible deprecation:
>   * re#define APLOG_NOERRNO to zero for source compatibility
>   * mask out the bit that used to be APLOG_NOERRNO within
>     ap_log_*error() for binary compatibility, unless other
>     changes force an MMN major increment in the same release.

I wouldn't remove APLOG_NOERRNO within the same release.  Most MMN
bumps don't require a source code change for any particular module.
I don't see a compelling reason to make modules remove the symbol from
their code until there is a new level of Apache where it is understood
that modules will have to be seriously revisited.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: APLOG_NOERRNO useless

[Greg Stein <gs...@lyra.org>]

On Thu, May 16, 2002 at 08:11:03AM -0700, Brian Pane wrote:
>...
> My vote presumes, by the way, that the removal is really
> a backward-compatible deprecation:
>
>   * re#define APLOG_NOERRNO to zero for source compatibility
>   * mask out the bit that used to be APLOG_NOERRNO within
>     ap_log_*error() for binary compatibility, unless other
>     changes force an MMN major increment in the same release.

If we want Apache to follow APR's versioning model(*), then you shouldn't
redefine a symbolic constant's value. Just mark it as deprecated, and toss
the symbol in the next major release.

In particular, it might be possible for a third-party module to use
APLOG_NOERRNO and want to test for it. It doesn't hurt us to leave the value
in there.

Cheers,
-g

(*) http://apr.apache.org/versioning.html

-- 
Greg Stein, http://www.lyra.org/

Re: APLOG_NOERRNO useless

[Brian Pane <bp...@pacbell.net>]

Brian Pane wrote:

> Jeff Trawick wrote:
>
>> We never do anything with errno in our logging functions.
>>
>> We can figure out whether or not there is an apr_status_t to deal with
>> by comparing the appropriate parameter with 0/APR_SUCCESS only, with
>> no regard to APLOG_NOERRNO.
>>
>> APLOG_NOERRNO made sense before because errno wasn't an explicit
>> parameter.
>>
>> The only conceivable use is so the caller can pass non-zero for the
>> apr_status_t but turn on the APLOG_NOERRNO flag so that no error
>> information is logged.  No sleep would be lost here over that
>> feature.
>>
>
> +1 


My vote presumes, by the way, that the removal is really
a backward-compatible deprecation:
  * re#define APLOG_NOERRNO to zero for source compatibility
  * mask out the bit that used to be APLOG_NOERRNO within
    ap_log_*error() for binary compatibility, unless other
    changes force an MMN major increment in the same release.

--Brian

Re: APLOG_NOERRNO useless

[Brian Pane <bp...@pacbell.net>]

Jeff Trawick wrote:

>We never do anything with errno in our logging functions.
>
>We can figure out whether or not there is an apr_status_t to deal with
>by comparing the appropriate parameter with 0/APR_SUCCESS only, with
>no regard to APLOG_NOERRNO.
>
>APLOG_NOERRNO made sense before because errno wasn't an explicit
>parameter.
>
>The only conceivable use is so the caller can pass non-zero for the
>apr_status_t but turn on the APLOG_NOERRNO flag so that no error
>information is logged.  No sleep would be lost here over that
>feature.
>

+1


--Brian

Re: APLOG_NOERRNO useless

[Aaron Bannert <aa...@clove.org>]

> I'd recommend that we keep the constant for now so that everybody's
> code compiles, document it as useless and deprecated, stop using it in
> our code so we don't set a bad example, and remove it with the next
> big API change (2.1?).

+1

Time to start the laundry list of things we need to do as soon as
we hit/branch 2.1.

-aaron

Re: APLOG_NOERRNO useless

[Jeff Trawick <tr...@attglobal.net>]

Aaron Bannert <aa...@clove.org> writes:

> On Thu, May 16, 2002 at 06:38:14AM -0400, Jeff Trawick wrote:
> > We never do anything with errno in our logging functions.
> ...
> > No sleep would be lost here over that feature.
> 
> I tend to agree that the feature is useless (an artifact of the old
> logging interface, as you point out), but at this point I think it might
> cause something between an annoyance and a PITA to module authors if we
> get rid of it now.

I'd recommend that we keep the constant for now so that everybody's
code compiles, document it as useless and deprecated, stop using it in
our code so we don't set a bad example, and remove it with the next
big API change (2.1?).

It rubs me the wrong way to see it in our code when it doesn't do
anything useful.

-- 
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...

Re: APLOG_NOERRNO useless

[Aaron Bannert <aa...@clove.org>]

On Thu, May 16, 2002 at 06:38:14AM -0400, Jeff Trawick wrote:
> We never do anything with errno in our logging functions.
...
> No sleep would be lost here over that feature.

I tend to agree that the feature is useless (an artifact of the old
logging interface, as you point out), but at this point I think it might
cause something between an annoyance and a PITA to module authors if we
get rid of it now.

Given that, I'm still +0.25 on removing it. :)

-aaron