httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rodent of Unusual Size <Ken.C...@Golux.Com>
Subject Re: [APR] Comments to proposed function interface
Date Fri, 22 Jan 1999 22:09:17 GMT
Martin Kraemer wrote:
> 
> All parameters which specify the the size of an in-memory-object
> should be `APRSize' with an appropriate typedef somewhere in the
> platform specific parts.

Part of me likes that, and part of me dislikes it.  I guess the
Java fixed-and-reliably-sized primitive types have spoilt me.
It's almost certainly less important here, since no-one is
expecting the object code to be portable the way Java bytecode
is.

> APRstatus
> 
> While this may be a VMS specialty, the choice of status fields
> does not look very well thought-out to me. While it is good to
> have a severity level (I remember "I"nformatory, "W"arning,
> "E"rror and "U"nrecoverable error flags back from my old OS/360
> days), and a separate "problem" flag, plus an error message
> number value, I think that putting the severity into the LOWEST
> three bits (and combining them with the "problem" bit) isn't
> such a terribly good idea.

Why not?

>                            What strikes me especially is the
> fact that the severity level isn't ascending (or I must have
> misunderstood the meaning of "Warning" vs. "Unqualified success"
> or "Informational". At IBM's, an information is less severe than
> a warning, is it?).

It's based on the low bit denoting goodness (set) or badness
(clear).  The level of goodness or badness depends upon the
value of the field, but you can make a determination based
upon the simple oddness or evenness of the result.

Once you've used the low bit to mark success or failure,
the values are ascending: WARNING < ERROR < FATAL and
SUCCESS < INFO.

Of course, that particular paradigm followed from the PDPs
and VAXes (and then Alphas, I think) having instructions
to test and branch just on the low bit.

Changing it so the success/failure bit is on the high end
of the field would make things a bit awkward, since there
are more failure levels than success ones, and to keep
the field ascending may mean discarding the visceral
association of 'non-zero means true/good/success.'  Of
course, Unix doesn't really have that association; more
things return 0 for success than otherwise.  My VMS
experience speaking; 'never mind.'  I've always felt
weird about "a false return value means it worked,"
anyway. :-)

> Then there's arbitrary constants like 0xFFF8 denoting "errors
> from any origin". Why not use the value 0 here?

I thought I elided that.  I think it's safe to ignore that
part for now; it seems to have come from a miscommunication
during one of our lunchtable discussions.

> What I propose is to leave the AND'ing, OR'ing and SHIFT'ing all
> to the compiler (we're not living in assembler days anymore!)
> and use the vehicle of structures (and unions?) to achieve the
> same result, albeit with an easier interface:
> 
> typedef struct {
	:
> } APRstatus;

Unfortunately, that opens the possibility of the structure
changing and breaking compatibility.  Won't macros do as well?

> If we're really worried about space (which I doubt in times of
> MBytes and GBytes of installed ram), OR if it is important to
> have "error constants", then one could still fall back to bit
> fields and create a union of an unsigned long (and it wouldn't
> matter if a long is 4 or 8 bytes long) with the bit masks:

I'm not worried about space so much as compatibility and
call packing/unpacking complexity.  I have no objection to
a fixed-size union.  I notice you've glossed over the
shared/origin-private capability; an oversight?

> *** Passing Buffers ***
> 
> Some functions in the spec require a buffers of the correct size
> to be passed down which is then filled in by the function. I
> think that this can be avoided in many cases (especially in
> cases where the size isn't known beforehand, like in
> apr_netaddrtostring() or apr_format_time()). Since we pass a
> pool pointer to most of these functions, it only seems natural
> to allocate a string in the function and return that instead of
> having to check everywhere whether the passed buffer is big
> enough.

Heh-heh.  One of the big discussion issues at lunch, in private
email, and on the telephone has been about the use of pools.
I'm not going to tackle it now, though..
-- 
#ken	P-)}

Ken Coar                    <http://Web.Golux.Com/coar/>
Apache Group member         <http://www.apache.org/>
"Apache Server for Dummies" <http://Web.Golux.Com/coar/ASFD/>

Mime
View raw message