Sv: I'm back

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

>"Be liberal in what you accept and strict in what you produce"
>
I should put more consideration into the way I express myself via Email.
People often get the feeling I'm trying to tell them I know everything and
they should just do what I say because I know best. When I read my own
Emails, I often see what they mean. I really do not mean it that way,
though.

>Let's compare the two:
>
>
>My code behaves like this:
>  If it detects an invalid argument and debugging suport is enabled it
>  prints a warning informing the user about this, i.e. she is notified of
>  the problem and can try to correct it
>  In any case, however, the user's code can detect that something went
>  wrong, eventually *recover* from the error gracefully and continue
>  running.
>
Of course, as you say, that's nice if the client code contains a bug, and
the program would, if the argument was not checked, show "bad" behavior (as
it would). Completely correct.

However, I somehow don't like the prospect of beginning to speculate as to
what bugs external code might have, and try to code PPlay so as to
compensate for them.

The task is ultimately futile, because buggy code will show "bad" behavior,
nomatter what we do. In this case, checking the argument is not a very
serious performance problem. However, in other cases, it migth be. With
support for RTTI, should we then check that all pointers we get passed are
of the correct type? I mean, if external code contains a bug that passes the
wrong type of pointer, then that migth lead to serious problems... Perhaps
we should also check that the overall entegrity of global data is sound in
each and every function? I mean, its not unrealistic that some buggy piece
of external code migth have been wreaking havoc with the memory that PPlay
occupies... We could then device elaborate safety mechanisms to be able to
reconstruct the correct PFile data, even if it gets corrupted. etc. etc.
etc.

Ok, I'm not being very fair here. That's not what you meant. It however
makes my point clear: we should do everything we can to tell developers who
use PPlay "you got a bug needing fixing here". That's very important. But we
shouldn't fix the problem for them. We can't anyway, and they shouldn't rely
on it. If they have a bug, they should fix it. It's their mess. Programs
that doesn't pass 0 (NULL) when they shouldn't shouldn't be slowed down by
features incorporated to cater to those who do (ok, again, the effect is
quite minimal for this localized example, but it won't be so minimal if this
is applied consistently).

The point of a specification is to say "If you do X, and *not* Y, then I'll
do Z", not IMHO to say "If you do X, and *not* Y, then I'll do Z, but if you
should happen to do Y, then I'll do Z anyway".

>Your code:
>  When debugging is enabled the args are checked for validity and if one is
>  invalid an error message is printed (an internal error, indicating that
>  the problem lies in libpenguinplay itself) and the program is *aborted*.
>
Ok, ok, it shouldn't have said internal error, but that's just a question of
which macro is used.

>  With debugging disabled no checking is done and invalid parameters cause
> undefined behavior.
>
Checking that a pointer that, according to the specification, must not be 0
(NULL) really isn't 0 (NULL), is unnessecary, since that should not happen.
Passing 0 (NULL) anyway must be the result of undefined behavior (ie, a bug)
on the side of the calling code.

So let me rephrase that: "With debugging disabled no unnessecary checking is
done and undefined behavior causes undefined behavior."

I don't see anything wrong with that.

>>Ok, perhaps just "Memory corrupted".
>>
>I somehow can't imagine a case where to print this.
>
I see what you mean. Allocators could incorporate features to check for
memory corruption, though. They don't, though.