Pete Becker wrote:
> Erik Wikstr   m wrote:
> >
> > I've read somewhere that the reason for requiring a newline at the end
> > of the file is to make sure that no unpleasant surprises comes up when
> > including files.
> >
> > Example:
> >
> > #include "foo.h"
> > #include "bar.h"
> >
> > if the last line of foo.h is a one-line comment but does not end in a
> > newline that would mean that after the pre-processing the second line in
> > the example (#include "bar.h") would be a part of that comment (or would
> > it be the first line of bar.h, can't remember how the pre-processing
> > works). Is this correct?
> >
>
> Nope. The rule comes from C, which doesn't have one-line comments. Seems
> to me that i heard it's about peculiar file systems which can't tell
> where a text file ends unless its last line has a newline.
>
> --
>
>  -- Pete

C preprocessor lines.

And HP's compiler (11.11 PA-RISC ansic and aCC both) would seem to be
at least one real-world example that chokes on an unterminated #endif,
which MS VS 2003 and 2005 (for a real-world editor example) gladly
leave the newlines off with the default settings.

Several compilers exist that will warn, but not fail, on encountering
files with a final character that is not a newline...

--
Nathan


---
[ 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                      ]

Pete Becker wrote:
> Erik Wikstr   m wrote:

> > I've read somewhere that the reason for requiring a newline
> > at the end of the file is to make sure that no unpleasant
> > surprises comes up when including files.

> > Example:

> > #include "foo.h"
> > #include "bar.h"

> > if the last line of foo.h is a one-line comment but does not
> > end in a newline that would mean that after the
> > pre-processing the second line in the example (#include
> > "bar.h") would be a part of that comment (or would it be the
> > first line of bar.h, can't remember how the pre-processing
> > works). Is this correct?

> Nope. The rule comes from C, which doesn't have one-line
> comments. Seems to me that i heard it's about peculiar file
> systems which can't tell where a text file ends unless its
> last line has a newline.

It certainly had something to do with strange file systems, but
I'm not sure any longer what:-).  In practice, in the file
systems I know of today that don't treat text files as a simple
stream of bytes, with a strict end of file which can be anywhere
(and is always recognizable), don't allow writing text except as
lines (or records), so it is impossible to write a text file
that doesn't end in a '\n'.  (Obviously, when copying data from
Unix or Windows to such a system, some sort of translation will
occur, especially since such systems often still use EBCDIC, or
some sort of exotic code on 9 bit characters. And I wouldn't
exclude the possibility that the translation looses all
characters after the final newline in the file.  But that's not
a C++ issue.)

There's also the question of what to do if the file ends with an
escaped newline.  Presumably, that isn't the result of a bad
editor, but something the author meant to do.  Making it
undefined behavior means that the committee members don't have
to worry about defining what happens in such useless cases.  Any
proposal to have the compiler implicitly insert a new line at
the end of a file if one is missing would have to address this
issue.

--
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                      ]

James Kanze wrote:
> Kaba wrote:
> > > ISO 14882 international C++ standard says:
>
> > > 2.1/2:  ... 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 backslash, the behaviour is
> > > undefined.
>
> > I've always been irritated by the requirement that a file must
> > end in a new-line. It just comes to me automatically to leave
> > the last row without an new-line.
>
> What kind of program editor do you use?  I can't imagine a
> program editor not ending a file it writes with a new line.
> (For whatever historical reasons, we view programs as a sequence
> of lines, e.g. the error messages from the compiler give a line
> number.  Given this, it would seem logical that any program
> editor be line based, or at least give the impression of being
> so when editing code.)
>
[snip]

> In practice, I cannot see a system where it is possible to
> generate a text file which doesn't end in a newline (it's not
> possible on most systems---Windows and Unix are exceptions in
> this regard), where it is not reasonably easy to read the
> trailing data and detect the error.  So in practice, I would
> expect an error message from the compiler.  I would still favor
> keeping the requirement, however, since copying such files to
> another system could easily result in the last line missing.
>
[snip]

We seem to come from different worlds, James.... all the Visual Studio
editors, I've used allow me to not put an empty line at the bottom and
so does e.g. notepad. Why on earth would a text-editor submit a blank
line in the end of a random text? Unless the editor was made especially
for editing of c/C++ files I can't see a reason (but there are reasons
not to).

/Peter

---
[ 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                      ]

> (I'm not familiar enough with Visual Studios to know how to
> configure its editor, but it would seem very strange that it
> cannot automatically generate boiler plate, nor automatically
> ensure that the file ends with a new line.  I've never actually
> seen an editor which doesn't have the latter possibility.)

Maybe strange, but that's the way it is:)

> > In effect, pretend that the newline was there before the end-of-file
> > marker.
>
> And what happens if the last character in the file is a '\'?  Or
> if the system isn't capable of returning data from a text file
> if the data doesn't end with a '\n'?  (I suppose that for the
> first, you could say that the compiler should process all files
> as if they had two additional trailing new lines, and I doubt
> that the second is really relevant today.)

Happens the same as if there were a newline in the first place. That
rule should answer any such problem.

Ok, I've got an example of a system that would not work right: take an
imaginary system that stores files as "rows". A row is a sequence of
symbols, with the "newline" being a special symbol, which ends the row.
There is also another special symbol, the "escape" symbol, that allows
to use both the special symbols without special meaning.

Further imagine the system stores the end-of-line information by storing
the filesizes as counts of these rows, not as counts of symbols. It also
places the responsibility of ending the last line with newline on the
user. Every file that is stored in that system must be stored with that
convention. In particular, the wise creators of the system state that
they are able to store C++ files space-efficiently by interleaving the
file data and their internal file system data. They report space savings
of at least 1 byte per file:)

This example demonstrates the facts that:
* If the existence of the newline matters, then it must be because it is
an essential part of the end-of-file coding.

Right, maybe no-one creates filesystems like that, but maybe if we think
about blocks of memory that contain C++ source code ("files"). Then we'd
have pointers to those memory blocks and stored the filesize as
described above. This reminds me of how the shader programs work in the
current graphics hardware. They are effectively stored and transmmited
to the gpu just in this manner (and coincidently, they are based on a C-
style language).

--
Kalle Rutanen
http://kaba.hilvi.org

---
[ 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                      ]

James Kanze wrote:

> In practice, I cannot see a system where it is possible to
> generate a text file which doesn't end in a newline (it's not
> possible on most systems---Windows and Unix are exceptions in
> this regard),

;-) "Exceptions"...? What percentage of the world wide installed computers
are NOT one of these...?

And it IS possible on most system. E.g. I'm using emacs on every system, and
I can of course generate my files without newline at the end. But the
default in the c++-Mode of emacs is to append a newline automatically. And
I think, it should be default on all programming editors. OTOH a editor
should save what I have typed, and not what the editor likes better. So if
I omit the newline, it may ask, if I'm sure, but it should not modify my
files without notice.

>> especially by those that are starting on C++.  And, I can't
>> imagine any compiler not doing the right thing in this
>> situation anyway.
>
> You mean, emit a warning or an error?

I'm responsible for a build system here at our company, and I would like it
to be an error, because otherwise you can't get some programmers to add a
newline, so I always have to deal with those annoying newline-warnings
myself.

> With the difference that this problem is related (and more or
> less imposed) by external issues, and is normally handled by the
> editor.  (I wanted to see what g++ did in such cases---I
> couldn't generate such a file with the editors I had at hand,
> and had to write a C++ program to generate the code.)

