NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/sys/atari/st/tech/6875

Internet Message Format | 1993-01-27 | 3.5 KB

Path: sparky!uunet!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!ira.uka.de!rz.uni-karlsruhe.de!fg70.rz.uni-karlsruhe.de!ig25
From: [e-mail] (Thomas Koenig)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Porting UNIX Code to the ST
Date: 26 Jan 93 20:01:54 GMT
Organization: University of Karlsruhe, Germany
Lines: 61
Message-ID: <ig25.728078514@fg70>
References: <[e-mail]> <[e-mail]>
NNTP-Posting-Host: fg70.rz.uni-karlsruhe.de

[e-mail] (Martin P. Ibert) writes:

>Oh sure. You're right of course. There ARE those nasty "typed" file systems
>that are EVEN WORSE than what we are squabbling about here. I remember
>hacking away at a VMS system trying to find the mode to open a file that
>yields exactly as many bytes as the stat(2) emulation says the file has.
>I didn't found one, and I guess it simply can't be done. So maybe we should
>consider ourselves lucky, after all :-)

It is not going to take much longer until you will indeed be able to.
After all, VMS is going to get a POSIX.1 compliant application interface,
so that stat thing better get fixed or else DEC will have quite a number
of irate customers on their hands ;-)

But then again, even IBM announced POSIX compliance for MVS, and hat
file system is nothing short of a nightmare... that'll be a sight.
End-of-line character, what a strange concept ;-)

>So let's rephrase. The problem is indeed not that UNIX doesn't have a typed
>file system while TOS has; this is rubbish. The problem is really with the
>C language, whose idea of a text file differs from TOS' idea of a text file.
>So in fact, the problem is neither TOS' nor UNIX' problem, but C's problem.

True.

Unfortunately, with POSIX.1 and ANSI-C being the only reasonable
standards for writing both portable and useful programs above a certain
level, you're stuck.

>In C source code, you'll find lots of I/O function calls that explicitly
>or implicitly write or expect a single '\n' as a line delimiter. This is
>not really part of the language proper (which is totally oblivious to
>I/O anyway) but of run-time libraries and/or common usage. This usage
>coincides (not incidentially) with the way text files are usually handled
>on UNIX systems.

You have to distinguish between internal and external representation
here.  If you open a file in text mode in C, using fopen(), the \n
character has to be translated to whatever the operating system thinks
is a line delimiter; it might even be the physical end of a record.
For BINARY files, things are different.  I'd be tempted to call any
program broken which writes out a \n to a binary stream and expects it
to be treated as line delimiters by anything that follows (at least
broken WRT to the ANSI Standard).

>Okay. So if you write/compile/whatever C programs that produce "text" files
>with '\n' delimited lines, TOS couldn't care less. Those files are perfectly
>legal TOS files. But they violate common TOS usage and are thus no legal
>text files in a TOS environment. So your program has to be considered
>malfunctioning, just like a program that writes files containing ISO-8859/1
>coded 8bit letters.

In a way, that's correct.  However, with frequent porting of compressed
files, it might be argued that for reading text files, at least, enough
common usage exists that both \n and \r\n should be recognized when
reading from a text stream.  After all, it can't be that hard to
implement in the stdio library.
--
Thomas Koenig, [e-mail], [e-mail]
The joy of engineering is to find a straight line on a double
logarithmic diagram.