Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!usc!apple!bionet!ames!uhccux!munnari.oz.au!otc!metro!basser!nswitgould!nick
From: nick@nswitgould.cs.uts.oz (Nick Andrew)
Newsgroups: comp.os.minix
Subject: Re: Future of Minix
Message-ID: <12996@nswitgould.cs.uts.oz>
Date: 19 Jul 89 12:06:25 GMT
References: <568@amms4.UUCP>
Organization: Comp Sci, NSWIT, Australia
Lines: 42

in article <568@amms4.UUCP>, hjg@amms4.UUCP (Harry Gross) says:
> 
>>>The additional code should
>>>be included in #ifdef DEBUG -- #endif so that it is possible to generate
>>>a fast run-time library and a debugging library version. 
> 
> Agreed.  However, there are other possibilities.  I have given this a bit of
> thought over the past day or two.  If a very fast, very limited output routine
> were created, and calls to it were dependent on a runtime Debug_State variable,
> it could be done without #ifdefs (which I don't like either, unless ABSOLUTELY
> necessary), and without too great an addition to the size of the code.

#ifdefs may be ugly, when used indiscriminately, however a simple #ifdef DEBUG
at the right places in the library could work wonders. I think Andy was
referring to using #ifdefs to keep the PC and ST versions in sync ... which
is truly ugly, as people modifying the code for the PC cannot test the ST
version.

Compiling inbuilt debugging dependent on a runtime variable is truly loathsome;
each module will be larger - don't forget, checking the arguments to functions
could involve as much work (code) as the function itself. The library is big
enough already!  At least, with #ifdef DEBUGs in the library source, if you
suspect program X is making wonky calls to (eg) strcat (like Arc does :-))
then when compiling you can include the debugging strcat.s without searching
the whole debugging library.

Meta-point:  I would have said the major barriers to porting more code to
Minix were lack of some system calls; addressing limitations; and lack of
some standard commands (e.g. awk). Lack of system calls can be fudged.
Addressing limitations are more difficult to get around. And lack of
commands is annoying.

Differences in some ordinary system calls can get you into trouble. Such
as r+,w+ and a+ modes in fopen(). Lack of 3-argument open(). Incorrect
handling of O_APPEND. These are the problems I look for first when porting!

	Regards, Nick.
-- 
			"Zeta Microcomputer Software"
ACSnet:    nick@nswitgould.cs.uts.oz	nick@ultima.cs.uts.oz
UUCP:      ...!uunet!munnari!ultima.cs.uts.oz!nick
Fidonet:   Nick Andrew on 3:713/602 (Zeta)