g++ generates a warning by default but with -Werror or -pedantic-errors it
generates an error.

But so far, in this thread I have not found any good reason for this rule,
except convenience. The only reason I can think of would be source, that is
piped into a compiler through a buffered named pipe, that may block if no
eof is found. But are there any real reason? The file system mentioned seem
a little outdated as a reason for me.

Regards
Stephan

---
[ 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                      ]

Greg Herlihy wrote:
> Kaba wrote:
> > > ISO 14882 international C++ standard says:

> > > 2.1/2:  ... 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 backslash, the behaviour
> > > is undefined.

> > I've always been irritated by the requirement that a file
> > must end in a new-line. It just comes to me automatically to
> > leave the last row without an new-line. Minor inconvenience,
> > yet irritating. I wonder if this requirement could be
> > removed?

> The C++ Standard's closing new-line requirement is a ludicrous
> anachronism.

Only if you've never really thought about the problem.

> The very notion that an implementation capable of parsing -
> what probably has to be the most complex and ambiguous grammar
> of any mainstream computing language - is nonetheless also an
> implementation that is apt to go haywire at the first
> "missing" linefeed it runs into, is simply preposterous on the
> face of it.

You don't seem to be aware of it, but most implementations run
under an OS, and are subject to the constraints of that OS.

> Frankly the continued inclusion of this teletype-era
> requirement is an embarrassment.  The proper resolution would
> simply have the implementation supply a "virtual" line feed at
> the end of any header file that is "missing" one.

Which still leaves you up in the air if the file ends with a
'\'.

--
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                      ]

peter koch wrote:
> James Kanze wrote:
> > Kaba wrote:
> > > > ISO 14882 international C++ standard says:

> > > > 2.1/2:  ... 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 backslash, the behaviour is
> > > > undefined.

> > > I've always been irritated by the requirement that a file must
> > > end in a new-line. It just comes to me automatically to leave
> > > the last row without an new-line.

> > What kind of program editor do you use?  I can't imagine a
> > program editor not ending a file it writes with a new line.
> > (For whatever historical reasons, we view programs as a sequence
> > of lines, e.g. the error messages from the compiler give a line
> > number.  Given this, it would seem logical that any program
> > editor be line based, or at least give the impression of being
> > so when editing code.)

> [snip]

> > In practice, I cannot see a system where it is possible to
> > generate a text file which doesn't end in a newline (it's not
> > possible on most systems---Windows and Unix are exceptions in
> > this regard), where it is not reasonably easy to read the
> > trailing data and detect the error.  So in practice, I would
> > expect an error message from the compiler.  I would still favor
> > keeping the requirement, however, since copying such files to
> > another system could easily result in the last line missing.

> [snip]

> We seem to come from different worlds, James.... all the
> Visual Studio editors, I've used allow me to not put an empty
> line at the bottom and so does e.g. notepad. Why on earth
> would a text-editor submit a blank line in the end of a random
> text?

Because text isn't random.  In the case of a C++ program (and in
a lot of other cases as well), it is a sequence of lines (which
are formed from a sequence of words/tokes, which are formed from
a sequence of letters).  A work processor (like Word) doesn't
treat it as such, and breaks lines according to its whim when
displaying and printing, but C++ programs are normally treated
as a sequence of lines, in which YOU have inserted the breaks.

Given this, it's up to the text editor to save the file as a
sequence of lines.  Under Windows, the "definition" of a "line"
in the file system is a sequence of characters ending in a CRLF,
so each line in the editor ends up being written this way.

At least that is the way I understand it (but my understanding
may be influenced by Unix).  Another possible definition could
be that a line is a sequence of characters, with multiple lines
being separated by a CRLF.  (The classical separator vs.
terminator distinction.)  If this is the case, it is impossible
to write a text file which doesn't end with a new-line, so the
problem doesn't exist (unless you intentionally create a file
with a \ as the last character).

> Unless the editor was made especially for editing of c/C++
> files I can't see a reason (but there are reasons not to).

Well, when I edit C++, I use an editor made (or at least
configured) for C++.  I've gotten used to things like automatic
indentation, syntax highlighting, and the rest.  And the Visual
Studios editor certainly handles all of this well; it's
knowledge of C++ is generally better than that of the editors I
normally use.  (I find the general Windows environment a bit
Mickey Mouse, with a lot of showy gimicks, but little useful
features.  On the other hand, the individual programs within the
environment, such as the compiler, are often better than many of
their Unix counterparts.  The editor has at least some features
which are better than those in the editors I know well, and if I
could only get it to run on my machine, a Sun Sparc under
Solaris, I'd give it a serious try.)

--
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                      ]

Kaba wrote:
> > (I'm not familiar enough with Visual Studios to know how to
> > configure its editor, but it would seem very strange that it
> > cannot automatically generate boiler plate, nor
> > automatically ensure that the file ends with a new line.
> > I've never actually seen an editor which doesn't have the
> > latter possibility.)

> Maybe strange, but that's the way it is:)

The fact that it cannot automatically generate boiler plate
pretty much makes it unusable for production code, no?  You
certainly don't want to count on developers typing in the
copyright by hand each time, nor the SCCS (or whatever you're
using) control strings.

I'll admit that from what little I've seen of the Visual
Studio's interface, I'd categorize it as a toy.  BUT... I'm not
at all familiar with it.  Apparently, people are using it in
real developments, so I presume that it has possibilities I
don't know about.  And to tell the truth, I was pretty sure that
automatic generation of boiler-plate text was one of them, since
I've never heard of a project where this wasn't required.  And
the system is known for its "Wizards", which automatically
generate things (or at least, that's what I think I've heard.)
I've also read or heard somewhere that source code control
systems can be integrated---maybe that's how they do it: by
asking the source code control system for the file, and having
it generate the boiler plate.

Anyway, my answer to your problem would be to change editors. Or
learn how to do such fundamental things with the editor you've
got.

> > > In effect, pretend that the newline was there before the
> > > end-of-file marker.

> > And what happens if the last character in the file is a '\'?
> > Or if the system isn't capable of returning data from a text
> > file if the data doesn't end with a '\n'?  (I suppose that
> > for the first, you could say that the compiler should
> > process all files as if they had two additional trailing new
> > lines, and I doubt that the second is really relevant
> > today.)

> Happens the same as if there were a newline in the first
> place.  That rule should answer any such problem.

Undefined behaviour, then?

The current rule is that unless a file ends with an unescaped
new line, it is undefined behavior.  You are proposing to change
that, so what is the new rule?  (One possiblity would be that
when reading a file, the compiler automatically appends two
newline characters to the end of it, no matter what.)

Anyway, if you think it important, write up a proposal.  I don't
think that the "impossible on some systems" argument really
holds much weight today, and changing undefined behavior into
defined behavior should break much working code.

--
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                      ]

Stephan Kuhagen wrote:
> James Kanze wrote:

> > In practice, I cannot see a system where it is possible to
> > generate a text file which doesn't end in a newline (it's not
> > possible on most systems---Windows and Unix are exceptions in
> > this regard),

> ;-) "Exceptions"...? What percentage of the world wide
> installed computers are NOT one of these...?

Probably somewhere around 90%---most of the computers in my home
or my car do NOT run either Windows nor Unix.

