Re: gcc and mint-libs PL46

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

What you wrote:
> 	There is no way to decide at the application level if "fname"
> points to a valid string. Only the kernel knows the memory layout of a
> user process, which means that the error can only be detected when the
> final system call is issued (open() in Unix, Fopen() in MiNT).

A test for NULL would be simple, and quick.  Ex,

fname ? return Fopen( fname, mode ) : return NULL;

(I know that's not exactly what's in fopen, since the kernel Fopen works
differently and doesn't use the text-based modes.)

If the filename isn't valid, they'll get ENOENT in errno; NULL isn't a
valid filename, therefore...

> 	What you propose is _exactly_ what should be avoided: putting
> tests in places where they don't belong. Duplicating tests at all layers
> of a library is not only a waste of CPU, but it also pollutes the
> conceptual model. You should think of library function as "contracts":
> if you give them valid input, then they will behave in a predictable
> way. If you give them garbage, you'll get what you deserve :-)

So, are you saying the _kernel_ should be checking for fopen( NULL, "r" )
instead of the library?

I thought library design _required_ you to expect garbage-in and give a
reasonable error (why else do we have return codes?  why else do we have
errno?  then again, it's not like most UNIX hackers bother to ever check
their return codes...).

Now that I think about it, the kernel might be a good place to do it.  But
then you start ending up with this huge kernel that spends most of its time
checking its function parameters.  This might not be such a bad idea;
Windoze 3.1 was made quite a bit more stable than Windoze 3.0 just by adding
some sanity checking to the system calls.  The whole system sucked to start
with, so nobody noticed the speed delay.

IMHO, parameter checking should go in the library, especially something as
trivial (and fatal to your application) as this.  After all, if fopen()
is just a concentrated minimal call, why no just use Fopen() and hit the
kernel directly?

The fopen( NULL, "r" ) example is an example of something that would
only happen because the _user_ didn't enter the right data at some
point, or maybe they've screwed up a configuration file.  That's why I'm
arguing for this sort of thing (I'm a strong advocate of sensible
user-interface design).  The programmer is never going to cause this
(how often have you put fopen( "", "r" ) in your code instead of a
hard-coded filename?).

As a programmer, I'd rather have fopen fail, and _then_ figure out why,
instead of checking the parameters before making the call.  That's (IMHO
again) the more logical way of doing things.

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