fprintf(stderr in Apache and APR.

[Ryan Bloom <rb...@raleigh.ibm.com>]

There is an item in the STATUS file about having "fprintf(stderr" in the
code.  On Windows, this is no longer a good thing, because we don't ever
point stderr to the error log.  This is EASY to fix in Apache, just
replace all the fprintf(stderr with ap_log_[r]error.  And make those
ap_log_[r]error use stderr (or equivalent) if the server_rec's aren't
setup yet.  I think this last part has been done already I'll check
tomorrow.

Things get a bit harder in APR.  We still can't use fprintf(stderr, but we
also can't use ap_log_[r]error.  To make matters worse, these fprintf's
are the only way we can determine why we failed.  For example, very often
if there is a problem, we will print out the message, and then either
return or exit with a common value (usually 1 or 0).  If we remove the
printf, there is no way to tell which if-clause caused us to fail.  I see
a few possibilities to fix this.  This is only an issue for those
functions we moved from Apache into APR.

1)  Re-write all the apr functions to follow the return a defined status
code.

2)  Return a different error condition for each return statement.  (i.e.
-1, -2, -3, etc)

3)  Leave it alone and use fprintf(stderr, excepting that this doesn't
work properly on Windows.

I like option 1 the best, but I am looking for other ideas and/or opions
on the right way to attack this.

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

Re: fprintf(stderr in Apache and APR.

[Ryan Bloom <rb...@raleigh.ibm.com>]

> > 1)  Re-write all the apr functions to follow the return a defined status
> > code.
> 
> Uh... could you rephrase (1) ? I'm not parsing it...

Sure.  In fact, I'm not sure I would understand it if I hadn't written it.

APR has a defined standard for function prototypes:

ap_status_t ap_foo(arg1, arg2, arg3, ...)

A lot of the functions in the lib directory were taken from Apache 1.3,
and so they don't follow this format.  We could just re-write all of the
functions to return meaningful error codes in the status field, instead of
an error message to stderr, and a generic error value.

Better?

> 4) have a platform-specific error reporting function.
>    On Win32: it goes to the event log and/or a log file
>    On *nix: it goes to stderr
> 
> Where you can't return a status code, but must report an error and exit 
> (e.g. malloc failure), then you can use the system error function.

I think we should be returning a status code in ALL cases.  We just have
to return APR_ENOMEM.  This lets the app figure out what to do about the
failure.  There is no reason APR has to decide to exit just because there
is no more memory to allocate (The app probably should, but you never
know).

APR can never output error messages to a log file, and my own opion is
that we shouldn't ever be outputting messages.  The C Run-Time doesn't
output error messages, and it isn't really up to a Run-Time library to
write logs.  We should just be reporting that there is a problem, and
leaving the function, IMO.

> Of course, the words "platform-specific" means that the function goes into
> APR :-) and that APR can use it when necessary.
> 
> I also believe that you should add a similar function, but it would be
> used for debugging messages. On Win32, it would go to DebugString(), on
> *nix, it would go to stderr.

Debugging NEEDS to be added to Apache and most likely to APR as well.  It
will most likely not get into the code before the BETA, but hopefully we
can put it in before too many BETA's are released.



_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

Re: fprintf(stderr in Apache and APR.

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

On Mon, 15 Nov 1999, Ryan Bloom wrote:
> 1)  Re-write all the apr functions to follow the return a defined status
> code.

Uh... could you rephrase (1) ? I'm not parsing it...

> 2)  Return a different error condition for each return statement.  (i.e.
> -1, -2, -3, etc)
> 
> 3)  Leave it alone and use fprintf(stderr, excepting that this doesn't
> work properly on Windows.

4) have a platform-specific error reporting function.
   On Win32: it goes to the event log and/or a log file
   On *nix: it goes to stderr

Where you can't return a status code, but must report an error and exit 
(e.g. malloc failure), then you can use the system error function.

Of course, the words "platform-specific" means that the function goes into
APR :-) and that APR can use it when necessary.

I also believe that you should add a similar function, but it would be
used for debugging messages. On Win32, it would go to DebugString(), on
*nix, it would go to stderr.

In all cases, more refined status codes would be a good addition.

Cheers,
-g

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

