Re: Ada.Text_IO.Get_Line issue in windows

[tornenvi <tornenvi@gmail.com>]

On 6/2/2015 12:14 PM, AdaMagica wrote:
> As you say, it's a nonregular file. Are you sure the documentation you cite is up to date with your GNAT implementation? Obviously it isn't.
>

I know by the definition it is a nonregular file however it is a "standard" windows text file.
Earlier versions of the compiler did handle it correctly.

I just checked the gnat reference manual for gcc 5.1 direct from gnu.org and the documentation is still the same.

I also found in a-textio.ads ...

   -----------------------------------
    -- Handling of Format Characters --
    -----------------------------------

    --  Line marks are represented by the single character ASCII.LF (16#0A#).
    --  In DOS and similar systems, underlying file translation takes care
    --  of translating this to and from the standard CR/LF sequences used in
    --  these operating systems to mark the end of a line. On output there is
    --  always a line mark at the end of the last line, but on input, this
    --  line mark can be omitted, and is implied by the end of file.

So I believe the intent of the compiler code is as described in the documentation.

I did some more digging and it seems that the Get_line function was modified and separated out into its
own package (a-tigeli.adb) and the code in this file is different from what it used to be.

I believe I have found the problem in that file (a-tigeli.adb)

I believe line 193 which is

    elsif ch /= LM then

should read

    elsif ch /= LM and ch /=EOF then


There is even a comment already there saying

     --  If we get EOF after already reading data, this is an incomplete
     --  last line, in which case no End_Error should be raised.

it just looks like the EOF was not checked for before
adding the last character.


I will post a bug report to gcc.gnu.org/bugzilla for the FSF compiler.

I could not find any way to report a bug to Adacores libre site,
is there some where I should report it to?

Is there any point? I assume Adacore will be the ones processing the FSF gcc ada
bugs anyway.