httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <dgau...@arctic.org>
Subject Re: [APR] Comments to proposed function interface
Date Mon, 25 Jan 1999 01:03:52 GMT


On Fri, 22 Jan 1999, Martin Kraemer wrote:

> *** Types ***
>[use abstract names, not base types]

Yup, absolutely necessary.  Although I think it would behoove us to do
64-bit files wherever we can as the default.

> APRstatus 
>
> 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!)

Passing unions or structures as results is handled very poorly by most
compilers.  The code generated is horrid.  It's also a weak area in terms
of compatibility between compilers -- for example gcc and and the native
cc may disagree how to do it.

I haven't looked at APRStatus in detail.  But if it is so complex that a
SINGLE comparison cannot be used to determine if something abnormal
happenned, then it is broken.  In the unix API the comparison is almost
always ">= 0". 

Also I'm not sure why the complexity is required.  In 99% of the cases an
error occured, or it didn't.  I don't want craploads of code in the
library just to say "oh hey, you're shoe is untied, thought you might like
to know, I did what you asked anyhow".

> apr_open(): 
>   A flag for binary files is needed for DOS / EBCDIC based systems.

I would say the default is binary.  Then if we ever find a need for text
files write support for them as a layer.  But I find them pretty pointless
-- just define the fgets equivalent to grok \r\n and \n. 

> apr_opendir()
>   This function is too *nix centric. A good abstraction could be
> created with a callback interface where the caller supplies a
> function which is called for each file in a directory. Its
> return value would determine if more scanning is desired or if the
> caller found the corresponding file already, or if the entry
> should be added to an automatically created (and sorted?) array.
> While the BSD4.3 scandir() function could serve as an example
> interface, we could define a different callback model as well.
> Such a function would easily wrap the unix
> opendir/readdir/closedir calls, the DOS (and even CP/M) specific
> findfirst/findnext functionality and other OS models.

Well I don't see any defn's of apr_readdir ... and at any rate there's no
difficulty turning findfirst/findnext (dos, os/2, win32) into
opendir/readdir... I don't really understand the objection.  Or are you
saying that we don't allow ourselves the opportunity to scan for "foo.*"
which the DOS crowd supports "in the kernel" ?  Yeah that'd be good... but
then we have to worry about portable file patterns :)

> apr_enumeratehostent()
>   Like in the directory scan case, the natural solution to an
> unknown number of result entries is not building the loop at
> each calling location, but to use a callback and integrate the
> loop into the function. The callback function can then do
> whatever it wants with the individual entries.
> Alternatively, the apr_enumeratehostent() function could return
> the number of entries and a complete array of entries which
> could simply be indexed.
> The proposed interface (start with an index value of zero and 
> continue until the "next value" is returned as 0) is to
> deadloop-prone. It seems more natural to terminate the loop with
> a value that can not be used as a valid index (-1).

I really really really don't like callbacks.  They turn the user's code
inside out and make it more difficult to write.  Rather than the suggested
approach which turns the library inside out -- and you only have to write
the library inside out, the user code "looks normal". 

Dean


Mime
View raw message