Date: Tue, 8 Aug 2000 09:30:27 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Bruce Korb cc: djgpp-workers AT delorie DOT com Subject: Re: DJGPP patch for fixincludes In-Reply-To: <398ED65F.52CF62FA@sco.com> Message-ID: 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