httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Slemko <ma...@znep.com>
Subject errnos and buff.c
Date Wed, 16 Dec 1998 06:19:43 GMT
Right now, in numerous places, we assume that buff.c functions will have a
valid errno if they return -1.  In some cases, they do set an errno.  

But in others they don't.  They just leave any old errno there.  

This is a major problem because it can cause infinite loops in userspace.
In this particular case, ap_send_fb_length calls ap_bwrite.  For some
obscene reason, it loops if errno == EAGAIN.  I'm not sure why; even if it
were nonblocking, we would end up busy waiting.  It just can't be
nonblocking.

in any case case, ap_bwrite checks if there was an error:

1207        if (fb->flags & (B_WRERR | B_EOUT))

and, if so, just returns -1 without touching errno.  errno happened to be
EAGAIN from some previous IO, so we get screwed.

There are other problems with ap_send_fb_length WRT not checking return
values, but those are other problems.

So does anyone know what the goal was?  First, I think the useless EAGAIN
checks (ie. checks in places where we don't deal with nonblocking
descriptors anyway) should be removed.  

Second, either functions have to always set errno when they return an
error or never set it when they return an error.  Which one is it to be?
And what errno can we set for a generic error when we don't have the real
errno?


Mime
View raw message