Re: gcc and mint-libs PL46

["Chris Herborth" <chrish@qnx.com>]

What you wrote:
> 
> If one of my programs calls fopen(NULL, "r"), then I *want* it to fail with
> a bus error, so that I can debug it -- it should never be in a state where
> it thinks a null pointer is valid data.

You're assuming that you'll never write an application with user input.
OR that you'll always check user input before you make any calls that
depend on it.

> If GNU Chess is expecting that NULL is a valid string for any purpose at
> all, then it's buggy. No doubt dereferncing location 0 works on many
> operating systems (and probably usually results in an empty string), but
> expecting this to always work is very bad programming practice.

Nobody's expecting it to work, really, they just expect it to fail in a
reasonable way.  Keeling over dead is the UNIX way, of course, but it'd
be nicer to spit out an error and then die.  People get disturbed seeing
bombs and no explanation.

> As a parallel example, what should the library do for fopen(-1L, "r")?
> -1L doesn't point to a valid path name; should fopen() then return NULL?
> Or is it OK to crash? Carried to an extreme, we would have the library
> catching all bus errors and trying to recover transparently. That may
> not be a bad idea in some cases; but it would make debugging a real
> nightmare.

How would you call it with -1L as the pointer?  Unless your application
has already gone nuts and puked all over its memory space... you'd never
do this explicitly.

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?  Do all of you always check your return
values?

I mean, I always check my return values, and it's a pain in the neck that
C doesn't have a clue about exceptions...

-- 
----------========================================================----------
Chris Herborth, R&D Technical Writer       Arcane  Dragon     chrish@qnx.com
QNX Software Systems, Ltd.                  -==(UDIC)==-         |||  JAGUAR
http://quest.jpl.nasa.gov/Info-ZIP/people/cjh/chris.html        / | \ 64-bit