[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: assert() vs. return(error)

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2006-02-14 19:57:07 CET

On Tue, 14 Feb 2006, Garrett Rooney wrote:

> On 2/14/06, Julian Foad <julianfoad@btopenworld.com> wrote:
>
> > 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.
>
> That's not exactly true either. We've had (for as long as I can
> remember) a policy that we don't explicitly check for valid arguments
> to ANY API calls, if a caller passes us bogus data (i.e. a NULL
> pointer to a function defined to not take NULL pointers, etc) we
> crash, with the end result being that these sort of problems are
> usually found quickly and fixed. There's no real difference between
> enforcing such things via an assert and enforcing them via the fact
> that we dereference a NULL pointer a few lines later.
>
I think the most famous example of this is our path manipulation functions
that expect canonical paths (no double slashes except where required, no
slash at the end). It would be both inefficent and cumbersome to have each
such function check that the input is valid in this case. Here, the input
validation must be done on a higher level.

> The fact that in this particular case there was a bug that allowed
> such a situation to be triggered by a client, and that bug didn't get
> fixed instantly is unfortunate, but it doesn't make the general policy
> wrong.
>
Agreed.

//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Feb 14 19:57:36 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.