Date: Thu, 10 Feb 2000 13:10:37 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: "Campbell, Rolf [SKY:1U32:EXCH]" 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Precedence: bulk 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.