Path: utzoo!utgpu!water!watmath!clyde!att-cb!ihnp4!inuxc!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Newsgroups: comp.lang.c
Subject: Re: Say what!?  (Re: MSC 5.0 Bug Fix?? (Simple..))
Message-ID: <2187@bsu-cs.UUCP>
Date: 22 Feb 88 12:08:29 GMT
References: <11739@brl-adm.ARPA> <1988Feb17.171813.15472@utzoo.uucp> <2183@ttrdc.UUCP> <225@sdrc.UUCP>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 42

[ every line in a file must end with '\n', including the last line]

For files read and written from a Pascal program, the sequence-of-
characters-terminated-by-a-newline model has existed for some time.  No
doubt OS implementors have already solved the problem, if they were
going to solve it at all, to conform to ISO Pascal.

The VAX/VMS C manual describes the painful translation that goes on
so that the VMS C runtime system can convert between the newline model
and the internal record structure.  Since the compiler is just a
program, the same translation can be done when it reads a source file.

Newlines embedded in records are easy to deal with:  They simply
terminate a line, so the record will appear as two lines.  Any other
behavior contradicts the term "newline".

Under VMS, if you use the EDT editor, an invisible ^M character appears
to be at the end of each line.  You can force EDT to insert an embedded
carriage return by asking it to insert an arbitrary character by ASCII
code, and then typing 13.  But when you manipulate text (e.g. move text
from one place to another in the file), EDT translates the embedded
carriage return into a record terminator and the result is that you get
two lines and the embedded carriage return is gone.  (Disclaimer:  this
was so when I last checked.  VMS evolves rapidly so your version may
behave differently.)

OS implementors, use record files if you must, but please also allow
the user to create unstructured, newline-terminated files.  Else you
and your users are going to suffer as more and more programming
languages, to be portable, specify this type of file behavior.  You can
fight it just to be different, or you can gracefully give in and
support a universal text format.

Did you all know that DEC *is* giving in?  Its stream-LF format files
not only behave like UNIX-style newline-terminated text text files, but
are also freely executable without any protest from the operating
system.  DEC's C compiler is even more forgiving:  it will happily
compile C source files that are in stream-LF format *and* have a
spurious carriage return character at the end of each line of text.
IBM, as always, will take a little longer.
-- 
Rahul Dhesi         UUCP:  <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi