Re: Get_Line problem (GNAT bug?)

[Maciej Sobczak <no.spam@no.spam.com>]

Dmitry A. Kazakov wrote:

> When End_Of_File meets a CR (Ctrl-M) it cannot know if this CR manifests
> the end of the current line or both the line end and the file end.

I understand. But then I consider the specs to be broken, see below. :-)

> The rules of thumb I suppose I and many other Ada programmers are using:
> 
> 1. Never ever use End_Of_File with text files;

This is broken. For me, End_Of_File is a concept that is completely 
orthogonal to what the file contains and how it is interpreted.
It is true that it is defined in Text_IO and therefore it might be a 
hint that actually EOF is somehow entangled with interpretation of text 
markers, but that's not what I would expect.

> 2. If you yet use End_Of_File then do it for *each* character of the file;

I don't see how it might solve this problem - End_Of_File would block 
after first <CR> anyway.

> 3. As Adam has suggested, End_Error exception is the right design;

I don't find it to be "right". For me, exception is something that is 
unexpected. An error, usually. With files, EOF happens - on average - 
almost once per file and it is something that I expect. There is nothing 
unusual in the fact that there is no more data in a file, *unless* in 
the given environment we really want to work with conceptually infinite 
data sources. But this is an exception (no pun intended) and is rather 
domain-specific, so should not be imposed by the general-purpose library.

EOF might be an error if, for example, with some known file format the 
parser expected some more data and there isn't any (like with the XML 
file which was truncated somewhere in the middle). *That* would be the 
reason to raise an exception, but then it's the business of the parser, 
not IO library. The library should not interfere with my interpretation 
of what I want to see in the file.

> 4. End_Error is not only cleaner and correct, but also more efficient.

It's not cleaner for me (see above), it is very likely correct (in the 
sense that the real solution is broken) and I don't see on what basis it 
is expected to be more efficient. :-)

-- 
Maciej Sobczak : http://www.msobczak.com/
Programming    : http://www.msobczak.com/prog/