Message-ID:	<3597D1C7.FEC6F0CB@compmore.net>
Date:	Mon, 29 Jun 1998 13:41:27 -0400
From:	stdenis <stdenis AT compmore DOT net>
MIME-Version:	1.0
To:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
CC:	Nate Eldredge <nate AT cartsys DOT com>, djgpp AT delorie DOT com
Subject:	Re: portable code
References:	<Pine DOT SUN DOT 3 DOT 91 DOT 980629165523 DOT 3196F-100000 AT is>

> The concerns which Nate was expressing still apply.  You cannot write a
> useful, non-toy program with only ANSI C functionality.  You *must* use
> library functions and OS features which are outside ANSI.  Even Posix is
> not always enough to write any given program.

So... write the actual guts (algorithm) in ANSI C, and interface changes between
systems?

>         - text vs. binary I/O
>         - file name format (multiple root directories, drive letters etc.)
>         - the way subsidiary programs are invoked

Well that is what ANSI C is for.  in ANSI C all text has only a LF at then end.
DOS has a CR/LF but the lib must ignore the CR to be compatible.  Where's the
problem there?  Um file name format?  A file name is a filename.  It depends on
what you are expecting, however you just pass a string and open a file, so what?

See if the compiler is truly ANSI C there would not be this problem.  However ANSI
C only covers the basics.  (Memory routines, formatted input output, block input
output, math routines and such), however the 'neat' features like interrupts and OS
calls are not part of ANSI C and if a compiler claims them as ANSI C, then that's a
shame.

tom

- Raw text -