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?