Re: fprintf(stderr in Apache and APR.

[Ryan Bloom <rb...@raleigh.ibm.com>]

> >Do we change their interfaces, and automatically break EVERY module
> >out there because we are changing our API's?
> 
> That's hapenning anyway.

We are breaking everybody, but usually in very small ways.  Only more
complex modules REALLY have to change anything now, and usually even those
changes are small.  If we change the API's for each of these functions,
those changes become really bad IMO.  I'm wiliing to do it, but I want the
groups opinion first.  I know Greg is against it, and I agree with what he
said earlier, but having APR print errors to stderr is just horrible.  And
it will not stay that way if I have anything to say about it.  And, I do,
because I'm fixing the code even as we speak.  :-)

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

Re: fprintf(stderr in Apache and APR.

[Tony Finch <do...@dotat.at>]

Ryan Bloom <rb...@raleigh.ibm.com> wrote:
>
>Do we change their interfaces, and automatically break EVERY module
>out there because we are changing our API's?

That's hapenning anyway.

Tony.
-- 
let it be dot at

Re: fprintf(stderr in Apache and APR.

[Manoj Kasichainula <ma...@io.com>]

On Thu, Nov 18, 1999 at 07:02:12AM -0500, Ryan Bloom wrote:
> I don't have any problem returning errors, I just want to make sure we do
> it with the least amount of pain to our users.

I dealt with this while killing program-wide errno in buff.

1. Per-object errno. It's not nearly as evil as program-wide errno,
and it allows you to easily support calls that are just so entrenched
in the C world that it becomes way too much trouble to deviate.

2. something like ap_bonerror() (no calcium jokes, Ken), which allows
you to register an action for when you get an error. This would allow
easy support for exit on error, like Greg was suggesting, but it's
more generic, providing some of the benefits of an exception-handling
language.

(1) seems okay for certain specific cases. (2) may be cool, but since I
don't think anyone will use it in the near future, it should be put
off 

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/

Re: fprintf(stderr in Apache and APR.

[Dean Gaudet <dg...@arctic.org>]

On Thu, 18 Nov 1999, Ryan Bloom wrote:

> That's the question.  Currently, these functions don't have interfaces
> like the rest of the functions, because they came from Apache.  Do we
> change their interfaces, and automatically break EVERY module out there
> because we are changing our API's?

please take this opportunity to change the API.

Dean

Re: fprintf(stderr in Apache and APR.

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

On Thu, 18 Nov 1999, Ryan Bloom wrote:
>...
> > i know errors are a pain in the ass to return in certain cases, such as
> > fork()/exec()... see "lazy" :)
> 
> I don't have any problem returning errors, I just want to make sure we do
> it with the least amount of pain to our users.

-1 on returning errors from the memory allocators. No way do I want to
start checking every one of those. eesh!

If somebody wants to use APR in a context other than Apache, and they want
errors from the allocators, then I might suggest a flag in the context
that states whether to exit on alloc failure or to return a failure. This
allows Apache and its modules to continue on its current pattern: no need
to check for alloc failure.
[ this, along with cleanup makes memory handling livable in Apache ]

The problem with changing the allocators to return a status is simply the
obfuscation caused by that. In other words:

s2 = ap_pstrdup(s1, p);

must become:

status = ap_pstrdup(&s2, s1, p);


Icky.

Cheers,
-g

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

Re: fprintf(stderr in Apache and APR.

[Ryan Bloom <rb...@raleigh.ibm.com>]

> yuck, APR calls exit()?  that makes it kind of hard for the application
> using APR to have any sort of cleanup code...

Exactly.  The exit calls have been there since the beginning.  They used
to be in the functions when the functions were in ap.  Now they are a part
of a separate library, and exit has to go away.

> - the API lacked sufficient methods of reporting errors
> 
> these are errors, and you should be able to return them via the
> apr_status_t ... right?

That's the question.  Currently, these functions don't have interfaces
like the rest of the functions, because they came from Apache.  Do we
change their interfaces, and automatically break EVERY module out there
because we are changing our API's?  Or do we just find some other way to
return different errors for different cases for these functions.

> i know errors are a pain in the ass to return in certain cases, such as
> fork()/exec()... see "lazy" :)

I don't have any problem returning errors, I just want to make sure we do
it with the least amount of pain to our users.

Ryan

_______________________________________________________________________
Ryan Bloom		rbb@raleigh.ibm.com
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

Re: fprintf(stderr in Apache and APR.

[Dean Gaudet <dg...@arctic.org>]

On Mon, 15 Nov 1999, Ryan Bloom wrote:

> also can't use ap_log_[r]error.  To make matters worse, these fprintf's
> are the only way we can determine why we failed.  For example, very often
> if there is a problem, we will print out the message, and then either
> return or exit with a common value (usually 1 or 0).

yuck, APR calls exit()?  that makes it kind of hard for the application
using APR to have any sort of cleanup code...

typically i find when libraries do this it's usually because:

- the programmer was lazy (we all are ;)

or

- the API lacked sufficient methods of reporting errors

these are errors, and you should be able to return them via the
apr_status_t ... right?

i know errors are a pain in the ass to return in certain cases, such as
fork()/exec()... see "lazy" :)

Dean