Re: gcc and mint-libs PL46

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

What you wrote:
> Chris Ridd <chris@imc.exec.nhs.uk> writes:
> |> 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?  Do all of you always check your return
> |>> values?
> 
> |> Amen. How much larger would a program be if the libs did the check for
> |> NULL (once) instead of the program (many times, potentially)?
> 
> Your program has to check for it anyway, so what's the point?  NULL is
> *never* a valid pointer, and if you pass it to a function that expects
> a valid pointer all bets are off.

The problem is that it should just fail instead of keeling over dead. 
You're not trying to do something totally ridiculous here, you've just
got a pointer that you forgot to initialize.

Before you start saying "uninitialized pointers in C are in an unknown
state, not NULL", what if you're using C++?  In C++, char *foo; makes
foo a pointer to NULL.

_unx2dos() should check for a NULL pointer.  That's all we're asking for.
We don't want it to check for *any* possible bogus value, just NULL. 
*Any* other bogus value will probably fail with ENOENT, right?

A "bad filename" should be a recoverable error, no matter what that bad
filename was.

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