The C standard specifies, for translation phase 1, that:

"Physical source file multibyte characters are mapped, in an
implementation-defined manner, to the source character set (introducing
new-line characters for end-of-line indicators) if necessary." (5.1.1.2p1).

That wording is deliberately vague about how any particular
implementation defines what an end-of-line indicator might be, to allow
the wide variety of methods that were in use at the time C was first
standardized: <https://en.m.wikipedia.org/wiki/Newline#Representation>,
many of which are still in use. Note in particular that several systems
used methods other than delimiter characters to indicate end-of-file.

I had remembered there being similar wording in the descriptions of
streams or files in the section describing <stdio.h>, indicating that
platform-specific means of indicating the end-of-line would be
translated to and from '\n' characters by the standard I/O routines -
but I've been unable to locate such wording.

Am I remembering incorrectly, or searching incorrectly?

On Wednesday, November 3, 2021 at 10:02:14 AM UTC-7, james...@alumni.caltech.edu wrote:
> The C standard specifies, for translation phase 1, that:
>
> "Physical source file multibyte characters are mapped, in an
> implementation-defined manner, to the source character set (introducing
> new-line characters for end-of-line indicators) if necessary." (5.1.1.2p1).
>
> That wording is deliberately vague about how any particular
> implementation defines what an end-of-line indicator might be, to allow
> the wide variety of methods that were in use at the time C was first
> standardized: <https://en.m.wikipedia.org/wiki/Newline#Representation>,
> many of which are still in use. Note in particular that several systems
> used methods other than delimiter characters to indicate end-of-file.
>
> I had remembered there being similar wording in the descriptions of
> streams or files in the section describing <stdio.h>, indicating that
> platform-specific means of indicating the end-of-line would be
> translated to and from '\n' characters by the standard I/O routines -
> but I've been unable to locate such wording.
>
> Am I remembering incorrectly, or searching incorrectly?

Hi. Are you an angry gay white man?

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> The C standard specifies, for translation phase 1, that:
>
> "Physical source file multibyte characters are mapped, in an
> implementation-defined manner, to the source character set (introducing
> new-line characters for end-of-line indicators) if necessary." (5.1.1.2p1).
>
> That wording is deliberately vague about how any particular
> implementation defines what an end-of-line indicator might be, to allow
> the wide variety of methods that were in use at the time C was first
> standardized: <https://en.m.wikipedia.org/wiki/Newline#Representation>,
> many of which are still in use. Note in particular that several systems
> used methods other than delimiter characters to indicate end-of-file.
>
> I had remembered there being similar wording in the descriptions of
> streams or files in the section describing <stdio.h>, indicating that
> platform-specific means of indicating the end-of-line would be
> translated to and from '\n' characters by the standard I/O routines -
> but I've been unable to locate such wording.
>
> Am I remembering incorrectly, or searching incorrectly?

N1570 7.21.2p2:

A text stream is an ordered sequence of characters composed into
*lines*, each line consisting of zero or more characters plus a
terminating new-line character. Whether the last line requires a
terminating new-line character is implementation-defined. Characters
may have to be added, altered, or deleted on input and output to
conform to differing conventions for representing text in the host
environment. Thus, there need not be a one-to-one correspondence
between the characters in a stream and those in the external
representation. Data read in from a text stream will necessarily
compare equal to the data that were earlier written out to that
stream only if: the data consist only of printing characters and the
control characters horizontal tab and new-line; no new-line
character is immediately preceded by space characters; and the last
character is a new-line character. Whether space characters that
are written out immediately before a new-line character appear when
read in is implementation-defined.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

On 11/3/21 1:56 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> The C standard specifies, for translation phase 1, that:
>>
>> "Physical source file multibyte characters are mapped, in an
>> implementation-defined manner, to the source character set (introducing
>> new-line characters for end-of-line indicators) if necessary." (5.1.1.2p1).
>>
>> That wording is deliberately vague about how any particular
>> implementation defines what an end-of-line indicator might be, to allow
>> the wide variety of methods that were in use at the time C was first
>> standardized: <https://en.m.wikipedia.org/wiki/Newline#Representation>,
>> many of which are still in use. Note in particular that several systems
>> used methods other than delimiter characters to indicate end-of-file.
>>
>> I had remembered there being similar wording in the descriptions of
>> streams or files in the section describing <stdio.h>, indicating that
>> platform-specific means of indicating the end-of-line would be
>> translated to and from '\n' characters by the standard I/O routines -
>> but I've been unable to locate such wording.
>>
>> Am I remembering incorrectly, or searching incorrectly?
>
> N1570 7.21.2p2:
....
> ... Characters
> may have to be added, altered, or deleted on input and output to
> conform to differing conventions for representing text in the host
> environment. Thus, there need not be a one-to-one correspondence
> between the characters in a stream and those in the external
> representation. ...

I missed that because I was looking for something using the terms
"new-line" or "end-of-line indicator". "new-line" is used both
immediately before and immediately after that sentence, but not in that
sentence itself, which is the one I was looking for.
I don't think that the implications for end-of-line indicators that
aren't new-lines is quite as clear as it is in 5.1.1.2p1.

In article <slufa8$q7o$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:

> Am I remembering incorrectly, or searching incorrectly?

The end of line is at least twelve zero bits at the bottom of a
sixty bit word.

--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
Discordia: not just a religion but also a parody. This post / \
I am an Andrea Doria sockpuppet. insults Islam. Mohammed

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 11/3/21 1:56 PM, Keith Thompson wrote:
> > James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> >> The C standard specifies, for translation phase 1, that:
> >>
> >> "Physical source file multibyte characters are mapped, in an
> >> implementation-defined manner, to the source character set (introducing
> >> new-line characters for end-of-line indicators) if necessary." (5.1.1.2p1).
> >>
> >> That wording is deliberately vague about how any particular
> >> implementation defines what an end-of-line indicator might be, to allow
> >> the wide variety of methods that were in use at the time C was first
> >> standardized: <https://en.m.wikipedia.org/wiki/Newline#Representation>,
> >> many of which are still in use. Note in particular that several systems
> >> used methods other than delimiter characters to indicate end-of-file.
> >>
> >> I had remembered there being similar wording in the descriptions of
> >> streams or files in the section describing <stdio.h>, indicating that
> >> platform-specific means of indicating the end-of-line would be
> >> translated to and from '\n' characters by the standard I/O routines -
> >> but I've been unable to locate such wording.
> >>
> >> Am I remembering incorrectly, or searching incorrectly?
> >
> > N1570 7.21.2p2:
> ...
> > ... Characters
> > may have to be added, altered, or deleted on input and output to
> > conform to differing conventions for representing text in the host
> > environment. Thus, there need not be a one-to-one correspondence
> > between the characters in a stream and those in the external
> > representation. ...
>
> I missed that because I was looking for something using the terms
> "new-line" or "end-of-line indicator". "new-line" is used both
> immediately before and immediately after that sentence, but not in that
> sentence itself, which is the one I was looking for.
> I don't think that the implications for end-of-line indicators that
> aren't new-lines is quite as clear as it is in 5.1.1.2p1.

For me it is clear that standard allows "text" files consisting
of space padded fixed length records, where trailing space
stripped on reading. Talking about end-of-line indicators
would leave suggestion that such files are disallowed.
Putting it differently: the text above seem to be more permissive,
hence there are less constraints then alternative text
that would make demands for end-of-line indicators.

--
Waldek Hebisch