But that's not the issue.  Windows and Unix are, roughly
speaking, two operatings systems (although there are at least
two code bases for Windows, and God knows how many incompatible
variants of Unix).  Globally, there have been hundreds, if not
thousands, of different OS's.  Most haven't had quite the
commercial success of Windows, or even of Unix, but they do
exist (or have existed).

> And it IS possible on most system. E.g. I'm using emacs on
> every system, and I can of course generate my files without
> newline at the end.

On an IBM mainframe?  The last time I looked there, emacs wasn't
available.  And text files were stored as variable length
records, with no new-line characters anywhere.  The compiler,
and just about every other program you can think of, treated the
end of each record as a line-end.  And since you can't write
data outside a record, and every record has an end...

>From what I've seen outside the Unix/Windows world, this would
seem to be the usual situation.  It's impossible to write a text
file that has a "partial" line.

> But the default in the c++-Mode of emacs is to append a
> newline automatically. And I think, it should be default on
> all programming editors. OTOH a editor should save what I have
> typed, and not what the editor likes better.  So if I omit the
> newline, it may ask, if I'm sure, but it should not modify my
> files without notice.

The question is what you are editing.  If the text is a sequence
of lines (and a lot of text is), then the editor should output
it as a sequence of lines.  Whatever that means to the operating
system.  Under Windows, I do NOT type a CRLF, for example.  For
that matter, under Unix, I don't type a control-J, either.  In
both cases, I use the Enter key to tell the editor that I want
the following text to be on a new line.  In no case do I
explicitly enter a new-line character (or whatever its
representation is on the system I'm working on); I tell the
editor that this text is part of a different line than the
preceding, and it does whatever is necessary.  The text is a
sequence of lines, which is what the editor should store.  And
by definition, when a C++ compiler reads it, it appends a
new-line character to the end of each line.

When it comes down to it, perhaps the problem is that Microsoft
hasn't made clear the definition of a sequence of lines in a
text file, and that different groups at Microsoft disagree as to
whether the CRLF is a terminator (and thus must be at the end of
every file which is a sequence of lines, and it is the
responsibility of whoever is writing the file to put it there),
or a separator (in which case, its presence at the end of a text
file means that the file ends with an empty line).

Note that this has consequences for the C++ runtime as well;
when reading a file in text mode, every line ends in a '\n', and
it is the responsibility of the library to do whatever is
necessary for this to be the case.  In particular, IF the
definition for Windows is that CRLF is a separator, and not a
terminator, partial lines aren't possible, and the library must
automatically add a '\n' after it has read the last character in
the file, in addition to converting the CRLF sequence to '\n'.

> >> especially by those that are starting on C++.  And, I can't
> >> imagine any compiler not doing the right thing in this
> >> situation anyway.

> > You mean, emit a warning or an error?

> I'm responsible for a build system here at our company, and I
> would like it to be an error, because otherwise you can't get
> some programmers to add a newline, so I always have to deal
> with those annoying newline-warnings myself.

> > With the difference that this problem is related (and more or
> > less imposed) by external issues, and is normally handled by the
> > editor.  (I wanted to see what g++ did in such cases---I
> > couldn't generate such a file with the editors I had at hand,
> > and had to write a C++ program to generate the code.)

> g++ generates a warning by default but with -Werror or
> -pedantic-errors it generates an error.

But of course, g++ comes from the Unix world, and applies the
Unix definition, where LF is a terminator (and not a separator).

> But so far, in this thread I have not found any good reason
> for this rule, except convenience.  The only reason I can
> think of would be source, that is piped into a compiler
> through a buffered named pipe, that may block if no eof is
> found. But are there any real reason? The file system
> mentioned seem a little outdated as a reason for me.

I think so to.  Another reason may have to do with the extra
work involved in defining what happens when the last character
is an escaped new-line.  Today, there are only two cases: a
non-escaped new-line, and undefined behavior.

A third reason why it doesn't change is inertia.  Whatever the
original reasons, they have been lost in time, but it works, so
no one bothers to change it.

In the meantime, it might not be a bad idea if Microsoft got the
guys who write the editor and the guys who write the compiler
together, to agree on their definition of a line.  Since I find
it hard to imagine that they consider the editor in Visual
Studios a word processor or such, and not a program editor,
which is line oriented.

--
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                      ]

> The fact that it cannot automatically generate boiler plate
> pretty much makes it unusable for production code, no?  You

I haven't looked into that possibility, that would be most convenient.

> I'll admit that from what little I've seen of the Visual
> Studio's interface, I'd categorize it as a toy.  BUT... I'm not

Hehe:) All in all, I really like the VS editor, and I haven't missed any
feature to be added. That may be because of lack of experience. And
since VS 2003, I have encountered a very few bugs in the compiler.

> Anyway, my answer to your problem would be to change editors. Or
> learn how to do such fundamental things with the editor you've
> got.

Oh, the former would surely be a too strong reaction for such a minor
defect:) For the time being, I just have to bite the bullet and add the
newlines.

> > Happens the same as if there were a newline in the first
> > place.  That rule should answer any such problem.
>
> Undefined behaviour, then?
>
> The current rule is that unless a file ends with an unescaped
> new line, it is undefined behavior.  You are proposing to change
> that, so what is the new rule?  (One possiblity would be that
> when reading a file, the compiler automatically appends two
> newline characters to the end of it, no matter what.)

Your rule would be an adequate one, but I think the more minimal rule
suffices:
"If there is no newline at the end of the file, the compiler must work
as if there was one."

That way the situation is brought back to the currently legal situation.
If there is a \, it does not matter. It still should work as if the
compiler would work if there was a newline.

> Anyway, if you think it important, write up a proposal.  I don't
> think that the "impossible on some systems" argument really
> holds much weight today, and changing undefined behavior into
> defined behavior should break much working code.

Well, why not, but unfortunately I don't have an access to the standard.
However I'd like to have one someday, that would be the most thrilling
bed-time reading:) Any idea where about the prices are moving?

--
Kalle Rutanen
http://kaba.hilvi.org

---
[ 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                      ]

Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
news:1158678909.784291.287380@i42g2000cwa.googlegroups.com...

> When it comes down to it, perhaps the problem is that Microsoft
> hasn't made clear the definition of a sequence of lines in a
> text file, and that different groups at Microsoft disagree as to
> whether the CRLF is a terminator (and thus must be at the end of
> every file which is a sequence of lines, and it is the
> responsibility of whoever is writing the file to put it there),
> or a separator (in which case, its presence at the end of a text
> file means that the file ends with an empty line).
>

The system GUI EDIT control sees it as a separator and all self-respecting
editors follow this convention.  A properly terminated file is displayed
with a spurious empty line at the bottom.  You can see it when the text is
longer than the window is high and you scroll to the bottom.  The shell TYPE
command does the same.  It is annoying and people tend to delete that line.
I am not surprised.
However, another question is what happens when you send such a file to a
line printer.  The printing head would probably stop somewhere in the middle
of the line.  And when you concatenate such files A and B using system
command COPY/A A+B AB, the first line of file B will be appended to the last
line of file A.  This effect is rather unexpected but both scenarios are
extremely rare these days.

> Note that this has consequences for the C++ runtime as well;
> when reading a file in text mode, every line ends in a '\n', and
> it is the responsibility of the library to do whatever is
> necessary for this to be the case.  In particular, IF the
> definition for Windows is that CRLF is a separator, and not a
> terminator, partial lines aren't possible, and the library must
> automatically add a '\n' after it has read the last character in
> the file, in addition to converting the CRLF sequence to '\n'.

