httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bh...@pobox.com
Subject Question: error checking: how important?
Date Sat, 06 Mar 1999 14:32:41 GMT

John Bley writes:
> So, I started to do this:
> --- util.c.orig	Fri Mar  5 19:39:59 1999
> +++ util.c	Fri Mar  5 19:38:18 1999
> @@ -548,7 +548,9 @@
>  
>      x = strrchr(file, '/');
>      if (x == NULL) {
> -	chdir(file);
> +	if(chdir(file) != 0)
> +	    ap_log_error(APLOG_MARK, APLOG_ERR, NULL, 
> +		"Couldn't chdir to %s, errno is %d", file, errno);
>      }
>      else if (x - file < sizeof(buf) - 1) {
>  	memcpy(buf, file, x - file);
> 
> But then, I noticed this comment directly below another unchecked return 
> value from chdir:
>     /* XXX: well, this is a silly function, no method of reporting an
>      * error... ah well. */

Yet another illustration of how badly we need to get some API doc.  This 
routine is nothing but trouble.  It is just a wrapper generating passing 
on the semantics of chdir in all it's crufty beauty.

Meanwhil you can't really do a chdir since in the window's version it would
require a lock to clarify what thread thinks they own the process working
directory.  Thus you'll notice it is rarely used.

Chdir's saving grace is that users when the directory gets used
that will trigger an error.

Exactly how to log is also a problem.  This routine takes no
dynamic context info so you can't record the request or the
server that was deluded into thinking the directory in question
was useful.

If one wanted a more elegant ap_chdir routine it would have
to return an error and that would require changing the API
- which frightens us.

Ah - legacy code!  When I first came to encounter these mysteries I turned to
the usenet Oracle <http://www.cs.indiana.edu/internet/oracle.html>

  The Usenet Oracle has pondered your question deeply.
  Your question was:

  > Why does no one ever never reuse code?

  And in response, thus spake the Oracle:

  } Once it's broken by the enemy, there really isn't much use for it.

I suspect you have found fertile ground for many interesting discussions.  The
trick is to find the right ones that actually turn up bugs that actually need to
be fixed or at a minimum generate a thought provoking discussion.

> ignored entirely (i.e., not logged or even checked).  There are easily 100 
> such instances.  I loosely define "important" as close(), closedir(), 
> write(), fseek(), dup2().. anything in the "libc" or "syscall" kind of 
> world.  (All examples cited have instances of unchecked return values).

Few programs include code to handle errors that if they occur
the entire enterprise is a hopeless mess.  So for example the
calls on dup2 fall into that catagory.  Programs willing to
call longjmp at the error site sometimes do, but they are rare.

The nobel programmer makes a judgement call betwix:
 - the chance of the error happening.
 - the value of the error reporting he can imagine implementing
 - the mess handling will make of the code
 - the likely hood some other call already guarded against
   the error or reported it.
 - his desire to get something working

So I'm sure we would love to see cases where you think that
the judgement call made was deluded!

> I'm willing to fix these, but I obviously don't want to spend the 
> substantial amount of time it would take if "we" don't really care too 
> much about providing this class of information to the user.
> PR#3098, for instance, complains about exactly this type of thing, but is 
> listed as non-critical.

More power to you!  The error handling in buff.c is amazingly subtle
but to date I've often thought I had a bug when in fact I was just
confused.  Currently I think there is a bug in read_request_line of
this character but since I've so often turned out to have missed the
subtle way the gears turn I remain doubtful.

> If the Apache community would like me to fix most of these instances, or 
> provide the rather large list of locations where these return 
> values are ignored, I'd be happy to.  But I don't want to proceed with 
> this kind of large-scale job without the support and advice of the community.

One at a time.

> -- 
> John Bley - jbb6@acpub.duke.edu
> Duke '99 - English/Computer Science
>   Since English is a mess, it maps well onto the problem space,
>   which is also a mess, which we call reality.     - Larry Wall

 - ben

"Analysis is easier than synthesis." - Fred White

Mime
View raw message