Seems my FSF GNAT (*) does not raise an exception anymore when
encountering the last line of a malformed text file; that is, a text file
whose last line is not terminated with an end‑of‑line.
Is this on purpose?
(*) GNAT 4.7.0 20111119 (experimental)
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
Le 06/02/2012 08:08, Yannick Duchêne (Hibou57) a écrit :
> Hi all,
> Seems my FSF GNAT (*) does not raise an exception anymore when
> encountering the last line of a malformed text file; that is, a text
> file whose last line is not terminated with an end‑of‑line.
> Is this on purpose?
I don't know, but it is definitely acceptable, and many would view this
as an improvement.
Ada says nothing about how an end_of_file_mark (and siblings) is
represented in the physical file. Considering that the end of the
physical file acts as an end_of_line_mark followed by an
end_of_page_mark followed by and end_of_file_mark is actually quite user
friendly: currently, all my programs that read files do not check the
end of file, but catch end_error, precisely because it works better on
ill formed files.
Le Mon, 06 Feb 2012 16:33:32 +0100, J-P. Rosen <ro...@adalog.fr> a écrit:
> I don't know, but it is definitely acceptable, and many would view this
> as an improvement.
> Ada says nothing about how an end_of_file_mark (and siblings) is
> represented in the physical file.
Okay. I just wanted to know, in the context of some tiny tips I am writing
about Ada in a forum.
Will just tell this may occur, with an emphasis on the “may”.
Thanks for your reply :-)
-- “Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University
On Feb 6, 7:33 am, "J-P. Rosen" <ro...@adalog.fr> wrote:
> Le 06/02/2012 08:08, Yannick Duchêne (Hibou57) a écrit :
> > Hi all,
> > Seems my FSF GNAT (*) does not raise an exception anymore when
> > encountering the last line of a malformed text file; that is, a text
> > file whose last line is not terminated with an end-of-line.
> > Is this on purpose?
> I don't know, but it is definitely acceptable, and many would view this
> as an improvement.
Right--in fact, we've had issues where a customer created a file with
Notepad and didn't hit RETURN at the end of the last line, and then
asked why a program wasn't reading the last line of the file. This
sort of behavior can be surprising and unwelcome.
> Seems my FSF GNAT (*) does not raise an exception anymore when
> encountering the last line of a malformed text file; that is, a text file
> whose last line is not terminated with an end-of-line.
Such a file is NOT a malformed text-file; that definition is a UNIX-
ism and therefore applicable ONLY to the UNIX/LINUX world. In Windows,
for example, a user in Notepad (or wordpad, or any other editor) can
save a text-file without such a termination (as Adam points out) and
it IS a valid text-file precisely because Windows does not define a
text-file in that manner. (IIRC all that Windows needs is the ASCII
EOF character.)
> > Seems my FSF GNAT (*) does not raise an exception anymore when
> > encountering the last line of a malformed text file; that is, a text file
> > whose last line is not terminated with an end-of-line.
> Such a file is NOT a malformed text-file; that definition is a UNIX-
> ism and therefore applicable ONLY to the UNIX/LINUX world. In Windows,
> for example, a user in Notepad (or wordpad, or any other editor) can
> save a text-file without such a termination (as Adam points out) and
> it IS a valid text-file precisely because Windows does not define a
> text-file in that manner. (IIRC all that Windows needs is the ASCII
> EOF character.)
I don't even think it needs an EOF character, based on a test I just
ran; if it's stored on disk (or other storage), the file size is
enough to determine where the end of the file is. Of course that may
not apply to files input over a serial line.
Also, I'm not even sure if the "malformed" definition applies in the
Unix/Linux worlds; I'd think users would still expect things to work
"correctly" even if the line terminator is missing.
>> Seems my FSF GNAT (*) does not raise an exception anymore when
>> encountering the last line of a malformed text file; that is, a text file
>> whose last line is not terminated with an end-of-line.
> Such a file is NOT a malformed text-file; that definition is a UNIX-
> ism and therefore applicable ONLY to the UNIX/LINUX world. In Windows,
> for example, a user in Notepad (or wordpad, or any other editor) can
> save a text-file without such a termination (as Adam points out) and
> it IS a valid text-file precisely because Windows does not define a
> text-file in that manner. (IIRC all that Windows needs is the ASCII
> EOF character.)
You miss the point here. We are talking about a malformed file from the
Ada POV.
In Ada, a text is terminated by an End_Of_Line_Mark, followed by an
End_Of_Page_Mark, followed by an End_Of_File_Mark, but the standard does
not say how these marks are represented in the file.
IF an implementation chooses to represent EOL as LF, EOP as FF, and EOF
as ^Z, then any file that does not end with LF+FF+^Z is malformed. Such
an implementation is legal, but user hostile. Better implementations are
more flexible: Gnat f.e. accepts CR, LF, CR+LF and LF+CR as EOL.
Most implementations accept the physical end of file as EOF, and
generally as EOP+EOF if there is no explicit EOP.
The only thing required by the standard is that a file written by an Ada
program can be read by an Ada program (using the same compiler of
course). It is not specified that an Ada program can read a file
produced by a text editor. However, if you are a compiler vendor, you'd
better choose an implementation that accepts it, or you won't sell many
compilers!
