Stuart Celarier wrote:
> The rest of the C world uses the assert macro to compile assertions in
> to the debug version, and to remove assertions in the release version.
> Subversion always compiles with assertions in the code, including the
> release version.
>
> For Subversion, assert means "conditional abort."
>
> I haven't seen another software project change the meaning of assert in
> this way, so I don't think much of the existing writing on assert
> applies to Subversion.
You're over-simplifying. Don't read too much into anything that was said in a
mailing list thread. :-) Subversion does not define assert in this way, it's
just that some builds of Subversion do (like perhaps some or all of the
official Windows binaries). Anyway, the "goes away in release builds" aspect
is not the only significant aspect discussed in writing.
We might well want to use assertions that remain in release mode. We might
well want to use both kinds. We haven't discussed it enough yet.
Branko Čibej wrote:
> The "unwritten policy" about Subversion and assert is that we use assert
> to check for conditions that "can't happen".
I don't think most developers have a consistent view on that. Mostly, asserts
are simply not used, and I feel this is because many people fear them because
they see only the obvious result that the program will terminate, and, lacking
the knowledge and experience to see where this is a good thing, just assume
that it is a bad thing.
> That obviously means we can't use assert to check function arguments,
Not true. If one accepts that "assert" is allowed at all, it's perfectly valid
to check arguments of private functions because we know all the callers and
what they can do. As for public APIs, that's partly what the debate is about,
and the answer is far from obvious.
> and it's especially evil
> if a malicious client can trigger an assert on the server.
Certainly.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 14 16:14:00 2006