To:	Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: v 1.11 "bugs" to fix in 1.12
Date:	Sun, 17 Jul 94 09:41:07 +0300
From:	eliz AT is DOT elta DOT co DOT il

>    For example, in the current implementation of "always fail" stubs
> for pipe(), fork(), etc, the program links fine, the stub fails wwhen
> the program is run, certain programs then report a non-DJGPP errno,
> attempt to index past the end of the array of error messages, and
> GPF in _doprt with an illegal access error.  Took me a couple of days
> to figure out what was happening.

This is what I do to avoid such "bugs":

	1. NEVER *EVER* believe a successfull compile/link.
	2. Keep a list of ``suspicious'' features which need work when
porting to DJGPP (and DOS in general).  This list includes the ``always-fail''
functions like fork() and pipe(), functions which need their call parameters
to be changed (e.g. open() might need O_BINARY), and other features whose use
under DOS might mean trouble (e.g., using st_ino from stat() or fstat()).
After I have a clean compile, I run fgrep(1) on all the sources to hunt for the
suspicious features, then read the source near locations found by fgrep and fix
whatever needs fixing.  Btw, this list is quite large, and keeps growing with
each port... (If anybody is interested, I can mail it.)

Some time ago I proposed revising fork(), so that it would allow minimal changes
to the source to work under DOS, assuming fork()/exec() should do spawn(); but
somebody on the list said it wasn't wise, because this would interfere with the
different environments run by various DJGPP'ers out there.

	Eli Zaretskii

- Raw text -