Re: assert() vs. return(error)

Stuart Celarier wrote:
> Garrett wrote:
>> proactively checking for NULL arguments and things
>> like that, [...] we assume our API is used correctly
>> and if it isn't then we'll fail soon enough when we dereferrence a
>> NULL pointer.
>
> Speaking from a security standpoint, this is not a sound policy. The API
> represents a security boundary: you have no relationship with or control
> over clients using the API. Not validating input coming across the
> security boundary puts the system at risk for attack, whether unwitting
> or malicious.
> ...
> So what is the benefit of not validating input in APIs?

I'll throw my $0.02 in, FWIW, YMMV, etc...

In my own code, I try to avoid having functions with undefined
behavior or input that they can't handle. Asserts, IMHO, should
only be used when there is no other reasonable error handling
mechanism available.

Typically all of my public APIs do simple validation of their input
and return an error or NULL as appropriate for the function. A
*lot* of my code is shared/used by server-side and application code,
and putting the error checking in the API not only saves on code but
also makes everything more robust/reliable.

For *private* APIs, however, I *don't* do all that checking. I
assume that the public APIs have done all of the necessary checks,
and so additional checks are unnecessary. While there is still the
possibility of memory corruption and other programming errors
causing mischief, debuggers, printf's, and tools like Valgrind make
finding these errors pretty easy when the crop up (usually during
testing).

Right now it sounds like Subversion's public APIs are like my
private APIs - bare with essentially no input validation, with
asserts to cause the application to crash when you try to do
something not supported by the API. This behavior is unacceptable
in server applications, and downright rude in user applications
where a crash in Subversion might bring down your IDE and cause
the loss of any modifications...

You can argue about whether to return an error, dummy values, do
a setjmp (bleah!), throw an exception, etc., but ultimately you
need good validation/error handling in public APIs so that the
burden does not fall on the application/server code. Doing so
ultimately reduces code size, improved reliability, and makes the
API friendly to its users.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org