Re: Get_Line problem (GNAT bug?)

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Thu, 07 Dec 2006 09:26:07 +0100, Maciej Sobczak wrote:

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

No. It is the concept, which is broken. And that wasn't Ada, who broke it,
but crippled operating systems like Windows and Unix. In a proper OS the
line terminator is not a character.

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

Right, so see above. You need a file system which has EOF state
determinable without look ahead. It is not language business.

[Though I don't defend End_Of_File. I would simply remove it from Text_IO.]

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

Huh, what did you expect buying Windows? (:-))

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

Yes, but then at least you would know what's going on. End_Of_File happened
to be lower level (in OSI hierarchy terms) than Get_Line. Mixing levels is
asking for trouble. Because End_Of_File drags you into a character-oriented
encoding issues, so have to face this in arms.

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

OK, this is a bit "theological" issue... (:-))

My answer is no. Exception is not an error. It indicates an exceptional
state. Note that an exceptional state is a *valid* state. While an error
(bug) has no corresponding program state at all.

Sure an exception may indicate an error, but this error is *never* one of
the program where it is handled. For example, Segmentation Fault is an
error of an application, but a valid state for the OS which has spawned
that erroneous application and where Segmentation Fault is handled.

To summarize: we should distinguish errors (and states) of the problem and
solution spaces. Exceptions live in the latter, what you meant does in the
former.

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

This is because you consider it from the C++ stand point. In Ada exceptions
are efficient. They are highly recommended for use in place of return
codes. This is a *good* design. End_Of_File in your program serves the
purpose of return code. What is even worse, from the software design
perspective, is that one operation "give me next line" is split into two,
so that the side effect of one determines the outcome of another and
reverse. It is a very fragile (and wrong) design. Just notice how much
efforts it requires to analyse. And what for? To defend a myth, that each
loop should have only one exit? Your code didn't managed that either!
Neither manages it inputs longer than 99 characters. Do you call it clean?
Further, even in C you wouldn't use it either. You probably would turn to
fgetc (or even to fread):

int Char;
   // Do we all know that characters are integers? char is just for fun,
   // real programmers are using int for all datatypes! (:-))

while (EOF != (Char = fgetc (File)))
{
   ...
}

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de