Re: [MiNT] an example of broken lib

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

On Wed, Jun 23, 1999 at 08:57:26AM +0200, Julian Reschke wrote:
> 
> > From: owner-mint@fishpool.com [mailto:owner-mint@fishpool.com]On Behalf
> > Of kellis
> > Sent: Tuesday, June 22, 1999 10:17 PM
> > To: MiNT mailing list
> > Subject: Re: [MiNT] an example of broken lib
> >
> >
> > bug report or wishes for mintlib.
> >
> > Have EAGAIN included (EWOULDBLOCK?)

Frank and I want to introduce a completely new (and extended) errno.h.
This is on the list.

> >
> > snprintf, and vsnprintf added to the lib.

Not possible right now, because snprintf is in the portlib.  It is also on
the TODO list to integrate the portlib but this requires to integrate also
the libsocket.  It's on the list, but takes a little time.

> > Have fchmod added to the lib, even if simply faked with chmod. 
> 
> a) How do you want to fake it?

Frank wants to add this to the kernel soon (Julian is right, it can't be
emulated by the lib).  But this causes a problem:  Software that uses
these calls and evaluates the return value (fortunately, most software
doesn't) will not run under MagiC or plain TOS correctly.  So even if the
calls make it into the MiNT kernel one should consider to either #outdef
them or to emulate them within the software.  Only in very rare cases
these calls (fchown, fchmod, ...) are really necessary.  An example would
be:

	int desc = open ("foobar", O_RDWR);
	unlink ("foobar");
	fchown (desc, 0, 0);

The call to unlink() deletes the directory entry for "foobar" from the
file system and then a call

	chown ("foobar", 0, 0);

could not work (because there is no inode associated with the pathname
"foobar").  However there still /is/ an inode associated with the open
descriptor "desc".  

But in 99 % of the cases, using fchmod instead of chmod is just lazyness
of the programmer (don't have to remember the path name).  And besides,
the above trick would not work with primitive file systems and so MagiC
compatibility is not really an issue here.

> > ulong, ushort etc (in correct h file?)
> 
> Define "correct" file...

sys/types.h, it's already in there (at least in the current developer
version) but you have to specify either -D_SVID_SOURCE or -D_GNU_SOURCE to
activate these typedefs.  Hm, I'm quite sure that they are not yet in
official versions.

Thanks for reporting tho.

Ciao

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