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!postnews.google.com!73g2000cwn.googlegroups.com!not-for-mail From: "Adam Beneschan" Newsgroups: comp.lang.ada Subject: Re: Get_Line problem (GNAT bug?) Date: 7 Dec 2006 09:42:13 -0800 Organization: http://groups.google.com Message-ID: <1165513333.321151.74320@73g2000cwn.googlegroups.com> References: NNTP-Posting-Host: 66.126.103.122 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1165513338 24287 127.0.0.1 (7 Dec 2006 17:42:18 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 7 Dec 2006 17:42:18 +0000 (UTC) User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: 73g2000cwn.googlegroups.com; posting-host=66.126.103.122; posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w Xref: g2news2.google.com comp.lang.ada:7853 Date: 2006-12-07T09:42:13-08:00 List-Id: Steve wrote: > "Maciej Sobczak" wrote in message > news:el6jss$268$1@cernne03.cern.ch... > [snip] > > > > Any thoughts? > > > You have run across what I consider to be a weakness in the standard Text_IO > library, it is one of the few things I find really annoying about Ada, which > I really like otherwise. > > In Ada you can't write a simple program to read and process lines in a text > file that looks something like: > > while not End_Of_File( inFile ) loop > Get_Line( inFile, Input_Buffer, Count ); > Process_Line( Input_Buffer( 1 .. Count ) ); > end loop; > > The problem is that Get_Line reads a line of text into a string buffer and > returns the count of characters read. Nitpick: Get_Line returns the *index* of the last character it has read into the buffer (or Input_Buffer'First-1 if none), not the count. The two are equivalent if the 'First of the buffer is 1. But it doesn't have to be. You can say something like Get_Line (InFile, Some_Buffer(10..50), Last); and if it reads three characters, the three characters will be read into Some_Buffer(10..12) and Last will be set to 12. The "line of text" is defined by the > next sequential characters from the current position of the file up to the > next line terminator. If the last character in the file doesn't happen to > be a line termnator an End_Error exception is raised. This, I think, is implementation-dependent. Ada makes it clear that a "line terminator" is a logical concept, not a character. There is nothing stopping a Unix-type implementation from saying that a file does not end with a LF charcter, then the implementation will consider the end-of-file to be accompanied by an *implicit* line terminator that is not represented by any bits in the file, but is conceptually considered to be there anyway. Ada allows this interpretation. It's a mistake to think of a line terminator as a "character"; this is probably a common mistake among those used to using C and Unix (or Linux or other OS's ending in "x") (or Solaris), but it's not even correct to say that a line terminator is a character on other OS's. On Windows, it's two characters (CR-LF). VMS, as I recall, doesn't use any character as a line terminator, but keeps information on where lines start and how long they are in an index or somewhere. Ada is a portable language that needs to be implementable on all these systems and others, so therefore it left the definition of "line terminator" up to the implementation and did not tie us to the concept that there has to be a "character" involved. -- Adam