William A. Rowe Jr. wrote: > Branko Čibej wrote: > >> Paul Querna wrote: >> >>> On Tue, Dec 15, 2009 at 2:05 PM, William A. Rowe Jr. >>> <wr...@rowe-clan.net> wrote: >>> >>> >>>> Should apr_initialize and friends be programmed to go 'bang' and drop out >>>> with a stderr emit, if compiled against a x.y.0-dev release and run against >>>> x.y.*[1-9]? Or, at least a stderr warning at initialization time? >>>> >>>> Seems like a simple, sensible fix. >>>> >>> No, APR is a library, it has no ownership over stderr/stdout. >>> >> OK, stderr isn't a good idea, but APR can abort, right. >> > > Well, if not stderr, then what? In this context (startup) stderr has a well > defined meaning. I have no problem with my versions for HP/UX hacked with > the [rejected] patch to allow HP libdld to emit a sensible message about what > function could not be resolved by apr_dso(). There is no way to ask HP/UX > for the contents of that message programatically. And by jove, libdld is ... > wait for it ... a library! :) > > So for APR 2 I can see an optional behavior to allow/prohibit emitting any > messages to stderr. That would cover both Paul's and other use cases. > > And apr_initialize() could certainly return APR_SUCCESS or a failure code > that maps to 'wrong apr version' or some such, at APR 2.0. > > But abort() seems too unilateral, let the app author decide how pedantic > to be, or how to exit gracefully, if there is no indication of what exactly > was the problem? >
How is aborting on memory allocation failure any different from aborting on version mismatch? As for indication of failure -- by zeus, if inspecting a core dump doesn't help, then nothing will. :) Especially if we document that an abort in apr-initialize most likely means you diddled with your library versions. (And maybe it's just me, but I prefer debugging a consistent abort on start-up than a random abort because of ABI mismatch). -- Brane
