Date: Tue, 30 Jun 1998 10:15:33 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: stdenis <stdenis AT compmore DOT net>
cc: Nate Eldredge <nate AT cartsys DOT com>, djgpp AT delorie DOT com
Subject: Re: portable code
In-Reply-To: <3597D1C7.FEC6F0CB@compmore.net>
Message-ID: <Pine.SUN.3.91.980630101509.6274G-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Mon, 29 Jun 1998, stdenis wrote:

> > 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?

Something like that.  But it is far from being easy, since you usually
don't want to rewrite large parts of the C library just to avoid using
existing but non-ANSI functions.

> >         - 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?

There are all kinds of problems.  On Unix, when you read in a file,
the number of bytes you've read exactly matches the file size as
reported by `stat' or `findfirst'.  There are programs which test the
value returned by `read' against the file size to check whether the
file was read successfully.  This breaks on DOS/Windows.

Another problem is that some programs cannot use the usual text mode
of reading the file whereby CRs are stripped.  For example, a program
that prints a hex dump of a file needs to use binary I/O.  When you
have a program which needs binary I/O, but needs also to find the end
of each line, you have trouble on DOS/Windows whereas on Unix this is
easy.

The above are actual examples from real-life programs, and it is only
the tip of an iceberg, believe me.  Making all these cases work on
different platforms is a pain.

> 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?

The problem begins when a program needs to take a file name apart, or
otherwise parse it.  For example, how do you know whether a given file
name is an absolute or relative?  How do you find the directory part
of a file name, if it has one?  How do you tell whether two file names
belong to the same filesystem?  All those questions need
system-specific code to work right on all platforms.  For example, the
usual naive code in many Unix programs will decide that "d:/foo/bar"
is a relative file name, and that "c:\\foo\\bar" has no explicit
directory.

> See if the compiler is truly ANSI C there would not be this problem.

I think this is naively untrue.  I hope that the above gives you some
idea why.