It does not.  In addition, it interprets ^Z as end of file and refuses to
read anything more unless you reposition the reading head by seeking (which
is possible on regular files).

Chris


---
[ 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                      ]

kanze wrote:

>> ;-) "Exceptions"...? What percentage of the world wide
>> installed computers are NOT one of these...?
>
> Probably somewhere around 90%---most of the computers in my home
> or my car do NOT run either Windows nor Unix.

True, that was ignorant of me. But aren't embedded systems are mostly
programmed in plain old C (or more and more with an embedded Java-VM)?
Anyway... The computers running Windows or some kind of Unix may not be the
biggest quota of all computers, but I'm pretty sure, they are the most
used, when it comes to programming. I think, programming an embedded system
does normally take place on Windows or Unix and not by starting your
VisualStudio directly on your washing machine...

>> And it IS possible on most system. E.g. I'm using emacs on
>> every system, and I can of course generate my files without
>> newline at the end.
>
> On an IBM mainframe?

Another ignorance by me, sorry. I should have written "I'm using emacs on
every system, _I'm_ programming on."

>> found. But are there any real reason? The file system
>> mentioned seem a little outdated as a reason for me.
>
> I think so to.  Another reason may have to do with the extra
> work involved in defining what happens when the last character
> is an escaped new-line.  Today, there are only two cases: a
> non-escaped new-line, and undefined behavior.
>
> A third reason why it doesn't change is inertia.  Whatever the
> original reasons, they have been lost in time, but it works, so
> no one bothers to change it.

But it seems to me, that also nobody bothers to use it strictly as a rule:
if it has no newline at the end, it is not a valid source file. Even GCC,
which tries to be as ISO-conform as possible, does not make it an error by
default.

I played a little with GCC trying to create some includes and other things
without newlines at the end, with "\" a last character (trying to trick the
preprocessor) and so on, but I was not able to produce any code, that
really failed. The only exception is "\" as last char in a non-comment-line
and omitting the newline. But that is wrong code anyway. So my question is:
does anyone know a "working" real example on a widely used system, where
the missing newline leads to erroneous code when compiled? - I really love
the newline at the end, but just for convenience. And I think, a standard
should not have rules, that are ignored by everyone, because nobody can
create an example, where the rule shows its necessity... Either it is a
usefull rule, then there should be a real reason for it, or it is not, then
it should not be there. This is like having sequences of "nop" (NoOps, I
did 68k-Assembler in my early years...) in a high level language...

Regards
Stephan

---
[ 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                      ]

kanze wrote:
> Greg Herlihy wrote:
> > Kaba wrote:
> > > > ISO 14882 international C++ standard says:
>
> > > > 2.1/2:  ... 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 backslash, the behaviour
> > > > is undefined.
>
> > > I've always been irritated by the requirement that a file
> > > must end in a new-line. It just comes to me automatically to
> > > leave the last row without an new-line. Minor inconvenience,
> > > yet irritating. I wonder if this requirement could be
> > > removed?
>
> > The C++ Standard's closing new-line requirement is a ludicrous
> > anachronism.
>
> Only if you've never really thought about the problem.

Only if there were a problem - or at least a problem that was not
entirely of the Standard's own making. In fact what exactly is the
problem? Why must a source file end in a new line? Is it to keep the
contents of included files separate? No, because a new line already
keeps them apart. For example, it's not possible to include two files
on the same line:

     #include "a.h" #include "b.h"

Instead, in order to include both a.h and b.h the Standard requires a
new-line character after each:

    #include "a.h"
    #include "b.h"

thereby ensuring their separation. Now one might think that with a
new-line character already keeping each included file a respectable
distance away from any other, that that would be the last word on this
issue.

Well...this matter would indeed have been laid to rest, were it not for
the fact that the included file's contents replaces both the include
directive and its trailing new-line character. Yes, that is correct,
the new-line character is thrown away. So as it turns out, the reason
that the included file has to end with a new-line character is to
replace an identical character that had no good reason for having been
thrown away in the first place. The real problem is not a "missing"
new-line character, the problem is simply that part of the Standard is
undoing the effects of its own mistake made in another part.

Furthermore, the fact that a missing new-line character leads to
"undefined behavior" does nothing to diminish the perception that C++
has a tendency to conjure up "undefined" behavior at the first
opportunity - and manages to do so seemingly out of thin air. Why, for
example, isn't the behavior of a C compiler when it encounters a
missing new-line character, also undefined? Why can't a C++ compiler be
expected to detect the same error that a C compiler must?

> > The very notion that an implementation capable of parsing -
> > what probably has to be the most complex and ambiguous grammar
> > of any mainstream computing language - is nonetheless also an
> > implementation that is apt to go haywire at the first
> > "missing" linefeed it runs into, is simply preposterous on the
> > face of it.
>
> You don't seem to be aware of it, but most implementations run
> under an OS, and are subject to the constraints of that OS.

The ending new-line requirement is a case of the opposite: the C++
Standard is imposing a constraint of its own on the implementation.
There would never be a need to accomodate an OS constraint because any
such constraint could be easily overcome simply by having the
implementation not count the final new-line character (and therefore
require two new-line characters to count as one "logical" new-line
character when both appear as the last two characters in a file).
Furthermore, the Standard is quite clear that "source files" do not
need to be implemented as files at all. A source file can be
implemented by any means whatsoever - they are not even contrained to a
one-to-one mapping with the program's concept of its source files.

So as the Standard's own, pure invention, the ending new-line
requirement should therefore exist for benefit of the implementation.
But that is clearly not the case. It exists soley to the detriment of
the implementation. Its only effect is to create a risk of undefined
behavior and do so in the most improbable of circumstances (while
parsing) and for the most picayune of infractions - an
(easily-detectable) missing new-line character at the end of a file. An
artificial requirement with such a disproportionate penalty -
"ludicrous" it is.

Greg

---
[ 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                      ]

Greg Herlihy wrote:
.
> The ending new-line requirement is a case of the opposite: the C++
> Standard is imposing a constraint of its own on the implementation.

The new-line requirement constrains developers. It frees up
implementations to handle the issue any way they want to.

> So as the Standard's own, pure invention, the ending new-line
> requirement should therefore exist for benefit of the implementation.
> But that is clearly not the case. It exists soley to the detriment of
> the implementation.

Could you specify the nature of the detriment to the implementation?

> Its only effect is to create a risk of undefined
> behavior and do so in the most improbable of circumstances (while
> parsing) and for the most picayune of infractions - an
> (easily-detectable) missing new-line character at the end of a file. An
> artificial requirement with such a disproportionate penalty -
> "ludicrous" it is.

That's a serious problem for developers; but since the implementation
is free to define behavior in any way that's convenient for them, I
don't see how it's a detriment to the implementor.

---
[ 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                      ]

Greg Herlihy wrote:
> Why, for
> example, isn't the behavior of a C compiler when it encounters a
> missing new-line character, also undefined?

5.1.1.2, paragraph 2:
"A source file that is not empty shall end in a new-line character ..."

Looks like it is.


--
Paul

---
[ 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                      ]

kuyper@wizard.net wrote:
> Greg Herlihy wrote:
> .
> > The ending new-line requirement is a case of the opposite: the C++
> > Standard is imposing a constraint of its own on the implementation.
>
> The new-line requirement constrains developers. It frees up
> implementations to handle the issue any way they want to.
>
> > So as the Standard's own, pure invention, the ending new-line
> > requirement should therefore exist for benefit of the implementation.
> > But that is clearly not the case. It exists soley to the detriment of
> > the implementation.
>
> Could you specify the nature of the detriment to the implementation?

