On 2008-06-16 16:17:05 +0100, Julian Foad wrote:
> Do you mean in the case of corruption caused by a malicious user? Yes,
> you might well be right, but that condition is impossible to distinguish
> programmatically so it's a moot point.
Of course, but what I want to say is that in the doubt, aborting
immediately is probably safer (because less code is run), whereas
in the other cases, if an error is just reported, can anything
really useful be done without the risk to corrupt data? I mean,
as the failed assertion can imply incorrect data in some other
variables or memory structures, trying to fix things and ignore
the error (or trying to do some clean-up before terminating with
a "more useful" error for the user) can corrupt data even more.
So, I doubt this is useful enough compared to the risk of losing
data, even if this risk is quite low... unless you know reasons
for which there will be no problems.
> I think your concern is perhaps that higher-level code might ignore
> assertions unintentionally or without due consideration. The answer here
> is to help higher level code to do the right thing. For instance, we
> could make the standard error-ignoring mechanisms like
> "svn_error_clear(svn_error_t *err)" NOT ignore assertions, and provide a
> separate "svn_assertion_clear(svn_error_t *err) for those few cases
> where code needs to handle assertions in a special way.
>
> Does that approach address your concerns?
Well, without knowing what higher-level code does exactly, it is
difficult to say. Also can it make the difference between a failed
assertion (that indicates some bug) and a simple error coming from
the environment (e.g. something like a file not found in a low-level
function).
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-06-17 10:53:30 CEST