Joseph Galbraith wrote:
> Branko Čibej wrote:
>
>> Stefan Küng wrote:
>>
>>> Hi,
>>>
>>> In the Subversion code, there are a lot of calls to the abort()
>>> function. I think those should be removed and replaced with something
>>> else.
>>>
>> Oh wow, you've gone and opened a can of worms that we've had trouble
>> closing in the past.
>>
>> A note about assert vs. abort: As long as it remains common practice on
>> Windows to compile release binaries with NDEBUG defined, assert is worse
>> than useless.
>>
>> Also, returning an error implies that we can (somehow) recover from it,
>> which isn't always the case.
>>
>> We probably do call abort() in places where we could do something else;
>> such bits can be fixed. But we decided long ago on the policy to not
>> cater to clients that violate the API contract, so returning an error in
>> those cases would mean changing that policy. Nothing wrong with that in
>> general, it's just yet another can of worms.
>>
>> I'm willing to consider using something else instead of abort(). But
>> someone will have to come up with a proposal that works everywhere, not
>> just in Windows GUI with just-in-time debugging.
>>
>
> Two possibilities come to mind:
>
> Stefan, we could use _set_abort_behavior() to turn off
> the stupid message and turn on normal fault handling (in fact,
> I'm about to send a message off to our development group suggesting
> we do the same in our commercial apps.)
>
> A better alternative, in my opinion, would be to establish a
> subversion function, something like:
>
> typedef void (*PFN_abort)();
> void svn_set_abort_function(PFN_abort pfnAbort);
>
That would require setting an abort function for each Subversion
library, and it's a public API change that would have to wait until 1.5
(at least). Not to mention that you'd have to do the same for APR,
because some abort()s are there -- the default out-of-memory behaviour
is to call abort, for instance.
_set_abort_behaviour seems like a sane thing to do on Windows, but I
don't know how it behaves in the presence of possibly-dynamically-loaded
DLLs.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 30 09:22:19 2007