Gene Bushuyev wrote:
> Most compilers do not care whether the source file ends with a new-line
> character or not, others annoyingly complain but still compile, making porting a
> lot less enjoyable. I don't see any technical reasons why that should be an
> undefined behavior. Should that anachronism be removed from the standard
> already?

No, not without other changes being required in the standard.
The issue arises when processing a series of '#include'
preprocessor directives. Without the requirement that source
files end in an unescaped newline, you could have situations
where including two such files in a row could result in token
pasting.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:200607271455.k6REtWD2040405@mailbox7.ucsd.edu...
> Gene Bushuyev wrote:
>> Most compilers do not care whether the source file ends with a new-line
>> character or not, others annoyingly complain but still compile, making
>> porting a lot less enjoyable. I don't see any technical reasons why that
>> should be an undefined behavior. Should that anachronism be removed from the
>> standard already?
>
> No, not without other changes being required in the standard.
> The issue arises when processing a series of '#include'
> preprocessor directives. Without the requirement that source
> files end in an unescaped newline, you could have situations
> where including two such files in a row could result in token
> pasting.


As to token pasting, the standard could have just said that the end of file is
replaced by one space character. Or it could have taken another position that
token pasting is allowed. Anyway, it's a simple deterministic behavior, there is
no reason to make it undefined behavior. Most compilers already deal with this
gracefully, and so should the standard.
--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Gene Bushuyev wrote:
> As to token pasting, the standard could have just said that the end of file is
> replaced by one space character. Or it could have taken another position that
> token pasting is allowed. Anyway, it's a simple deterministic behavior, there is
> no reason to make it undefined behavior. Most compilers already deal with this
> gracefully, and so should the standard.

Also, text I/O follows the conventions of the C standard,
and a C implementation may require that the last line of
a text file ends in a newline. So if the C++ standard
allowed source files to not end in a newline, it could
place itself in the odd position of allowing source files
which could not be portably read by C++ programs!

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hyman Rosen wrote:
> Gene Bushuyev wrote:
>> Most compilers do not care whether the source file ends with a
>> new-line character or not, others annoyingly complain but still
>> compile, making porting a lot less enjoyable. I don't see any
>> technical reasons why that should be an undefined behavior. Should
>> that anachronism be removed from the standard already?
>
> No, not without other changes being required in the standard.
> The issue arises when processing a series of '#include'
> preprocessor directives. Without the requirement that source
> files end in an unescaped newline, you could have situations
> where including two such files in a row could result in token
> pasting.

Does the undefined behaviour mean that the compiler could do anything
during the translation (including formatting the drive) or that the
resulting compiled code could do anything during its own execution?

--
Seungbeom Kim

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

musiphil@bawi.org (Seungbeom Kim) writes:
> Hyman Rosen wrote:
>> Gene Bushuyev wrote:
>>> Most compilers do not care whether the source file ends with a
>>> new-line character or not, others annoyingly complain but still
>>> compile, making porting a lot less enjoyable. I don't see any
>>> technical reasons why that should be an undefined behavior. Should
>>> that anachronism be removed from the standard already?
>>
>> No, not without other changes being required in the standard.
>> The issue arises when processing a series of '#include'
>> preprocessor directives. Without the requirement that source
>> files end in an unescaped newline, you could have situations
>> where including two such files in a row could result in token
>> pasting.
>
> Does the undefined behaviour mean that the compiler could do anything
> during the translation (including formatting the drive) or that the
> resulting compiled code could do anything during its own execution?

Yes, that's what "undefined behavior" always means.  More precisely,
it's behavior for whcih the standard imposes no requirements.  If a
compiler reformats your hard drive because one of your include files
doesn't end in a newline, it's not non-conforming for that reason
(though it could be non-conforming for other reasons, and it's
certainly not something I'd ever want to use).

The standard doesn't require implementations to be sane.

In this case, though, it would be reasonable IMHO for the standard to
make the behavior implementation-defined: if a source file doesn't end
in a newline, the compiler either pretends there's a newline, or it
issues a diagnostic.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
We must do something.  This is something.  Therefore, we must do this.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Keith Thompson wrote:

    [...]
> In this case, though, it would be reasonable IMHO for the
> standard to make the behavior implementation-defined: if a
> source file doesn't end in a newline, the compiler either
> pretends there's a newline, or it issues a diagnostic.

Or ignores the last line.

I think that the real problem is when this last line ends with
an \.  Can you continue the line into the including file?  Or
must there be a diagnostic?  Or...

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Hyman Rosen wrote:
> Gene Bushuyev wrote:
> > As to token pasting, the standard could have just said that
> > the end of file is replaced by one space character. Or it
> > could have taken another position that token pasting is
> > allowed. Anyway, it's a simple deterministic behavior, there
> > is no reason to make it undefined behavior. Most compilers
> > already deal with this gracefully, and so should the
> > standard.

> Also, text I/O follows the conventions of the C standard,
> and a C implementation may require that the last line of
> a text file ends in a newline. So if the C++ standard
> allowed source files to not end in a newline, it could
> place itself in the odd position of allowing source files
> which could not be portably read by C++ programs!

That was my reaction at first.  But the more I think about it...

There are really only two major alternatives to be considered:

 -- the operating system views the file as a stream of bytes;
    local conventions assign a specific byte sequence as end of
    line (and sometimes another for end of file), and

 -- the operating system views the file as a sequence of
    records, and considers each record a line---when reading in
    C, the runtime library appends the '\n' character to the end
    of each record,

In the first case, it would be trivial for the compiler and/or
the C/C++ runtime to append a '\n' character to the end of each
file, and in the second, files that don't end with a '\n' are
impossible anyway.

Of course, this leaves open the question of the last character
before the end of file being a \.  I think one place the rules
still have relevance is that they allow the preprocessor to
handle escaped end of lines at a very low level, and separately
for each file.

I also don't think the issue worth bothering about, because no
one writing an editor for a programming language would every
have the editor write out lines without the final '\n'.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

2.1/1/2 contains the following:
"If a source file that is not empty does not end in a new-line character, or
ends in a new-line character immediately preceded by a backslash character, the
behavior is undefined."

Most compilers do not care whether the source file ends with a new-line
character or not, others annoyingly complain but still compile, making porting a
lot less enjoyable. I don't see any technical reasons why that should be an
undefined behavior. Should that anachronism be removed from the standard
already?

--
Gene Bushuyev (www.gbresearch.com)
----------------------------------------------------------------
To see what is in front of one's nose needs a constant struggle ~ George Orwell

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]