apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe Jr." <wr...@rowe-clan.net>
Subject Re: [VOTE] APR versioning rules w.r.t. released snapshots
Date Wed, 16 Dec 2009 04:50:01 GMT
Branko ─îibej wrote:
> Paul Querna wrote:
>> On Tue, Dec 15, 2009 at 2:05 PM, William A. Rowe Jr.
>> <wrowe@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?








Mime
View raw message