.by not serving the interests of the implementation's clients - that
is, programmers. There would be no C++ implementations without C++
programmers. Their interests are mutual.

A C++ programmer cannot afford to be careless when it comes to new-line
characters, since the consequences of not having one at the end of a
file have been left open. The C programmer on the other hand has no
such concern - the only outcome of missing a line feed is a
compile-time error.

The fact that a C++ compiler is held to a lower standard than a C
compiler - and for such an unchallenging task to begin with - is a
telling indicator of just how much confidence the authors of this
Standard must have in the accuracy and quality of a typical C++
compiler. At any rate, the lesson is to always compile a C source file
with a C compiler. There is nothing to be gained by assuming
unnecessary risks.

 In practi
> > Its only effect is to create a risk of undefined
> > behavior and do so in the most improbable of circumstances (while
> > parsing) and for the most picayune of infractions - an
> > (easily-detectable) missing new-line character at the end of a file. An
> > artificial requirement with such a disproportionate penalty -
> > "ludicrous" it is.
>
> That's a serious problem for developers; but since the implementation
> is free to define behavior in any way that's convenient for them, I
> don't see how it's a detriment to the implementor.

A problem for developers is a problem for implementors as well. An
implementation needs to be used to justify its existence, and C++
developers are its clients. In this case, some of the implementor's
customers may switch to a competing implementation which does detect
the error reliably. Whereas the original implementor relied on the
Standard in order to know what would be important to implement. And in
this case, the Standard misled and misled badly.

The Standard is essentially countenancing the fact that thousands of
lines of perfectly correct, ideally optimized C++ code can be undone by
just one missng character at the end of the file. In other words, the
presence of this one, new-line character is more important than the
correct translation of any C++ program. So I would imagine that it's
very difficult for implementors to articulate the reasons behind the
Standard's odd fixation with a closing new line character. It is
probably no easier to explain how the paramount importance the Standard
attachs to the one character's presence, really does outweigh the
importance of compiling the client's programs faithfully and
accurately.

I think that there is a good chance that a client in this situation
would become fed up with this nonsense and decide that the C++ Standard
simply has badly-misplaced priorities. And this client would then be
likely to consider writing code in a diffierent programming language -
one with a slightly more modern, and more programmer-friendly
perspective. And losing a C++ programmer harms all C++ implementors.

Greg

---
[ 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                      ]

Paul Black wrote:
> Greg Herlihy wrote:
> > Why, for
> > example, isn't the behavior of a C compiler when it encounters a
> > missing new-line character, also undefined?
>
> 5.1.1.2, paragraph 2:
> "A source file that is not empty shall end in a new-line character ..."
>
> Looks like it is.

5.1.1.2 of the C Standard clearly defines a missing new line character
at the end of a file as an error. And an error in C requires only a
diagnostic.

What matters in 5.1.1.2 is what it does not say. The C Standard does
not grant a license for undefined behavior and unlike the corresponding
clause in the C++ Standard. And that one point is the salient
difference to note here.

Greg

---
[ 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                      ]

Greg Herlihy wrote:
> Paul Black wrote:
>> Greg Herlihy wrote:
>>> Why, for
>>> example, isn't the behavior of a C compiler when it encounters a
>>> missing new-line character, also undefined?
>> 5.1.1.2, paragraph 2:
>> "A source file that is not empty shall end in a new-line character ..."
>>
>> Looks like it is.
>
> 5.1.1.2 of the C Standard clearly defines a missing new line character
> at the end of a file as an error. And an error in C requires only a
> diagnostic.
>

ISO/IEC 9899:1999, 4/2 says that requirements appearing outside of
constraints (as this one does) result in undefined behavior.

--

 -- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

---
[ 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                      ]

Greg Herlihy wrote:
> Paul Black wrote:
> > Greg Herlihy wrote:
> > > Why, for
> > > example, isn't the behavior of a C compiler when it encounters a
> > > missing new-line character, also undefined?
> >
> > 5.1.1.2, paragraph 2:
> > "A source file that is not empty shall end in a new-line character ..."
> >
> > Looks like it is.
>
> 5.1.1.2 of the C Standard clearly defines a missing new line character
> at the end of a file as an error. And an error in C requires only a
> diagnostic.

No, when a "shall" occurs outside of a constraint, it's one of three
different ways specified in 4p2 for identifying undefined behavior.

The C standard requires a diagnostic when a program contains a
constraint violation, a syntax error, an assert() that fails, a #error
directive that survives conditional compilation, or if a hexadecimal
constant cannot be represented exactly in its evaluation format. There
are no other mandatory diagnostics.

---
[ 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                      ]

Greg Herlihy wrote:
.
> .by not serving the interests of the implementation's clients - that
> is, programmers. There would be no C++ implementations without C++
> programmers. Their interests are mutual.

No. They do have mutual interests, but they also have conflicing
interests. Implementors want a language that's easy to implement,
developers want a language that's easy to program in; those are
generally conflicting needs. In this case, the primary impact is
entirely on developers; there is no direct impact on implementors,
because this rule imposes no requirements on them. And since the impact
on developers is quite negligible (many aren't even aware of the
requirment, having never used an editor that was capable of generating
such a file, or having never used a compiler where it would cause a
problem). Therefore, the indirect effect on implementors due to the
direct effect on developers is vanishingly small.

> A C++ programmer cannot afford to be careless when it comes to new-line
> characters, since the consequences of not having one at the end of a
> file have been left open. The C programmer on the other hand has no
> such concern - the only outcome of missing a line feed is a
> compile-time error.

As has already been pointed out in several other messages, it's
undefined behavior in both languages, with no diagnostic required in
either one.

If a diagnostic were required, that would impose a burden (albeit a
very minor one) on implementors.

> The fact that a C++ compiler is held to a lower standard than a C
> compiler - and for such an unchallenging task to begin with - is a
> telling indicator of just how much confidence the authors of this
> Standard must have in the accuracy and quality of a typical C++
> compiler. At any rate, the lesson is to always compile a C source file
> with a C compiler. There is nothing to be gained by assuming
> unnecessary risks.

Since you've mistaken the difference between the two languages on this
issue, that whole line of argument falls to pieces.

In reality, the fact that this is undefined behavior in C++ is an
inheritance from C, and it's undefined behavior in C mainly for
historical reasons. I gather that there were actual implementations of
pre-standard C which would fail, for reasons that made a lot of sense
on their particular platforms, if the file didn't end with a new-line
character. I don't remember the details; so I can't tell you why it
made sense on those platforms - I've been hoping that someone who did
remember would speak up. Making the behavior undefined in C was done to
allow those compilers to be conforming implementations.

.
> A problem for developers is a problem for implementors as well.

Not in general. Most problems affect one of the two groups differently,
and it's not at all uncommon for a problem for developers to be a boon
for implementors, or vice versa. The standard is essentially a contract
between developers and implementors; the parts that constrain
implementations make things more difficult for implementors, and easier
for developers. The parts that constrain programs make things easier
for implementors and harder for developers. This falls in the latter
category, though the impact, even on developers, is so tiny it's hardly
worth discussing.

---
[ 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                      ]

