Date: Tue, 8 Aug 2000 09:30:27 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Bruce Korb <bkorb AT sco DOT COM>
cc: djgpp-workers AT delorie DOT com
Subject: Re: DJGPP patch for fixincludes
In-Reply-To: <398ED65F.52CF62FA@sco.com>
Message-ID: <Pine.SUN.3.91.1000808092918.4905A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 7 Aug 2000, Bruce Korb wrote:

> > It was enough to find another bug in the DJGPP version of fixincl: the
> > external fixes didn't work because I failed to consider the
> > possibility that the input and the output files are the same file.  So
> > redirection nuked the input before the program got a chance to look at
> > it.
> 
> That was why I originally had all that mumbo-jumbo with *three* different
> file names

Yes, I understood that after I found the bug ;-).

> As for your other patch, I am going to disable the file name test
> disablement.  It is not really necessary for the "make check" to
> run on DOS.

My problem was that only a couple of tests are marked to catch
testing.h.  This means that any new type of fix you introduce in the
future will have to be marked for testing.h as well, to make sure it
works for the DOS version, since testing.h is the only file that gets
fixed when the DOS version is tested.  If you are comfortable with
that, I have no objections.

> I think it safe to assume that ``system(3)'' will work essentially
> the same way on UNIX and DOS.

That is not a very good assumption, although when $SHELL points to
Bash, the similarity is almost 100%, because in that case, DJGPP's
system(3) simply invokes Bash with its unmodified argument.

(When SHELL points to a stock DOS/Windows shell, system(3) tries very
hard not to call the shell, because stock shells are so dumb, and
instead emulates the shell functionality, adding some nifty features
such as long command lines, more consistent quoting, etc.)

> (By the way, if ``pz_machine'' is NULL, then fixincl is operating in
> test mode.)

I thought someone might want to test all the machines and all the
files separately, so I didn't want to overload $TARGET_MACHINE and
`pz_machine' with more magic meaning.

Anyway, the FIXINCL_TEST hack was originally introduced when I noticed
that many fixes don't seem to be run, and mistakenly thought that it
was because of the file-name check.  Later I found the bug with
redirection.  So I guess the file-name comparison disabling can go
away with little or no lossage.

Of course, if you remove it, the following line in Makefile.DOS:

	export FIXINCL_TEST=y ; export TARGET_MACHINE=* ; \

should instead say this:

	export TARGET_MACHINE="*" ; \

(note the quotes around `*' which I failed to include in my patch).

> Also, the file:
> 
>   "fixinc/tests/msdos/testing.exp"
> 
> should be identical to the file "fixinc/tests/base/testing.h",
> or I would like to know why they should be different.

The diffs against fixinc/tests/base/testing.h are below.  Do you think
I should debug this?


--- ./fixinc/tests/base/testing.h	Wed Jul 19 17:18:30 2000
+++ ./include.dos/testing.h	Mon Aug  7 20:40:58 2000
@@ -7,8 +7,6 @@
     This had to be done to correct non-standard usages in the
     original, manufacturer supplied header file.  */
 
-
-
 #if defined( CTRL_QUOTES_DEF_CHECK )
 #define _CTRL(c) (c&037)
 #endif  /* CTRL_QUOTES_DEF_CHECK */
@@ -59,8 +57,7 @@
 	*memccpy(),
 	memcpy();
 extern int
-	strncmp();
-extern unsigned int
+	strncmp(),
 	strlen(),
 	strspn();
 extern size_t
@@ -77,3 +74,8 @@
 #endif
 
 #endif  /* UNDEFINE_NULL_CHECK */
+
+
+#ifndef NULL
+#define NULL 0
+#endif