Jeremy Whitlock wrote:
>>> Is this another option:
>>>
>>> 4. Don't have platform-specific visibility for APIs in Subversion at all.
>>> Instead, move the #defines that toggle the availability down into the
>>> functions/structures themselves so that on platforms where the
>>> functionality is not available, a not-implemented error is thrown?
>>>
>> +1. I like that idea! That would make things much easier from a SWIG
>> point of view.
>
> While working on making this a reality, I realize that most of the
> functions affected by this return void. One option would be to rev
> the related functions, use abort() in the function being revved and
> make the new function return an svn_error_t, which would use
> SVN_ERR_ASSERT to return the error when being invoked on the wrong
> platform. (This is suggested in another thread:
> http://www.nabble.com/-PATCH--svn_dso_initialize-can-*silently*-fail-to-create-lock-td18777052.html)
> But is this necessary? Since the function signature isn't changing,
> nor is the content being returned changing, do we need to go through
> the revving process? In this scenario, either you can call the
> function or you can't. Why should the consumers of these functions
> have to care?
I've not thought fully through this, but if the function now returns an
svn_error_t *, and that error goes unhandled (because callers weren't
expecting one), that's a memory leak and, in certain debug modes, an abort()
as a result of such, right?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-10-09 05:59:57 CEST