Re: I'm back

[Christian Reiniger <warewolf@mayn.de>]

Bjarke Hammersholt Roune wrote:

>I looked through the code, and realised we have a somewhat differing view of
>how to check for arguments.
>
>I consider it a bug to pass an invalid argument, you seem not to. Let me
>give an example:
>
> int ppfFlush (ppFILE *stream) // FIX: make threadsafe
> {
>  if (stream == 0)
>  {
>   ppWarning ("Invalid Arguments");
>   return EOF;
>  }
>...
> }
>
>This function is coded in suchs a way as to expect a stream value of 0. Its
>completely normal behavior, and is handeld as suchs.
>
>The way I would have coded the same function is like this: (using the
>proposed ppAssertN to not evaluate the assert in release builds)
>
> int ppfFlush (ppFILE *stream) // FIX: make threadsafe
> {
>  ppAssertN(stream != 0);
>...
> }
>
>or:
>
> int ppfFlush (ppFILE *stream) // FIX: make threadsafe
> {
>#ifdef DEBUG
>  if (stream != 0)
>     ppInternalError("Invalid argument");
>#endif
>...
> }
>
>This means that passing 0 as an argument is a bug, and therefore should not
>be considered in release builds. Its simply not part of ppfFlush()'s
>specification that it should handle parameter values of 0.

"Be liberal in what you accept and strict in what you produce"

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.

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*.
  With debugging disabled no checking is done and invalid parameters cause
  undefined behavior.

Say what you want - I like my version better ;)

>>>"Memory corrupted or bug".
>>
>>Uh, don't know about the last one...
>>
>:)
>
>Ok, perhaps just "Memory corrupted".

I somehow can't imagine a case where to print this.


	Christian
-- 

Drive A: not responding...Formatting C: instead