Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!bingvaxu!leah!itsgw!steinmetz!uunet!sdrc!scjones
From: scjones@sdrc.UUCP (Larry Jones)
Newsgroups: comp.lang.c
Subject: Re: Say what!?  (Re: MSC 5.0 Bug Fix?? (Simple..))
Message-ID: <225@sdrc.UUCP>
Date: 21 Feb 88 15:34:09 GMT
References: <11739@brl-adm.ARPA> <1988Feb17.171813.15472@utzoo.uucp> <2183@ttrdc.UUCP>
Organization: Structural Dynamics Research Corp., Cincinnati
Lines: 39

In article <2183@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes:
> In article <1988Feb17.171813.15472@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
[ every line in a file must end with '\n', including the last line]
> Ahem, what does X3J11 have to say about source files on systems (like VMess)
> that support "record" text files?  There need be no new line character in them,
> but each record ("line") in the file is defined by some other mechanism,
> e.g., a byte count prepended to each record.  (Of course the answer should be
> that such source files are treated for the purpose of the standard as if they
> ended with a newline character, but is this actually an explicit part of the
> standard?  And if not, shouldn't it be?  And for that matter, what if, in
> the middle of a record in such a file, an actual newline character is found?
> How is the compiler supposed to treat that??)

X3J11 says nothing about how to >implement< the standard; that's up to each
individual implementor.  If your system happens to match the model used by
the standard (like Unix and MS-DOS), then the implementation is easy.  If not
(like VMS and MVS), then you have to do more work.  Certainly the most common
solution is to translate record endings into newlines but this is not always
the right solution (e.g. files with fortran carriage control).  Some OSs
provide enough information to do this right (VMS), others don't.  Some
implementations allow the user to specify the right interpretation, others
don't.  Embedded newlines are a headache.

In any case, the model specified by the standard was carefully chosen so as
to be compatible with existing practice (the Unix model) while avoiding things
which are very hard to get right on some systems.  How do you represent a line
that doesn't end with a newline on a system with record files where record
end is taken as a newline?  How do you represent a zero length line in a
record file when zero length records are invalid?  How do you represent an
empty file when empty files are deleted when closed to avoid "wasting" disk
and directory space?  How do you represent variable length lines in a fixed
length record file?  These are the reasons for the various restrictions in
the standard's file model.

----
Larry Jones                         UUCP: uunet!sdrc!scjones
SDRC                                MAIL: 2000 Eastman Dr., Milford, OH  45150
                                    AT&T: (513) 576-2070
"When all else fails, read the directions."