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: a07f3367d7,c689b55786a9f2bd X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news2.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!nx01.iad01.newshosting.com!newshosting.com!news2.euro.net!newsfeed.freenet.ag!newsfeed.kamp.net!newsfeed.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: for S'Image use Func?? Date: Thu, 13 May 2010 21:53:41 +0300 Organization: Tidorum Ltd Message-ID: <85305lF6p9U1@mid.individual.net> References: <4be417b4$0$6992$9b4e6d93@newsspool4.arcor-online.net> <1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net> <84r4k5Ftk8U1@mid.individual.net> <84sfkjF3btU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net EnsdDQzOZ35SxvXG0DGPlwD1zoeXTwZ8MJgpn/Xvm7//Smgnau Cancel-Lock: sha1:MuSh1m63BzYxVwFSgzV2lKnb7eY= User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100328) In-Reply-To: Xref: g2news2.google.com comp.lang.ada:11589 Date: 2010-05-13T21:53:41+03:00 List-Id: Yannick Duch�ne (Hibou57) wrote: > Le Tue, 11 May 2010 09:34:42 +0200, Niklas Holsti > a �crit: >> Yes, with one problem, which is that it is hard (that is, I don't know >> how) to detect when the very last line in the input file is null. This >> is because End_Of_Line returns true also at end of file, and >> End_Of_File returns true also when the data remaining in the file is >> an end-of-line (and end-of-page) before the true end of file. One >> consequence is that a truly empty file (like /dev/null) looks the same >> as a file with one null line (like echo ""). > This may be "hard" only with the Standard_Input file, which is a > Text_IO.File_Type, and Text_IO, as previously said, is a file of lines. We are indeed discussing Text_IO. Whether the program reads Standard_Input or some other Text_IO file is irrelevant. > A file of line, as you shown you know, is a file where each is line > strictly delimited in platform dependent manner (with LF on UNIX, CR+LF > on Windows and CR on Mac, or with specific chunks or records on some > other systems). The actual line terminators (if any) used in the physical file are irrelevant to the problem. The problem is in the logical definition of a text file and of the Text_IO operations and the information they give about the contents of the file. The problem can perhaps appear in different ways, depending on how a particular Text_IO implementation maps physical files to Text_IO concepts. My experience is with Gnat on Linux and MS Windows. > So obviously, each line is expected to have an end, just > like each file have an end, and the end of the last line is also the end > of a file, if the file is a file of line. Just like a file of some kind > of records ends with the end of the last record. I agree that each file has an end, and each line has an end. But Text_IO extends this in two weird ways: - The first problem is that the Text_IO operations require (the appearance of) a final line terminator before the end of the file. This means that no Text_IO file can be truly empty in the sense of having no lines at all; it will always have (or appear to have) at least one line terminator, so at least one line, if we count the number of lines by counting the number of line terminators. And it seems queer to have an "end of a line" with no line that it ends... - The second problem is that the Text_IO operations are defined to make no difference between two line terminators at the end of a file, and one line terminator. If the last line in the file is null (zero length), it is invisible to Text_IO. As far as I know, at least. > I was to say this is a matter only with Standard_Input, and in the > context of "/dev/null" which you gave, you have no need to open > "/dev/null" as a file of lines if have no reason to think "/dev/null" is > indeed a file of lines. An empty file, like /dev/null, seems the only reasonable representation of a text file with no lines at all. But such empty text files conflict with the Text_IO concepts, which is one of the problems. > To talk about text files now : let say most of them are just > inconsistently formated, as many text files as produced by text editors, > are not formated in the constant way : the last line oftenly lacks a > delimiter for the last line. It is up to the Text_IO implementation to decide how to handle such files; conceivably, an implementation could raise an exception, or behave in some other unexpected way, if the final line terminator is not physically represented in the expected way. But the Text_IO operations (Get (Character), End_Of_Line, End_Of_File) are defined to let an implementation ignore the missing line terminator. For example, End_Of_Line is defined to return True if the current position is at the end of the file, which makes it appear *as if* the file were correctly formatted with a final line terminator before the end of the file. The two problems I describe above are unfortunate by-products of these definitions. But again, the "problems" almost never cause any real difficulty, as final null lines can be ignored in most uses of Text_IO. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .