Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!ncar!gatech!udel!mmdf
From: bobs@crdec3.apgea.army.mil (J.R.Suckling)
Newsgroups: comp.os.minix
Subject: Re: Future of Minix
Message-ID: <20213@louie.udel.EDU>
Date: 21 Jul 89 23:19:56 GMT
Sender: mmdf@udel.EDU
Lines: 69

V61%DHDURZ1.BITNET@cunyvm.cuny.edu (Ronald Lamprecht) writes:
> 
> Concerning my proposal to introduce debugging stuff into the library ...

How about this:

    Once I wrote a UNIX plot filter that read UNIX plot and wrote UNIX
    plot.  My problem was the off the shelf tools used the same
    function names for both input and output.  Since I wanted to use
    the standard reader program from one generic output filter. I
    stold( we have the license ) the source for the reader and added a
    set of macros(ie. #defines ) to map one of thies sets of 'names'
    to another set of 'na_es'.  I jest added the underscore in a place
    that would not break anything.

If I was to say make an #include file which, for example

#define strcpy	st_cpy
#define strtok	st_tok
	... ,
	
redefine all of, or a set of, libc interface names with the the extra
'_'. Then I could write an interface library that would alow me to
test pre and post conditions on libc with out touching libc at all.

st_cpy( s1, s2 )
  char *s1, *s2;
{		/* test pre conditions */
	assert( s1 != NULL );
	assert( s2 != NULL );

	isastring( s2 ); /* may only check for a user defined length? */

		/* do the work. */
	strcpy( s1, s2 );

		/* test post conditions */

	assert( strcmp( s1, s2 ) == 0 );

		/* return the required value. */
	return s1;
}

I guess it is clear that you can not use the debugging #include file
when writting the debug library.  :-)

To add the debugging, all I would then need to do is add the #include
to each source file and the debuging library to each linker call.
And then run tests.

I would start to do this for you all, but I only have the book.  Some
day I will break down and get a home computer and it will run MINIX.

If I had a lint I would use it first, but lint is a big program, I
know that was why lint was not ported back the the pdp11's running
2.10BSD.  It is true a good set of pre and post condition tests and
good test data can get bugs that lint will miss.  However, It is hard
to get good test data.

      ___                        < BobS @ ApgEA.Army.Mil. >
 __  /   ` ,    U.S. Army Information Systems Command -- Aberdeen
'/_) \_   /_    J. Robert Suckling      / The opinions expressed are
/__)_(_)_/\)    ASQNC-TAB-T  E5234     /  solely my own and do not reflect
       \        APG, Md,21010-5423    /   US Army policy or agreement.
   \___/        Work: (301)671-3927, 671-2496

I vote for floating point.
I like numbers from 0 to 255, I like the numbers between thies as well.