Mail Archives: djgpp/1998/06/30/03:16:59
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.
- Raw text -