Re: gcc and mint-libs PL46

[dsb@goldfinch.cs.duke.edu (Scott Bigham)]

Martin Koehling writes:

>In <9506062232.AA23109@math.uni-muenster.de>,
>Bjarne Pohlers (bjarne@GOEDEL.UNI-MUENSTER.DE) wrote:

>>|>Chris Herborth wrote:
>>|>>I'm really amazed (and a little frightened) by the amount of flack we're
>>|>>getting for suggesting that the libraries be made a little (a very
>>|>>little!) more robust...  Do all of you always check your paramters
>>|>>before every system call?  [...]

If I have reason to believe they might have invalid values, yes.

>>The fact is, there are libraries
>>(not only the MiNT library) which do not check parameters to fopen &
>>co. So the program has to check it itself to be portable.

>OTOH, there *are* libraries out there that *do* check for NULL filename
>pointers - for maximum portability, the MiNTlib should do so, too!

`Scuse me?  How can changes to the _library_ change the portability of
user code?  Code that expects fopen(NULL, "r") to behave sanely is
already inherently non-portable; hiding that within the library just
serves to exacerbate the problem.

In fact, to use your own argument:

- If your code checks for NULL before calling fopen(), it is guaranteed
  to work on all conforming compilers.

- If your code does not check for NULL before calling fopen(), it is
  _not_ guaranteed to work on all conforming compilers, and will in fact
  fail on existing conforming compilers.

- Therefore, for maximum portability, your code _must_ check for NULL
  before calling fopen().

- Therefore, it doesn't matter what the library does in this case, and
  those two extra lines are two lines too many.

Simply put, if my code passes NULL to fopen(), that's a bug in my code,
and I _want_ the library to crash.

						-sbigham