Hi,

Sorry, but newline and linefeed are indeed the same thing.
That's why the character coded for by dec 10 (hex 0a) is so often
abbreviated as "nl".

On the C compilation and C string issue, it is indeed the case
that *in a character string in the C program*, '\n' is an
abbreviation of this character -- ASCII dec 10 (hex 0a).  However,
this has nothing to do with how the string is stored in an
external file.  When writing to an external file, the '\n'
would be replaced by whatever the OS uses as a line separator.
When reading an external file, whatever the OS uses as a line
separator must be replaced with a '\n' (i.e., ASCII 10, hex 0a)
in the C string into which it is read.

There is an inherent lack of portability when reading into
a C program, on one OS, a so-called ascii file written out
on another OS.  The entire reason that ftp has an ascii mode
is to be able to convert the file from one OS's convention
to another.  But such differences in convention do not
apply to the representation of the string in the C program,
where '\n' must always mean ASCI dec 10, hex0a.

Thus, if an ASCI 10 winds up in a C string (e.g., by having
been passed from Fortran), then it will always start a new
line when output from C to the file system.

-P.

On Thu, 29 Nov 2001, Gary Scott wrote:

> Hi,
>
> Sorry to interrupt.  I would like to clarify that "newline" and "line
> feed" are not the same thing (I haven't been following this item so I
> hope this isn't too far out of scope).  Character 0A hex is "line
> feed".  This does not necessarily imply that following the advance to a
> new line that the "current position" is at the first character of a
> record.  That would happen according to ascii only following both a CR
> and an LF pair (I'm not sure there is an equivalent to newline in
> ASCII).  In EBCDIC, 15 hex is newline and 25 hex is line feed.
> Therefore, the standard should not refer to ACHAR(10) as "newline" but
> instead as "line feed".  I've never understood why systems don't use 1E
> hex (record separator) to separate text records as intended (other than
> to save space in text files).
>
> Van Snyder wrote:
> >
> > Thanks to Malcolm for looking in the C standard (and knowing better
> > than most of us where to look):L
> >
> > > (1) A conforming C compiler can use (practically) any control character
> > >     as "new-line" (their spelling).  Even when running in ASCII on Unix,
> > >     with all files stored as byte streams with ACHAR(10) as record
> > >     delimiters, if a compiler decided that it liked to use ACHAR(3) as
> > >     new-line, that would conform.
> >
> > I suspected this was true.
> >
> > > (2) Whatever choice the C compiler decided to use itself as "new-line"
> > >     makes no necessary difference to the files stored.  (This follows
> > >     from point 1).
> >
> > Also as I suspected.
> >
> > > Anyway, virtually all C programs that do such "naughty things" are
> > > already assuming that '\n'==10.
> > >
> > > Which brings me to my last point:
> > > (3) A C compiler that does something other than ACHAR(10) for '\n' does
> > >     not provide anything other than portability problems for its users.
> >
> > I do not see how one gets from (1) + (2) to (3) (except by arithmetic).
> > The problem isn't that \n might be different from ACHAR(10), but that
> > users assumed \n==10.  What's ICHAR(ACHAR(10)) on EBCDIC?  I suspect
> > it's not 10.  So users also assumed the character set was ASCII.
> >
> > > ... my recommendation is to "require that [a parameter in
> > > ISO_FORTRAN_ENV] be ACHAR(10)", as allowing this to vary would be to
> > > invite unnecessary portability problems.
> >
> > Exactly the same kind of portability problems as assuming KIND(0d0)==8.
> >
> > Requiring it to be ACHAR(10) militates against C interoperability,
> > unless we have TWO parameters, one to cause new-line when used in
> > formatted stream output, and one that represents \n for the purpose
> > of interoperating with C functions.  But why multiply mechanisms when
> > one will do?  This will just confuse users, especially those who are
> > primarily C programmers.
> >
> > I do not want to require any particular concrete value such as
> > ACHAR(10).  I prefer something similar to Kurt's proposal:
> >
> > a) define a CHARACTER(1) symbolic constant,
> > b) define the stream I/O requirements in terms of that constant, and
> > c) in the description of the constant, require that it be \n, whatever
> >    value that has in the companion processor.
> >
> > --
> > What fraction of Americans believe   |  Van Snyder
> > Wrestling is real and NASA is fake?  |  [log in to unmask]
> > Any alleged opinions are my own and have not been approved or disapproved
> > by JPL, CalTech, NASA, Dan Goldin, George Bush, the Pope, or anybody else.
>
>
> --
>
> Gary Scott
> mailto:[log in to unmask]
>
> mailto:[log in to unmask]
> http://www.fortranlib.com
>
> Support the GNU Fortran G95 Project:  http://g95.sourceforge.net
>

--
  Peter S. Shenkin                      Schrodinger, Inc.
  VP, Software Development              120 W. 45th St.
  646 366 9555 x111 Tel                 New York, NY 10036
  646 366 9550 FAX                      [log in to unmask]
                                        http://www.schrodinger.com