From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,5afe598156615c8b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!news4.google.com!news2.volia.net!news.germany.com!feeder.ecngs.de!ecngs!feeder2.ecngs.de!130.59.10.21.MISMATCH!kanaga.switch.ch!news-zh.switch.ch!switch.ch!cernne03.cern.ch!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Get_Line problem (GNAT bug?) Date: Thu, 07 Dec 2006 09:26:07 +0100 Organization: CERN News Message-ID: References: <1c1gbc5u9cpvp.1wj1zhhn7q86j$.dlg@40tude.net> NNTP-Posting-Host: abpc10883.cern.ch Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: cernne03.cern.ch 1165479967 24283 137.138.37.241 (7 Dec 2006 08:26:07 GMT) X-Complaints-To: news@@cern.ch NNTP-Posting-Date: Thu, 7 Dec 2006 08:26:07 +0000 (UTC) User-Agent: Thunderbird 1.5.0.8 (X11/20061113) In-Reply-To: <1c1gbc5u9cpvp.1wj1zhhn7q86j$.dlg@40tude.net> Xref: g2news2.google.com comp.lang.ada:7844 Date: 2006-12-07T09:26:07+01:00 List-Id: 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 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/