In article <eeqi30$3m6$1@kohl.informatik.uni-bremen.de>, Stephan Kuhagen
<nospam@domain.tld> writes
>> A third reason why it doesn't change is inertia.  Whatever the
>> original reasons, they have been lost in time, but it works, so
>> no one bothers to change it.
>
>But it seems to me, that also nobody bothers to use it strictly as a rule:
>if it has no newline at the end, it is not a valid source file. Even GCC,
>which tries to be as ISO-conform as possible, does not make it an error by
>default.


On most platforms with most programming tools it will not matter if the
programmer does not explicitly terminate a source file with a newline.
However there certainly have been systems where it did matter (because
without it if the file is #included in another file the last line
(without the newline character) will be concatenated with the line
following the #include directive.

As usual the Standard makes such non-portable behaviour (a source file
without terminating newline) undefined. That allows all systems where it
does not matter to do the 'right thing' whilst ensuring that systems
that do anything else are not excluded.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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                      ]

Stephan Kuhagen wrote:
> kanze wrote:

    [...]
> > A third reason why it doesn't change is inertia.  Whatever the
> > original reasons, they have been lost in time, but it works, so
> > no one bothers to change it.

> But it seems to me, that also nobody bothers to use it
> strictly as a rule: if it has no newline at the end, it is not
> a valid source file.

It's undefined behavior, so by definition, every compiler is
conforming to it, since regardless of what the compiler does, it
is conformant:-).

> Even GCC, which tries to be as ISO-conform as possible, does
> not make it an error by default.

Undefined behavior.  Maybe they should reformat the hard disk if
they discover the case.  (Once upon a time, in the distant past,
g++ did fork off into a game of nethack, or something similar,
in one particular case of undefined behavior:-).)

> I played a little with GCC trying to create some includes and
> other things without newlines at the end, with "\" a last
> character (trying to trick the preprocessor) and so on, but I
> was not able to produce any code, that really failed. The only
> exception is "\" as last char in a non-comment-line and
> omitting the newline. But that is wrong code anyway. So my
> question is: does anyone know a "working" real example on a
> widely used system, where the missing newline leads to
> erroneous code when compiled? - I really love the newline at
> the end, but just for convenience. And I think, a standard
> should not have rules, that are ignored by everyone, because
> nobody can create an example, where the rule shows its
> necessity... Either it is a usefull rule, then there should be
> a real reason for it, or it is not, then it should not be
> there.

I've been thinking about this particular meta-issue a bit
lately, myself; there are a couple of places where the standard
specifies undefined behavior, but that work everywhere in
practice.  In this particular case, it really doesn't matter:
what constitutes the end of a line is implementation defined
anyways, and if Microsoft's editors allow, and even encourage,
files in which the last line is not terminated by a CRLF (and
treat it as a line), then the compiler should do so as well.
(It's interesting to note that the compiler does treat a single
LF, without the CR, as a correct end of line, even though some
other Microsoft tools don't.)

But I agree that the standard would be improved by bringing it
more in line with existing practice.  Here and elsewhere.

--
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                      ]

"Kristof Zelechovski" wrote:
> Uzytkownik "kanze" <kanze@gabi-soft.fr> napisal w wiadomosci
> news:1158678909.784291.287380@i42g2000cwa.googlegroups.com...

> > When it comes down to it, perhaps the problem is that
> > Microsoft hasn't made clear the definition of a sequence of
> > lines in a text file, and that different groups at Microsoft
> > disagree as to whether the CRLF is a terminator (and thus
> > must be at the end of every file which is a sequence of
> > lines, and it is the responsibility of whoever is writing
> > the file to put it there), or a separator (in which case,
> > its presence at the end of a text file means that the file
> > ends with an empty line).

> The system GUI EDIT control sees it as a separator and all
> self-respecting editors follow this convention.  A properly
> terminated file is displayed with a spurious empty line at the
> bottom.  You can see it when the text is longer than the
> window is high and you scroll to the bottom.  The shell TYPE
> command does the same.  It is annoying and people tend to
> delete that line.  I am not surprised.

This was sort of my suspicion, too.  I remember the effet with
TYPE under MS-DOS.

> However, another question is what happens when you send such a
> file to a line printer.  The printing head would probably stop
> somewhere in the middle of the line.  And when you concatenate
> such files A and B using system command COPY/A A+B AB, the
> first line of file B will be appended to the last line of file
> A.  This effect is rather unexpected but both scenarios are
> extremely rare these days.

So Microsoft isn't coherent itself.  That's probably the real
problem here.

> > Note that this has consequences for the C++ runtime as well;
> > when reading a file in text mode, every line ends in a '\n', and
> > it is the responsibility of the library to do whatever is
> > necessary for this to be the case.  In particular, IF the
> > definition for Windows is that CRLF is a separator, and not a
> > terminator, partial lines aren't possible, and the library must
> > automatically add a '\n' after it has read the last character in
> > the file, in addition to converting the CRLF sequence to '\n'.

> It does not.

So the runtime library of C++ takes the position that the CRLF
is a terminator, and not a separator.

> In addition, it interprets ^Z as end of file and
> refuses to read anything more unless you reposition the
> reading head by seeking (which is possible on regular files).

That's no problem.  It's backwards compatible with CP/M.  (Under
CP/M, file length could only be a multiple of 128 bytes.  So you
needed an EOF character for the case where the text ended in the
middle of a 128 byte block.  CP/M and others like it are also
the reason why the system may append extra null bytes to the end
of a binary file---without the text file's EOF indicator, you
couldn't get an EOF at an arbitrary file position.)

--
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                      ]

<kuyper@wizard.net> wrote in message
news:1158808138.483973.162250@i42g2000cwa.googlegroups.com...

> ...
> In reality, the fact that this is undefined behavior in C++ is an
> inheritance from C, and it's undefined behavior in C mainly for
> historical reasons. I gather that there were actual implementations of
> pre-standard C which would fail, for reasons that made a lot of sense
> on their particular platforms, if the file didn't end with a new-line
> character. I don't remember the details; so I can't tell you why it
> made sense on those platforms - I've been hoping that someone who did
> remember would speak up. Making the behavior undefined in C was done to
> allow those compilers to be conforming implementations.

IIRC, I'm the guy who pushed for the rule that every source file
must end in a newline. The main reason was simply to recycle the
carefully worked out rules for defining text files within the C
runtime library. It was easier to define a bunch of compile-time
concepts by using that model.

The C text-file model disallows partial last lines because it is
intended to be the lowest common denominator for representing
text across operating systems. And there are some file formats
that won't let you express a partial last line. If you can't
read back exactly what you wrote, you're asking for trouble, so
we omitted partial last lines from standard text files, and
hence by adoption from compiler source files.

But there's another, better reason for disallowing partial last
lines in source files. There was a strong consensus within X3J11,
possibly unanimity, that many of the structures visible to the
preprocessor must nest within the boundaries of source files.
In particular, no preprocessing directive should cross file
boundaries. By outlawing straddling comments, line continuation
at the end of a file, and partial last lines, we simplified
both the implementer's job and that of future code reviewers.

>> A problem for developers is a problem for implementors as well.
>
> Not in general. Most problems affect one of the two groups differently,
> and it's not at all uncommon for a problem for developers to be a boon
> for implementors, or vice versa. The standard is essentially a contract
> between developers and implementors;

I'm also the guy who first advanced that worldview.

