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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

> 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