Date:	Thu, 10 Feb 2000 13:10:37 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	"Campbell, Rolf [SKY:1U32:EXCH]" <moscoop AT americasm01 DOT nt DOT com>
cc:	djgpp AT delorie DOT com
Subject:	Re: fork() should generate warning, Was (Re: DJGPP Setup Utility in the making.)
In-Reply-To:	<38A194FF.14FEB94B@americasm01.nt.com>
Message-ID:	<Pine.SUN.3.91.1000210130721.27855G-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, 9 Feb 2000, Campbell, Rolf [SKY:1U32:EXCH] wrote:

>     That's a good point.  I wonder why there isn't a compiler warning
> for usage of 'fork' or any other UNIX functions that will always fail
> under DJGPP.

DJGPP's library is Posix-compliant.  Posix requires `fork' and `pipe'
to be present in a compliant library, but it doesn't require them to
succeed if the underlying OS doesn't support the functionality.

> I suspect it would make programs easier to port to have
> the compiler point you to a line that will not work rather than hope
> that the original program checks for error during fork and prints some
> meaningful message.

You cannot trust the compiler to find such problems when porting
programs, so it doesn't make sense to lose Posix compliance for this
reason alone. 

`fork' and `pipe' are just a tip of the iceberg: there are many subtle
incompatibilities between Unix and DOS/Windows which, if not taken
care of, will produce a broken or a buggy port.

The list of such problems is too lengthy to post in a short message,
but here's one, just to drivee a point home: Unix programs frequently 
delete an open file because the Unix filesystem actually defers the 
removal until the file is closed.  (It is very convenient, since you can 
close the file in some code that knows about the file and let rest of the 
program be clueless about the fact that some file was opened.)   Such 
code, if left in a ported program, will corrupt your FAT on plain DOS
and cause the program to abort with an error message on Windows 9X.

Another typical problem is the test for the leading slash in a file
name to see whether it is an absolute file name (this misses
backslashes and DOS/Windows style file names with drive letters).

A compiler cannot detect these cases.  To produce a good port, one
*must* examine the entire code, find any practices that would not work
on DOS/Windows, and replace them with something that will.  When you
do that, `fork' and `pipe' are the least of your problems (they can be
found by simply Grep'ping the sources for a bunch of fixed strings).

To ease the porting pains to some degree, libc.info from v2.03
introduces a new section that lists functions like `pipe' and `fork'
which either always fail or do nothing in the DJGPP implementation.

- Raw text -