Re: gcc and mint-libs PL46

[mk@anuurn.do.open.de (Martin Koehling)]

In <9506080259.AA24670@goldfinch.cs.duke.edu>,
Scott Bigham (dsb@goldfinch.cs.duke.edu) wrote:

>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?

If after a library change programs that didn't work correctly suddenly
*do* work correctly, their compatiblity was increased - or wasn't it? :-)

(OK, OK, I should originally not have written `portability' but
`compatibility' - the change would make the MiNTlib a *little* more
compatible to *some* existing libraries [or library/operating system
combinations], and thus more compatible to *some* existing programs...)
(Wasn't it some problem with GNUChess that started this discussion??)

>  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.

*Of course* they should - I certainly didn't mean to suggest otherwise!

>- 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,

Yes, it's a bug; but many existing programs *are* buggy and sloppily
programmed, and I just want the library to behave a *little* more
reasonable if something goes wrong...

>and I _want_ the library to crash.

I don't consider *crashing* reasonable behaviour - a library should
return an error code (or raise an excepton if the language supports
this), but it should *not* crash if this is at all avoidable!
In in the case of NULL pointers this is _easily_ avoidable...

-- 
 Martin Koehling | mk@anuurn.do.open.de | Martin_Koehling@un.maus.ruhr.de