httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <>
Subject Re: Errno code in APR again.
Date Fri, 07 Apr 2000 15:30:53 GMT
(Not exactly just-in-time, but that's not a problem...)

These comments address only the patch posted yesterday for the file 
APRDesign.  I have reviewed some of the code where needed to try to 
clarify issues in APRDesign, but APRDesign is the important part and
the only part I looked at in detail.

A. Philosophical disagreements and/or requests for more documentation

1. macros to avoid adding/subtracting APR_OS_START_SYSERR

Three of the four of us heavily involved in the recent ap_status_t
discussions wanted such macros.  Of course, there was no consensus on
a name, but I'm easy on this.

I won't speak for why others wanted such macros, but I can list my own

a) general

   i. I would be surprised if the current solution (or the solution I
      posted recently) is the best possible for current and future
      requirements.  With no macro, our implementation details are
      sprinkled all over APR, which would be a disincentive to future

      To the extent that implementation details are spread over
      app-level code, the disincentive grows exponentially.

      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

      In other words, a message like

      "system error 4011 opening config file: permission denied"

      instead of 
      "error 14011 opening config file: permission denied"

      allows a user to know where to find additional information on
      what went wrong without looking at the application source code
      to know what type of error code it is.
b) split out by macro type

   i. macro to build ap_status_t from os-specific error

      In some cases (I know you disagree with the need but I'm stating
      this for completeness), non-APR code will want to build an
      ap_status_t from an OS-specific error.  Even if we aren't
      worried about spreading out our implementation, this is an
      ugliness which should be hidden from the app.

  ii. one or two macros to test for and/or extract an OS-specific

      This is basically the same argument as the previous, but perhaps
      you are less disagreeable to this concept than to one that
      builds ap_status_t since this concept is primarily an app-layer

2. please discuss APR_OS_START_CANONERR in APRDesign

3. resolver errors

   i. h_errno

      I like that errno is handled the same on all platforms but I
      don't like that h_errno is handled differently.  Not all
      platforms have h_errno, but AFAIK everything but Win32 uses
      h_errno today.  This isn't as important as errno, but I would
      think that the same arguments for all platforms being able to
      "return errno" would hold for h_errno as well.

  ii. canonicalization of resolver error values

      These need to be canonicalized (only when the app asks for it if
      you insist :) ) at least enough to hide the usually-meaningless
      difference between NO_ADDRESS and NO_DATA.  Yes, many systems
      define these to be the same numeric values, but this is not

4. the issue of which party instigates the canonicalization of error

   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".

   I won't dispute that particular statement.  However, I think that
   optimizing this type of error path for time is misguided.

   Surely there are more compelling reasons to force the app to do
   something special to get a canonical error value.  Please list them.
   I don't at all consider this a silly request, particularly since in
   my past experiences with libraries/APIs/whatever I have never heard
   of one that worked this way (and APR is hardly unique in being
   portable).  A library such as APR is mostly about taking the onus
   of one chore or another off the programmer, so I think more
   justification is needed for when we do just the opposite.

5. your prototype for ap_strerror()

   Your prototype is certainly the one I would like to have.  However,
   you may recall from my previous post of an ap_strerror()
   implementation that  Windows has a special storage management
   requirement associated with retrieving the description for an OS
   error code.  To avoid storage leaks or even uglier interfaces, the
   ap_strerror() caller needs to provide a buffer for the description
   (and thus a buffer length).

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 :) )

Thanks and best wishes,

Jeff Trawick | | PGP public key at web site:
          Born in Roswell... married an alien...

View raw message