httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <trawi...@bellsouth.net>
Subject Re: Errno code in APR again.
Date Mon, 10 Apr 2000 18:18:49 GMT
> >       An example of when an app might need to deal with such details
> >       is when an app traces the error code.  On a platform like
> >       Windows or OS/2, it is probably meaningful to trace the
> >       ap_status_t value unless it is an OS-specific error.  In that
> >       case, the application will likely want to trace the OS-specific
> >       error value (and call it that) so that the user knows which 
> >       documentation to refer to for why that error might have
> >       occurred. 
> > 
> >       In other words, a message like
> > 
> >       "system error 4011 opening config file: permission denied"
> > 
> >       instead of 
> >       
> >       "error 14011 opening config file: permission denied"
> 
> Why would a user EVER see this?  Apache does not currently print out the
> error number.  If you are writing another program that does print out the
> error number, then fix this one of two ways.  Implement the macro you have
> asked for, or modify ap_strerror to print out the error number.

Please look at "(13)" in the log message below.

[Mon Apr 10 13:56:20 2000] [crit] (13)Permission denied: make_sock:
could not bind to address 0.0.0.0 port 80

> >    Your justification of forcing the app to do this seems to be based
> >    on your statement that "it takes time to convert error codes to a
> >    common code".

...

> The job of APR is to take portability off the programer's shoulders.  I
> guess the best justification for doing it this way is that we started
> doing it the other way (returning a common error code), and we lose
> information.  It isn't always possible to go through this transformation:
> 
>     platform err-code  ->  common error code  ->  platform error
>     code.

I think your statement here is a very powerful argument.  My point was
that the only argument listed in APRDesign wasn't very powerful.  I
would suggest that you copy this text into APRDesign at a place you
find appropriate.

> > B. trivialities
> > 
> > I have a small number of extremely minor editorial changes to your
> > text which, unless you prefer they be sent to you directly or posted
> > here, I will update in your text myself in a few days if nobody beats
> > me to it.  (I can assure you that none of it is related to my
> > sometimes-ignorant use of commas :) )
> 
> Please send them to the list.

(I just double checked "dependant" and found that it is a legal
variant of dependent, so that change is relatively asinine.)

Index: APRDesign
===================================================================
RCS file: /cvs/apache/apache-2.0/src/lib/apr/APRDesign,v
retrieving revision 1.8
diff -u -r1.8 APRDesign
--- APRDesign	2000/04/07 14:16:28	1.8
+++ APRDesign	2000/04/10 18:16:03
@@ -183,30 +183,30 @@
 APR Error reporting
 
 Most APR functions should return an ap_status_t type.  The only time an
-APR function does not return an ap_status_t is if it absolutly CAN NOT
+APR function does not return an ap_status_t is if it absolutely CAN NOT
 fail.  Examples of this would be filling out an array when you know you are
 not beyond the array's range.  If it cannot fail on your platform, but it
 could conceivably fail on another platform, it should return an ap_status_t.
 Unless you are sure, return an ap_status_t.  :-)
 
-All platform return errno values unchanged.  Each platform can also have
+All platforms return errno values unchanged.  Each platform can also have
 one system error type, which can be returned after an offset is added.  
-There are five types of error values in APR, each with it's own offset.
+There are five types of error values in APR, each with its own offset.
 
     Name			Purpose
 0) 			This is 0 for all platforms and isn't really defined
  			anywhere, but it is the offset for errno values.
 			(This has no name because it isn't actually defined, 
-                        but completeness we are discussing it here).
-1) APR_OS_START_ERROR	This is platform dependant, and is the offset at which
+                        but for completeness we are discussing it here).
+1) APR_OS_START_ERROR	This is platform dependent, and is the offset at which
 			APR errors start to be defined.  (Canonical error
 			values are also defined in this section.  [Canonical
 			error values are discussed later]).
-2) APR_OS_START_STATUS	This is platform dependant, and is the offset at which
+2) APR_OS_START_STATUS	This is platform dependent, and is the offset at which
 			APR status values start.
-4) APR_OS_START_USEERR	This is platform dependant, and is the offset at which
+4) APR_OS_START_USEERR	This is platform dependent, and is the offset at which
 			APR apps can begin to add their own error codes.
-3) APR_OS_START_SYSERR	This is platform dependant, and is the offset at which
+3) APR_OS_START_SYSERR	This is platform dependent, and is the offset at which
 			system error values begin.
 
 All of these definitions can be found in apr_errno.h for all platforms.  When
@@ -224,13 +224,13 @@
 
     if (CreateFile(fname, oflags, sharemod, NULL, 
                    createflags, attributes,0) == INVALID_HANDLE_VALUE
-        return (GetLAstError() + APR_OS_START_SYSERR);
+        return (GetLastError() + APR_OS_START_SYSERR);
 
 These two examples implement the same function for two different platforms.
 Obviously even if the underlying problem is the same on both platforms, this
 will result in two different error codes being returned.  This is OKAY, and
 is correct for APR.  APR relies on the fact that most of the time an error
-occurs, the program logs the error and continues, it does not try to
+occurs, the program logs the error and continues and does not try to
 programatically solve the problem.  This does not mean we have not provided
 support for programmatically solving the problem, it just isn't the default
 case.  We'll get to how this problem is solved in a little while.
@@ -241,14 +241,14 @@
 and are self explanatory.
 
 No APR code should ever return a code between APR_OS_START_USEERR and 
-APR_OS_START_SYSERR, those codes are reserved for APR applications.
+APR_OS_START_SYSERR; those codes are reserved for APR applications.
 
 To programmatically correct an error in a running application, the error codes
 need to be consistent across platforms.  This should make sense.  To get
 consistent error codes, APR provides a function ap_canonicalize_error().
 This function will take as input any ap_status_t value, and return a small
 subset of canonical APR error codes.  These codes will be equivalent to
-Unix errno's.  Why is it a small subset?  Because we don't want to try to
+Unix errnos.  Why is it a small subset?  Because we don't want to try to
 convert everything in the first pass.  As more programs require that more
 error codes are converted, they will be added to this function.  
 
@@ -288,7 +288,7 @@
     make syscall that fails
         convert to common error code
         return common error code
-            decide execution basd on common error code
+            decide execution based on common error code
 
 Using option 2:
     
@@ -306,9 +306,9 @@
 char *ap_strerror(ap_status_t err)
 {
     if (err < APR_OS_START_ERRNO2)
-        return (platform dependant error string generator)
+        return (platform dependent error string generator)
     if (err < APR_OS_START_ERROR)
-        return (platform dependant error string generator for
+        return (platform dependent error string generator for
                 supplemental error values)
     if (err < APR_OS_SYSERR)
         return (APR generated error or status string)

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Mime
View raw message