>                                      the parts that constrain
> implementations make things more difficult for implementors, and easier
> for developers. The parts that constrain programs make things easier
> for implementors and harder for developers.

Not always.

>                                             This falls in the latter
> category, though the impact, even on developers, is so tiny it's hardly
> worth discussing.

I don't agree that this makes life harder for developers, except
possibly for the crowd who likes to write code and say, "Betcha
can't tell what *this* does!". For every clown who finds a
clever use for line pasting across files, you'll find a dozen
future reviewers who have to puzzle out what the hell is going
on. (Clowns delight in omitting comments.) And if you allow this
practice, you'll also find a hundred puzzled programmers who stay
up half the night debugging when they inadvertently use this
"feature". The newline at the end of the last source file in the
translation unit is IMO no more onerous than the closing brace on
main. Get over it.

I see this as one of many examples of a decision that benefits
both implementers and programmers. Not everything in a treaty is
a tradeoff.


P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ 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                      ]

"P.J. Plauger" wrote:

>   The newline at the end of the last source file in the
> translation unit is IMO no more onerous than the closing brace on
> main. Get over it.

Yes, but the lack thereof is certainly less visible, and all compilers
omits a diagnostic in the case of the latter (not so for the prior).

Regards,

Werner

---
[ 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                      ]

"P.J. Plauger" wrote:
> <kuyper@wizard.net> wrote in message
> news:1158808138.483973.162250@i42g2000cwa.googlegroups.com...

    [...]
> But there's another, better reason for disallowing partial last
> lines in source files. There was a strong consensus within X3J11,
> possibly unanimity, that many of the structures visible to the
> preprocessor must nest within the boundaries of source files.
> In particular, no preprocessing directive should cross file
> boundaries. By outlawing straddling comments, line continuation
> at the end of a file, and partial last lines, we simplified
> both the implementer's job and that of future code reviewers.

This is, of course, what I was trying to get at when I pointed
out that if you don't want to require ending a file with a
new-line, you have to define exactly what it means.

I don't think that most of the people wanting to force the
new-line have considered all of these issues, but I rather
suspect that they would be happy with a rule along the lines of
"the preprocessor behaves as if all files are in fact terminated
by a non-escaped new-line", whether they are or not.

I'm tempted to say: if this makes them happy, why not?  On the
other hand, I'm not sure about the implications about
portability; I've already mentionned possible problems when
copying such a file to another system, and your explination just
increases my worry.  (Unlike some of the participants here, I've
very aware that there are other systems than Windows and Unix.
And that there are doubtlessly systems even stranger than any
I've worked on.)  I'm also pretty convinced from the discussion
that the real problem is that different groups in Microsoft
don't agree on the definition of a line.  I don't like the idea
of modifying the standard just because of one company's internal
communication problems.

    [...]
> I don't agree that this makes life harder for developers, except
> possibly for the crowd who likes to write code and say, "Betcha
> can't tell what *this* does!". For every clown who finds a
> clever use for line pasting across files, you'll find a dozen
> future reviewers who have to puzzle out what the hell is going
> on. (Clowns delight in omitting comments.) And if you allow this
> practice, you'll also find a hundred puzzled programmers who stay
> up half the night debugging when they inadvertently use this
> "feature". The newline at the end of the last source file in the
> translation unit is IMO no more onerous than the closing brace on
> main. Get over it.

I agree, but my impression is that the current argument is more
along the lines of omitting the final return from main.  They
don't want to allow all sorts of tricky code.  They simply want
to be able to omit the final new-line, and for the compiler to
act as if it were there, much as they omit the final return 0 in
main, and the compiler acts like it was there.  (Horrible
precedant, that.  IMHO, of course.)

> I see this as one of many examples of a decision that benefits
> both implementers and programmers. Not everything in a treaty
> is a tradeoff.

I agree, but I don't think anyone is proposing that we support a
line continuation accross the end of the file.

Personally, I'm happy with the status quo, but I could easily
live with a rule that said that the compiler treats each file as
if it ended with a non-escaped new-line, even if it doesn't.  As
you point out, the only people who would ever want any other
behavior are those who like to write code and say, "Betcha can't
tell what *this* does".

--
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                      ]

Hi!

ISO 14882 international C++ standard says:

2.1/2:  ... 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
backslash, the behaviour is undefined.

2.7 ... The characters // start a comment, which terminates with the
next new-line character.

Given those, does the following program have undefined behaviour?
(Here "#" denotes new-line and "|" marks the end of file):

 - - -

// That's all folks#
|

 - - -

In other words, does the comment consume the new-line, leaving no
new-line to signify the end of file?

Cheers!

 - Risto -

---
[ 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                      ]

Risto Lankinen wrote:
> Hi!
>
> ISO 14882 international C++ standard says:
>
> 2.1/2:  ... 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
> backslash, the behaviour is undefined.
>
> 2.7 ... The characters // start a comment, which terminates with the
> next new-line character.
>
> Given those, does the following program have undefined behaviour?
> (Here "#" denotes new-line and "|" marks the end of file):
>
>  - - -
>
> // That's all folks#
> |
>
>  - - -
>
> In other words, does the comment consume the new-line, leaving no
> new-line to signify the end of file?

No; it's legal.  The source file ended in a newline.  2.7 has no
bearing on that (except to guarantee that there can't be an
unterminated single-line comment in a source file, because there
*must* be a newline after the single-line comment begins).  The
actions and checking specified by 2.1/2 logically take place
before 2.1/3 looks for comments.

-- James

---
[ 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                      ]

> ISO 14882 international C++ standard says:
>
> 2.1/2:  ... 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
> backslash, the behaviour is undefined.

I've always been irritated by the requirement that a file must end in a
new-line. It just comes to me automatically to leave the last row
without an new-line. Minor inconvenience, yet irritating. I wonder if
this requirement could be removed? Otherwise it is very easy to produce
undefined behaviour .. especially by those that are starting on C++.
And, I can't imagine any compiler not doing the right thing in this
situation anyway. I find this problem and the template >> problem
similar in inconvenience.

--
Kalle Rutanen
http://kaba.hilvi.org

---
[ 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                      ]

On 2006-09-15 23:45, Kaba wrote:
>> ISO 14882 international C++ standard says:
>>
>> 2.1/2:  ... 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
>> backslash, the behaviour is undefined.
>
> I've always been irritated by the requirement that a file must end in a
> new-line. It just comes to me automatically to leave the last row
> without an new-line. Minor inconvenience, yet irritating. I wonder if
> this requirement could be removed? Otherwise it is very easy to produce
> undefined behaviour .. especially by those that are starting on C++.
> And, I can't imagine any compiler not doing the right thing in this
> situation anyway. I find this problem and the template >> problem
> similar in inconvenience.

I've read somewhere that the reason for requiring a newline at the end
of the file is to make sure that no unpleasant surprises comes up when
including files.

Example:

#include "foo.h"
#include "bar.h"

if the last line of foo.h is a one-line comment but does not end in a
newline that would mean that after the pre-processing the second line in
the example (#include "bar.h") would be a part of that comment (or would
it be the first line of bar.h, can't remember how the pre-processing
works). Is this correct?

If so, would it be a good solution to make the pre-processor insert a
newline-character after the contents of the file while using #include? I
can not see any negative effects with this solution.

--
Erik Wikstr   m

---
[ 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                      ]

Kaba wrote:
> > ISO 14882 international C++ standard says:

> > 2.1/2:  ... 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 backslash, the behaviour is
> > undefined.

