On Fri, 20 Jun 2003, Sander Striker wrote:
> > From: cmpilato@collab.net [mailto:cmpilato@collab.net]
> > Sent: Thursday, June 19, 2003 10:44 PM
>
> > Christian Daudt <csd_ob@daudt.org> writes:
> >
> > > So someone else doesn't spend a morning trying to figure why they're getting
> > > coredumps all of the sudden...
> >
> > Do I detect (in your patch) a note of sarcasm? :-)
> >
> > Dude, I'm sorry you wasted time looking at the wrong thing. But the
> > clues are present. In the very libsvn_ra_dav code you pasted, there
> > is a comment indicating that that section of code expects to get that
> > name= attribute. Now, I dunno why you're seeing a case where this
> > attribute isn't present, but if I could be so daring as to risk
> > annoying you -- would you mind trying to solved *that* problem? I
> > mean, if you have a Subversion server that's sending your client a
> > bogus REPORT response, by golly we want to know about it.
>
> In any case, we should not segfault on it. It is bad mojo if the server
> can let the client crash (or the other way around) by bad data.
>
> cvs is not hostile data proof and it's a pain in the butt.
As a guy from the side-lines, I agree fully with Sander here. The whole
"don't check errors, segfault!" logic is great... in some situations. The
whole point of that type of coding is to find errors as early as possible
and to make it so that you can't ignore them when you do find them. That
works great for some things, but not for all possible cases. I always
think of it this way:
There are three types of errors in code, and three appropriate ways to
resolve them.
1) Syntax errors.
Resolution: The compiler had better print an error and quit.
2) Semantic errors. ie the syntax is right, but the arguments are wrong
or your understanding of how the arguments are used is wrong.
Resolution: Segfault. This type of error should happen often enough that
the code shouldn't be committed without somebody seeing the segfault
during testing.
3) Logic errors. The code is using all of the APIs correctly, but there
is a logic error and something is being filled out wrong.
Resolution: Print an error message and fail gracefully. This type of
error is the rarest type, and is likely to sneak through testing.
The biggest problem is identifying the difference between type 2 and 3
when you are writing code. :-)
As proof that even Apache follows this model, try this sometime:
telnet apache_server 80
GET / HTTP/1.1
Host:
Apache doesn't segfault, even though the data it is receiving is bad.
This is the same type of error that you are discussing in this thread.
The syntax is right, the understanding of the API is right, but the logic
is wrong someplace.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 20 01:43:28 2003