Re: [MiNT] an example of broken lib

["Guido Flohr" <gufl0000@stud.uni-sb.de>]

Hi,

On Wed, Jun 23, 1999 at 11:57:01PM +0200, Julian Reschke wrote:
> > Yep, sorry, this is insider knowledge: Could you change the type of the
> > first argument from "short int" to "long int"?  Otherwise, the library
> > binding actually had to check if the descriptor is out of bounds.  I think
> > this is better done by the kernel.
> 
> That would be inconsistent with the rest of the GEMDOS bindings (if by
> descriptor you mean "file handle").

The other GEMDOS bindings are inconsistent with the rest of the world
(where a file descriptor can be 32-bits wide).

With 32-bit descriptors I could offer optimized inlined versions or even a
macro (without side effects). But that would require that I could pass the
return value from the GEMDOS trap unchanged without further checking.

Why not improve things? 

> > A propos library binding: What if Ffchown() and Ffchmod() is not supported
> > by the kernel?  I would suggest to always return 0 for success in the
> > library.  For older MiNT versions this is somewhat problematic but it will
> > be handy for MagiC and TOS without mulit-user support.  Anybody has got
> > problems with that?
> >
> > The same applies under MiNT if the FS doesn't support these calls.  I
> > think it is ok to report success nonetheless, is it?
> 
> The kernel should pass back what the XFS reports. It shouldn't make any
> assumptions about why a particular error code is returned.

In this particular case, no.  The error code "EINVFN" should be set if the
file descriptor argument corresponds to a pipe or socket, not an ordinary
file.  If the kernel reports success for FAT file systems it doesn't hurt
and we could still distinguish this case.

What does BSD or Linux report in such a case?

Ciao

Guido
-- 
http://stud.uni-sb.de/~gufl0000
mailto:gufl0000@stud.uni-sb.de