You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by "Roy T. Fielding" <fi...@kiwi.ICS.UCI.EDU> on 1999/10/19 12:05:24 UTC
Re: Change to Error logging routines.
>Along a similar vein, I happen to be working on unerrnoing IOLs. Of
>course, unerrnoing IOLs leads to unerrnoing buff, which leads to
>unerrnoing other chunks of Apache and modules. I'm in the middle of
>buff right now. I may try to separate each layer's changes into its
>own patch (by making the layer above assign error codes to errno) to
>make these changes more manageable, but I'll decide this based on the
>level of screaming from here and my mood for the day.
What is important to me is that no error information be lost.
Since there is no way to come up with a table of APR error codes that
includes all possible system-dependent error conditions, this implies
that we need to keep around both the errno and any simplified APR code.
I'm not sure how that maps to the current implementation.
....Roy
Re: Change to Error logging routines.
Posted by Greg Stein <gs...@lyra.org>.
On Fri, 22 Oct 1999, Brian Havard wrote:
> On Thu, 21 Oct 1999 11:46:38 -0400 (EDT), Ryan Bloom wrote:
>
> [...]
>
> >> Perhaps something like my os2errno() function could become a public API, say
> >> int ap_status_errno(ap_status_t);
> >> that could be used to map the system error codes to errno values when you
> >> actually want to know what type of error occurred.
> >
> >We would either need ap_status_errno, or we need to ifdef the code. Bill
> >says converting Windows Error values to errno's is not easy, which is what
> >precipitated this change. If it is as difficult as he seems to think it
> >is, I would rather just ifdef the code, I think. If it is easy, but
> >time-consuming (programming time, not run-time), I would probably rather
> >have the function.
>
> All C libraries do it so it can't be THAT hard. If the ap_status_errno() call
> is only made on failure and only when we care then execution expense becomes
> negligible.
I don't get it. Why do we need that function? Isn't the whole point of
placing APR error numbers at a platform-specific numeric offset intended
*specifically* to allow for equivalency between APR status codes and OS
errno values? i.e. errno values are at the low end, APR at the high end.
int ap_status_errno(ap_status_t status)
{
return status;
}
I mean "duh"... why have the function? Is there some other kind of voodoo
that is supposed to go in there?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Change to Error logging routines.
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Thu, 21 Oct 1999 11:46:38 -0400 (EDT), Ryan Bloom wrote:
[...]
>> Perhaps something like my os2errno() function could become a public API, say
>> int ap_status_errno(ap_status_t);
>> that could be used to map the system error codes to errno values when you
>> actually want to know what type of error occurred.
>
>We would either need ap_status_errno, or we need to ifdef the code. Bill
>says converting Windows Error values to errno's is not easy, which is what
>precipitated this change. If it is as difficult as he seems to think it
>is, I would rather just ifdef the code, I think. If it is easy, but
>time-consuming (programming time, not run-time), I would probably rather
>have the function.
All C libraries do it so it can't be THAT hard. If the ap_status_errno() call
is only made on failure and only when we care then execution expense becomes
negligible.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: Change to Error logging routines.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> Ok, being able to report system error messages is a great goal but for all
> other purposes it reduces the usefulness of the error code to that of a
> boolean success/fail indicator.
Yep. But looking through Apache, that's what they are used for most often
anyway. I guess that's been a common theme in APR development. APR is
there to REALLY help with the most common operations. Reading/writing a
file, boolean error checks, etc. APR succeeds there, but if you want to
do more complicated stuff, like actually branch on the error, APR may
require the programmer to do a bit more work. I think this is fine,
because 90% of the time we are making programming cross-platform much
easier. The 10% where it is just as hard as it always was, isn't a big
deal.
> >This is not a big issue I think. Most of the time you are checking for
> >APR_SUCCESS. If you don't get it, you cut an error message and stop whatever
> >it is you are doing. There are few places in Apache that take multiple
> >branches based on an return codes.
>
> Most, maybe, but sometimes you really want to behave differently depending on
> which error occurred, often to distinguish between fatal & non-fatal errors.
>
> Perhaps something like my os2errno() function could become a public API, say
> int ap_status_errno(ap_status_t);
> that could be used to map the system error codes to errno values when you
> actually want to know what type of error occurred.
We would either need ap_status_errno, or we need to ifdef the code. Bill
says converting Windows Error values to errno's is not easy, which is what
precipitated this change. If it is as difficult as he seems to think it
is, I would rather just ifdef the code, I think. If it is easy, but
time-consuming (programming time, not run-time), I would probably rather
have the function.
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: Change to Error logging routines.
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Thu, 21 Oct 1999 11:22:29 -0400, Bill Stoddard wrote:
>> In the OS/2 header files there's a constant ERROR_USER_DEFINED_BASE (set
>at
>> 0xFF00) which all system error codes are less than. I'm not sure what you
>> guys are getting at though, I can't see what use it would be for APR
>> functions to return system error codes as nothing would understand them.
>The idea is to place APR (i.e. user specific) error codes in the user range
>on each OS. This would mean, for example, that APR_SUCCESS would have a
>different numerical value, depending on the OS. Or saying it another way,
>the APR error codes would be offset, in an OS specific way, to put them in
>the user error code space suitable for that OS. It is important to keep the
>system error codes because in general, it is impossible to map all possible
>system error codes to APR codes with out loosing information. The
>ap_log_error function will have the smarts, based on the error number, to
>determine if the error is an APR status or a system status and do the right
>thing.
Ok, being able to report system error messages is a great goal but for all
other purposes it reduces the usefulness of the error code to that of a
boolean success/fail indicator.
>> I can't see what use it would be for APR functions to return system error
>codes as nothing would understand them.
>
>This is not a big issue I think. Most of the time you are checking for
>APR_SUCCESS. If you don't get it, you cut an error message and stop whatever
>it is you are doing. There are few places in Apache that take multiple
>branches based on an return codes.
Most, maybe, but sometimes you really want to behave differently depending on
which error occurred, often to distinguish between fatal & non-fatal errors.
Perhaps something like my os2errno() function could become a public API, say
int ap_status_errno(ap_status_t);
that could be used to map the system error codes to errno values when you
actually want to know what type of error occurred.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: Change to Error logging routines.
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
> > on each OS. This would mean, for example, that APR_SUCCESS would have a
> > different numerical value, depending on the OS. Or saying it another
way,
>
> Unless there is a valid reason to redfine APR_SUCCESS, it should remain
> zero on all platforms. This allows for some shortcuts, and it can make
> the code look a little cleaner. I have the feeling that at some point, we
> will see
APR_SUCCESS was a bad example. I agree that it should be 0 for the reasons
mentioned. But the numerical value of the failure APR status codes may be
different for each platform. That was the point I was trying to make.
Bill
Re: Change to Error logging routines.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> on each OS. This would mean, for example, that APR_SUCCESS would have a
> different numerical value, depending on the OS. Or saying it another way,
Unless there is a valid reason to redfine APR_SUCCESS, it should remain
zero on all platforms. This allows for some shortcuts, and it can make
the code look a little cleaner. I have the feeling that at some point, we
will see
if (!ap_readdir(temp)) {
...
}
While this is not great, programmers are programmers, and somebody will
code this way, no matter what we say. This will fail if APR_SUCCESS is
not zero. I envision the OS dependant stuff being used for APR error
codes and APR status codes. Anytime a platform returns 0 (NULL) as a
failure, it should simply be taken care of in APR.
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: Change to Error logging routines.
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
> In the OS/2 header files there's a constant ERROR_USER_DEFINED_BASE (set
at
> 0xFF00) which all system error codes are less than. I'm not sure what you
> guys are getting at though, I can't see what use it would be for APR
> functions to return system error codes as nothing would understand them.
>
The idea is to place APR (i.e. user specific) error codes in the user range
on each OS. This would mean, for example, that APR_SUCCESS would have a
different numerical value, depending on the OS. Or saying it another way,
the APR error codes would be offset, in an OS specific way, to put them in
the user error code space suitable for that OS. It is important to keep the
system error codes because in general, it is impossible to map all possible
system error codes to APR codes with out loosing information. The
ap_log_error function will have the smarts, based on the error number, to
determine if the error is an APR status or a system status and do the right
thing.
Bill
Re: Change to Error logging routines.
Posted by Bill Stoddard <st...@raleigh.ibm.com>.
> I can't see what use it would be for APR functions to return system error
codes as nothing would understand them.
This is not a big issue I think. Most of the time you are checking for
APR_SUCCESS. If you don't get it, you cut an error message and stop whatever
it is you are doing. There are few places in Apache that take multiple
branches based on an return codes.
Bill
Re: Change to Error logging routines.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> In the OS/2 header files there's a constant ERROR_USER_DEFINED_BASE (set at
> 0xFF00) which all system error codes are less than. I'm not sure what you
> guys are getting at though, I can't see what use it would be for APR
> functions to return system error codes as nothing would understand them.
But, the goal is to have them understood. Right now, we check for errors,
rather than checking for success. We do that because in POSIX, checking
for errors is just easier. With APR_SUCCESS, we can check for success in
all cases, and use portable API's to deal with the errors.
For example, this code should work regardless of what platform it's on.
(Assume valid types throught)
if ((status = ap_readdir(temp)) != APR_SUCCESS) {
ap_log(APLOG_MARK, ... , status, ....);
}
In ap_log, we use the equivalent of strerror on all platforms to output a
meaningful error message.
There are places, where we actually need to know which error was returned
to do the right thing, but they are few and far between (I seem to
remember one in the old http_main.c), and these can be #ifdef'ed cleanly.
The most common uses for errno, was to see if there was a problem, and for
logging. Both of those functions can be taken care of by APR. I'm not
saying that we can get rid of all uses of platform specific error codes,
but we can get rid of a bunch of them.
Take a look at the new apr_errno.h, and see what you think.
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: Change to Error logging routines.
Posted by Brian Havard <br...@kheldar.apana.org.au>.
On Wed, 20 Oct 1999 14:19:20 -0400 (EDT), Ryan Bloom wrote:
>
>> > I do not see why we need errno, because APR uses errno under the covers
>> > when it can, it just removes errno from being stored by the system as soon
>> > as it possibly can.
>>
>> You should probably have a platform-dependent range defined for
>> replacement error numbers (and so forth).
>>
>> Windoze and OS/2, if I remember correctly, have a standard for
>> user-defined errors, and it ain't 4000-5000!
>
>ARGH! I didn't think to look at OS/2. I don't really care what Windows
>does with errno, because MOST of the Windows calls we are making don't set
>errno anyway. We actually have to map the return from GetLastError to an
>errno #define. Brian, want to give me some clue about how OS/2 deals with
>error values?
OS/2 works much the same way as Win32 with error handling (in fact most of
the codes are the same) except that it has no GetLastError() function. All
API calls return an error code, just like APR. C libraries remap the OS/2
error codes into errno values but it's not a one to one mapping as there are
far more OS/2 error codes than errno values (301 just for file & process
stuff). In APR I've been using a simple table lookup (see
file_io/os2/maperrorcode.c).
In the OS/2 header files there's a constant ERROR_USER_DEFINED_BASE (set at
0xFF00) which all system error codes are less than. I'm not sure what you
guys are getting at though, I can't see what use it would be for APR
functions to return system error codes as nothing would understand them.
--
______________________________________________________________________________
| Brian Havard | "He is not the messiah! |
| brianh@kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian |
------------------------------------------------------------------------------
Re: Change to Error logging routines.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
> > I do not see why we need errno, because APR uses errno under the covers
> > when it can, it just removes errno from being stored by the system as soon
> > as it possibly can.
>
> You should probably have a platform-dependent range defined for
> replacement error numbers (and so forth).
>
> Windoze and OS/2, if I remember correctly, have a standard for
> user-defined errors, and it ain't 4000-5000!
ARGH! I didn't think to look at OS/2. I don't really care what Windows
does with errno, because MOST of the Windows calls we are making don't set
errno anyway. We actually have to map the return from GetLastError to an
errno #define. Brian, want to give me some clue about how OS/2 deals with
error values?
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: Change to Error logging routines.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
Okay, just sat down with Bill. Here's the solution for making error
values MORE portable still. In apr_config.h, there will be a #define for
OS_START_ERR (on UNIX, I'm going to use 4000). APR error codes will use
this value to start their numbering. APR status values will use this
number+500 to start their numbering.
In ap_log_error, we will have to call ap_strerror (not created yet)
instead of strerror. This will map in the following way:
values < OS_START_ERR
call native function to turn error number into string.
values > OS_START_ERR
return a string for APR values (this will be shared code across
all platforms).
This should allow ALL platforms to use their native error codes without
interference, while still allowing us to make them portable, and extend
them as APR needs.
Ryan
> You should probably have a platform-dependent range defined for
> replacement error numbers (and so forth).
>
> Windoze and OS/2, if I remember correctly, have a standard for
> user-defined errors, and it ain't 4000-5000!
>
> Cheers,
>
> Ben.
>
> --
> http://www.apache-ssl.org/ben.html
>
> "My grandfather once told me that there are two kinds of people: those
> who work and those who take the credit. He told me to try to be in the
> first group; there was less competition there."
> - Indira Gandhi
>
_______________________________________________________________________
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: Change to Error logging routines.
Posted by Ben Laurie <be...@algroup.co.uk>.
Ryan Bloom wrote:
>
> The current implementation uses errno within APR. Basically, when a
> function returns an error code to APR, APR returns errno as the error
> value. I have resrved the first 3000 values for Errno, and I reserved
> from 3000-4000 for replacement errno values, in case your platform doesn't
> have an errno value that we might expect. Values between 4000 and 5000
> are APR error codes, and values higher than 5000 are APR status values.
> These are not errors, they are just good information to have.
>
> I do not see why we need errno, because APR uses errno under the covers
> when it can, it just removes errno from being stored by the system as soon
> as it possibly can.
You should probably have a platform-dependent range defined for
replacement error numbers (and so forth).
Windoze and OS/2, if I remember correctly, have a standard for
user-defined errors, and it ain't 4000-5000!
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Change to Error logging routines.
Posted by Ryan Bloom <rb...@raleigh.ibm.com>.
The current implementation uses errno within APR. Basically, when a
function returns an error code to APR, APR returns errno as the error
value. I have resrved the first 3000 values for Errno, and I reserved
from 3000-4000 for replacement errno values, in case your platform doesn't
have an errno value that we might expect. Values between 4000 and 5000
are APR error codes, and values higher than 5000 are APR status values.
These are not errors, they are just good information to have.
I do not see why we need errno, because APR uses errno under the covers
when it can, it just removes errno from being stored by the system as soon
as it possibly can.
Ryan
> What is important to me is that no error information be lost.
> Since there is no way to come up with a table of APR error codes that
> includes all possible system-dependent error conditions, this implies
> that we need to keep around both the errno and any simplified APR code.
>
> I'm not sure how that maps to the current implementation.
>
> ....Roy
>
_______________________________________________________________________
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.