GNAT: no more exception raised on illformed text file?

[Yannick Duchêne (Hibou57)]

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?


(*) 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

[J-P. Rosen]

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.

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

[Yannick Duchêne (Hibou57)]

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 :-)

[Adam Beneschan]

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.

-- Adam

[Shark8]

On Feb 6, 1:08 am, Yannick Duchêne (Hibou57)

<yannick_duch...@yahoo.fr> wrote:
> 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.

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.)

[Adam Beneschan]

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.

-- Adam

[J-P. Rosen]

Le 06/02/2012 20:04, Shark8 a écrit :
>> 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!