> I've always been irritated by the requirement that a file must
> end in a new-line. It just comes to me automatically to leave
> the last row without an new-line.

What kind of program editor do you use?  I can't imagine a
program editor not ending a file it writes with a new line.
(For whatever historical reasons, we view programs as a sequence
of lines, e.g. the error messages from the compiler give a line
number.  Given this, it would seem logical that any program
editor be line based, or at least give the impression of being
so when editing code.)

> Minor inconvenience, yet irritating. I wonder if this
> requirement could be removed?

I think it has to do with the way a compiler reads lines.
Depending on how it is done, it may not see the final,
non-terminated line.

In practice, I cannot see a system where it is possible to
generate a text file which doesn't end in a newline (it's not
possible on most systems---Windows and Unix are exceptions in
this regard), where it is not reasonably easy to read the
trailing data and detect the error.  So in practice, I would
expect an error message from the compiler.  I would still favor
keeping the requirement, however, since copying such files to
another system could easily result in the last line missing.

> Otherwise it is very easy to produce undefined behaviour ..

Agreed.  It should require a diagnostic.  (Of course, the best
solution is to change the editor, if it's generating such
files:-).  But the standard doesn't say anything about the
editors we can use.)

> especially by those that are starting on C++.  And, I can't
> imagine any compiler not doing the right thing in this
> situation anyway.

You mean, emit a warning or an error?

> I find this problem and the template >> problem similar in
> inconvenience.

With the difference that this problem is related (and more or
less imposed) by external issues, and is normally handled by the
editor.  (I wanted to see what g++ did in such cases---I
couldn't generate such a file with the editors I had at hand,
and had to write a C++ program to generate the code.)

--
James Kanze (Gabi Software)              email: kanze.james@neuf.fr
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                      ]

> If so, would it be a good solution to make the pre-processor insert a
> newline-character after the contents of the file while using #include? I
> can not see any negative effects with this solution.

And nor can I. In my opinion there is no ambiguity on what the
programmer might have intended.

--
Kalle Rutanen
http://kaba.hilvi.org

---
[ 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                      ]

Kaba wrote:
> > ISO 14882 international C++ standard says:
> >
> > 2.1/2:  ... 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
> > backslash, the behaviour is undefined.
>
> I've always been irritated by the requirement that a file must end in a
> new-line. It just comes to me automatically to leave the last row
> without an new-line. Minor inconvenience, yet irritating. I wonder if
> this requirement could be removed?

The C++ Standard's closing new-line requirement is a ludicrous
anachronism. The very notion that an implementation capable of parsing
- what probably has to be the most complex and ambiguous grammar of any
mainstream computing language - is nonetheless also an implementation
that is apt to go haywire at the first "missing" linefeed it runs into,
is simply preposterous on the face of it.

Frankly the continued inclusion of this teletype-era requirement is an
embarrassment. The proper resolution would simply have the
implementation supply a "virtual" line feed at the end of any header
file that is "missing" one.

Greg

---
[ 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                      ]

> What kind of program editor do you use?  I can't imagine a
> program editor not ending a file it writes with a new line.

Currently I use the editor in the Visual Studio 2005, but I think it has
worked the same in the previous versions also. Specifically it is the
header file boiler-plate code that keeps me leaving the end-of-line out:

First I write

#ifndef FILE_H
#define FILE_H

#endif

Then after typing #endif I instantly move to the empty row and start
adding stuff. And I _never_ remember to push the enter after the
#endif:)

> > Minor inconvenience, yet irritating. I wonder if this
> > requirement could be removed?
>
> I think it has to do with the way a compiler reads lines.
> Depending on how it is done, it may not see the final,
> non-terminated line.

Hmm.. I'd presume that the file reader would have to check for the file-
end marker anyway? For example, isn't that how getline() behaves?

> So in practice, I would expect an error message from the compiler.

You can get Visual C++ to generate an error by disabling the Microsoft
specific language extensions.

> > especially by those that are starting on C++.  And, I can't
> > imagine any compiler not doing the right thing in this
> > situation anyway.
>
> You mean, emit a warning or an error?

In effect, pretend that the newline was there before the end-of-file
marker.

--
Kalle Rutanen
http://kaba.hilvi.org

---
[ 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                      ]

Erik Wikstr   m wrote:
>
> I've read somewhere that the reason for requiring a newline at the end
> of the file is to make sure that no unpleasant surprises comes up when
> including files.
>
> Example:
>
> #include "foo.h"
> #include "bar.h"
>
> if the last line of foo.h is a one-line comment but does not end in a
> newline that would mean that after the pre-processing the second line in
> the example (#include "bar.h") would be a part of that comment (or would
> it be the first line of bar.h, can't remember how the pre-processing
> works). Is this correct?
>

Nope. The rule comes from C, which doesn't have one-line comments. Seems
to me that i heard it's about peculiar file systems which can't tell
where a text file ends unless its last line has a newline.

--

 -- Pete

Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." For more information about this book, see
www.petebecker.com/tr1book.

---
[ 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                      ]

Kaba wrote:
> > What kind of program editor do you use?  I can't imagine a
> > program editor not ending a file it writes with a new line.

> Currently I use the editor in the Visual Studio 2005, but I
> think it has worked the same in the previous versions also.
> Specifically it is the header file boiler-plate code that
> keeps me leaving the end-of-line out:

> First I write

> #ifndef FILE_H
> #define FILE_H

> #endif

> Then after typing #endif I instantly move to the empty row and
> start adding stuff. And I _never_ remember to push the enter
> after the #endif:)

Funny, my editor inserts the boiler-plate automatically for me,
any time I open an inexistant file whose name ends in .hh.
(Obviously, I have defined the endings it recognizes and what it
inserts.)  I'd be very surprised if the Visual Studio editor
doesn't offer the same possibility.

More to the point, even if I enter the text by hand, without the
trailing new line, the trailing new line is there in the
generated file.  Although C++ doesn't require it, all of my
compilers are line oriented, displaying the line number for
error messages, etc.  The editors take this into account, and
don't allow text that isn't in a line.

(I'm not familiar enough with Visual Studios to know how to
configure its editor, but it would seem very strange that it
cannot automatically generate boiler plate, nor automatically
ensure that the file ends with a new line.  I've never actually
seen an editor which doesn't have the latter possibility.)

> > > Minor inconvenience, yet irritating. I wonder if this
> > > requirement could be removed?

> > I think it has to do with the way a compiler reads lines.
> > Depending on how it is done, it may not see the final,
> > non-terminated line.

> Hmm.. I'd presume that the file reader would have to check for
> the file- end marker anyway? For example, isn't that how
> getline() behaves?

I think that the original problem was at a lower level.  I'm not
sure that it's still relevant, however.

> > So in practice, I would expect an error message from the
> > compiler.

> You can get Visual C++ to generate an error by disabling the
> Microsoft specific language extensions.

> > > especially by those that are starting on C++.  And, I can't
> > > imagine any compiler not doing the right thing in this
> > > situation anyway.

> > You mean, emit a warning or an error?

> In effect, pretend that the newline was there before the end-of-file
> marker.

And what happens if the last character in the file is a '\'?  Or
if the system isn't capable of returning data from a text file
if the data doesn't end with a '\n'?  (I suppose that for the
first, you could say that the compiler should process all files
as if they had two additional trailing new lines, and I doubt
that the second is really relevant today.)

--
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                      ]