re: CVS commit: src/libexec/httpd

[matthew green <mrg%eterna.com.au@localhost>]

> >the whole point of having bozofunc() is to avoid having to do any
> >error checking in it.  but now there are calls to several of these
> >that do check errors, and plus the names are too similar.
> >
> >there shouldn't really be a distinction.  all the calls to strdup()
> >you adjusted are (newish) bugs that should just have called
> >bozostrdup(), and there should be no bozo_strdup().  looks like the
> >vast majority of the strdup() calls were added when i merged
> >libbozo work, 5.5 years ago, plus a single one from the initial
> >import.
> 
> I think that there are strdup/alloc/ calls that happen before connection
> time and ones that happen before during configuration and setup. We can
> either have two functions to handle failure appropriately, or one (which
> I prefer I think) and that checks the http->logstate or something to see if
> it should log, or send a response, or both. This requires a bit more
> surgery... Yes, having two functions with similar names is nasty and silly
> and I am not planning to keep it. I just wanted to have some discussion
> first on what to do to solve it. There are 2 or so more strdups that are
> unchecked in the prefs. Let me know how you prefer to go and I will fix
> them.

i don't think it matters where the failure happens.  we only need
one frontend function, and it can exit as necessary.  you can tell
from the contents of struct bozohttpd_t whether a reply can be sent
upon error, or simply exiting.

(it seems that i let strdup(3) back in when i merged agc's library
code, i should have caught that then.   oh well.)

the failure should always log -- but a reply depends.

thanks.


.mrg.