> >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.
