Re: [MiNT] compiling a kernel

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

On Sat, May 06, 2000 at 08:43:34PM +0300, Martin-Éric Racine wrote:
> On 2000-5-6, Martin-Éric Racine <q-funk@pp.fishpool.fi> wrote:
> 
> > On 2000-5-5, Guido Flohr <gufl0000@stud.uni-sb.de> wrote:
> > 
> > > > (and CAB.OVL cannot be compiled using the current MINTLIB:  too
> > > > many macros have disappeared).  
> > > 
> > > Which macros have disappeared?  
> > 
> > See the enclosed error.log produced by GCC:
> > 
> > init.c:186: `_IOREAD' undeclared (first use in this function)
> > init.c:188: `_IOWRT' undeclared (first use in this function)
> > init.c:190: `_IORW' undeclared (first use in this function)
> 
> Those used to be defined in stdio.h but have disapeared.

Yes, they have vanished because the stdio model has changed.  They were
undocumented and were never recommended to use.  But you're still not
lost, you can fix the sources to compile with the new stdio model. 

In init.c there must be something like:

	FILE* f = ...;

	if (f->flags & _IOREAD)
		...
	else if (f->flags & _IOWRT)
		...
	else if (f->flags & _IORW)
		...

Howard should change the sources like this:

#ifdef _IOREAD
	/* MiNTLib < 0.54.99.  */
	if (f->flags & _IOREAD)
		... continue like shown above
#else
	/* Recent MiNTLibs.  */
	if (f->__mode.__write && f->__mode.__read)
		... like old code for _IORW
	else if (f->__mode.__write)
		... like old code for _IOWRT
	else if (f->__mode.__read)
		... like old code for _IOREAD
#endif

Be careful, the order is reversed for the new MiNTLib.  In fact both the
old and the new stdio version use a bitfield to determine the FILE
flags.  But the old method was a little insecure because the file flags
were not always clear:

#define _IOREAD		0x0001
#define _IOWRT		0x0002
...
#define _IORW		0x0080
...

It was possible that all three bits were set and you were not able to
determine whether the file was actually open for reading, writing or
update (read/write) mode.  It all depended on the order in which you
checked the bits.  Now things are always clear:

typedef struct 
{
	unsigned int __read: 1;
	unsigned int __write: 1;
	unsigned int __append: 1;
	...
} __io_mode;

Either the read bit is set, or the write bit or both.  I don't remember
how old library versions reacted when opening the stream in append mode
(with "a").

I hope nobody misunderstands the above explanation as an invitation to
make assumptions about the internal representation of a FILE.  This is
really strongly recommended and seldom (if not never) really needed.  If
you need to remember the mode that a stream was opened with you should do
that in a private structure.

Another thing that has changed and may cause problems is the common but
nonetheless illegal practice to open streams with a "rw" mode.  This has
to be "r+", "rw" only exploited a bug in former MiNTLibs.  Opening a
stream with the mode "rw" will now cause an error (which is the correct
behavior).

Another word of warning: If Howard used the flags in init.c for changing
the open mode after the file had been opened (which would be a very bad
idea) you should at least flush the buffer (with "flush (f)") before you
change the io mode bits.  I can't guarantee that such a hack will still
work but flushing the stream is the least you have to do then.

> > domail.c:63: `EBADREQ' undeclared (first use in this function)
> 
> Seems replaced by EBADR in the current lib.

Right.  You can also compile with -D__LOOSE_ERROR_CODES.  That will
activate the old compatibility names (see <mint/errno.h>).

You may think it is pedantic that I protected the library namespace by all
these macros but in the past the relaxed namespace policy of the MiNTLib
has always caused a lot of problems that are sometimes hard to find.  The
correct name "EBADR" is reserved to the libc whereas "EBADREQ" may be used
by application code.  Thus, still defining EBADREQ will help to compile
unclean software but will prevent compiling software that uses by accident
the unofficial names for other purposes.  The new, restrictive namespace
policy of the MiNTLib favors clean code.

As for the "missing" aesbind.h, vdibind.h, gemfast.h:  I have removed them
because they are part of the GEM library and not of the libc, and
furthermore they didn't match anymore with the GEM library itself.  It
would probably make sense to add the headers for compatibility to the GEM
library (only consisting of an "#include <gem.h>).  But I am not the
maintainer of libgem.a.

Ciao

Guido
-- 
http://www.stud.uni-saarland.de/
Send your spam to president@whitehouse.gov and your replies to
mailto:guido at freemint dot de