On 2022-03-08 08:45, Marius Amado-Alves wrote:

Behaviour of Ada.Text_IO on GNAT/Windows 11:

(1) Get_Immediate does not read the CR in CRLF pairs

(2) Get_Immediate does not read the ending CRLF pair at all (in loop terminated upon End_Of_File)

(3) an extra ending CRLF pair is output

Does this behaviour follow from the ARM?
Do other compilers behave 'better'?

Sequential_IO instantiated with Character works correctly (so I am not blocked, just curious:-)

I guess this is a part of translation text I/O does and sequential and
stream I/O do not.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Behaviour of Ada.Text_IO on GNAT/Windows 11:

(1) Get_Immediate does not read the CR in CRLF pairs

(2) Get_Immediate does not read the ending CRLF pair at all (in loop terminated upon End_Of_File)

(3) an extra ending CRLF pair is output

Does this behaviour follow from the ARM?
Do other compilers behave 'better'?

Sequential_IO instantiated with Character works correctly (so I am not blocked, just curious:-)

Thanks.
______
with Ada.Text_IO; use Ada.Text_IO;

procedure Get_Immediate_Test is
C: Character;
F_In: File_Type;
F_Out: File_Type;

procedure Default_Files_With_End_Of_File is
begin
while not End_Of_File loop
Get_Immediate (C);
Put (Character'Pos (C)'Img);
end loop;
end;

procedure Default_Files_With_Exception is
begin
loop
Get_Immediate (C);
Put (Character'Pos (C)'Img);
end loop;
exception
when others => null;
end;

procedure Named_Files_With_End_Of_File is
begin
Open (F_In, In_File, "imm_test_in_file.txt");
Create (F_Out, Out_File, "imm_test_out_file.txt");
while not End_Of_File loop
Get_Immediate (F_In, C);
Put (F_Out, Character'Pos (C)'Img);
end loop;
Close (F_In);
Close (F_Out);
end;

procedure Named_Files_With_Exception is
begin
Open (F_In, In_File, "imm_test_in_file.txt");
Create (F_Out, Out_File, "imm_test_out_file.txt");
begin
loop
Get_Immediate (F_In, C);
Put (F_Out, Character'Pos (C)'Img);
end loop;
exception
when others =>
Close (F_In);
Close (F_Out);
end;
end;

begin
Named_Files_With_Exception;
end;

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/03/2022 07:45, Marius Amado-Alves wrote:

Behaviour of Ada.Text_IO on GNAT/Windows 11:

(1) Get_Immediate does not read the CR in CRLF pairs

Isn't this where you need to check for EOL and then Skip; when you hit it?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-03-08 08:45, Marius Amado-Alves wrote:

Behaviour of Ada.Text_IO on GNAT/Windows 11:

(1) Get_Immediate does not read the CR in CRLF pairs

Get_Immediate is only of interest for reading from Standard_Input, primarily when it is the keyboard. It's better to use Get for other cases.

Get_Immediate is not well defined for reading line terminators. Whatever the compiler decides to implement is probably correct, and implementation defined. Should it behave like Get, which ignores line terminators? ObjectAda 10.2 ignores the Enter key (10.3 returns CR).

Get_Immediate returns the character corresponding to the key pressed. What is the character for the Enter key? GNAT has decided to return LF in that case. Should it behave differently if the input is from a file? Presumably, Get_Immediate should behave the same whether Standard_Input is the keyboard or redirected from a file.

(2) Get_Immediate does not read the ending CRLF pair at all (in loop terminated upon End_Of_File)

End_Of_File is defined to return True if all that remains in the file is a line terminator followed by a page terminator (A.10.5). As such, it is broken, since,
when reading a file with a null last line, it will return True before the last line is read. In practice, most compilers treat a final line terminator the same, to work with files produced by non-Ada programs.

(3) an extra ending CRLF pair is output

Close is defined to call New_page if the file does not already end with a page terminator [ARM A.10.2(3), http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-A-10-2.html], and a page is defined to be terminated by a line terminator followed by a page terminator (A.10). GNAT seems to use the same character sequence for line and page terminators, presumably so that text files output with Ada.Text_IO may be read by non-Ada programs. If you've output a single LF as the last thing in a file on
Windows, that is not a page terminator, so Close adds one.

If you need to see all the bytes in a file, Sequential_IO or Stream_IO are the ways to go. Of course, there is no portable way to read Standard_Input using Sequential_IO.

--
Jeff Carter
"What's the amount of the insult?"
Never Give a Sucker an Even Break
104

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 8 March 2022 at 07:46:53 UTC, Luke A. Guest wrote:

On 08/03/2022 07:45, Marius Amado-Alves wrote:

Behaviour of Ada.Text_IO on GNAT/Windows 11:

(1) Get_Immediate does not read the CR in CRLF pairs

Isn't this where you need to check for EOL and then Skip; when you hit it?

Sorry, Luke, I dont understand the question.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 8 March 2022 at 09:06:07 UTC, Jeffrey R.Carter wrote:

Get_Immediate returns the character corresponding to the key pressed. What is the character for the Enter key? GNAT has decided to return LF in that case.

Surely Text_IO is not scanning the keyboard. Or it should not. The OS does. Text_IO should just get the character from the OS. Without assumptions that it is this or that key.

For me the ARM is very clear:

"Reads the next character, either control or graphic, from the specified File or the default input file. " A.10.7 (10/3)

That is why I dont understand the issue.

My guess was that redirection on the Windows command line was the culprit (and it does interfere a bit, but not enough to explain all).

Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-03-08 13:20, Marius Amado-Alves wrote:

Text_IO should just get the character from the OS. Without assumptions that it is this or that key.

That is technically impossible under Windows. Windows does not deal with characters it does with scan codes which then might be converted to
characters this or that way, or not at all.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/03/2022 12:08, Marius Amado-Alves wrote:

On Tuesday, 8 March 2022 at 07:46:53 UTC, Luke A. Guest wrote:

On 08/03/2022 07:45, Marius Amado-Alves wrote:

Behaviour of Ada.Text_IO on GNAT/Windows 11:

(1) Get_Immediate does not read the CR in CRLF pairs

Isn't this where you need to check for EOL and then Skip; when you hit it?

Sorry, Luke, I dont understand the question.

There is a procedure called Skip to get past the EOL/EOP.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sorry, Luke, I dont understand the question.

There is a procedure called Skip to get past the EOL/EOP.

Thanks. Does not look applicable to the usecase which is just to read characters (graphic or not) from a file.

Get_Immediate as defined in the ARM looked to me as an escape from the page and line (and keyboard) abstractions. Guess not. Thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Pardon the duplicate (empty) response... I was trying to trigger a new scan for messages but had the reply window open... and first button is
<send>, not <fetch>.


On Tue, 8 Mar 2022 08:43:03 -0800 (PST), Marius Amado-Alves <amado.alves@gmail.com> declaimed the following:

Sorry, Luke, I dont understand the question.

There is a procedure called Skip to get past the EOL/EOP.

Thanks. Does not look applicable to the usecase which is just to read characters (graphic or not) from a file.

Get_Immediate as defined in the ARM looked to me as an escape from the page and line (and keyboard) abstractions. Guess not. Thanks.

I suspect the page/line aspects are too baked into the definition of Text_IO itself. It's defined to work on systems that perform record
oriented I/O, and hence don't use stream oriented <eol> markers. Systems
might use hidden <length>text... formats, fixed width formats (card
readers), etc. so the runtime for each system has to map into that concept.


--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 8 Mar 2022 08:43:03 -0800 (PST), Marius Amado-Alves <amado.alves@gmail.com> declaimed the following:

Sorry, Luke, I dont understand the question.

There is a procedure called Skip to get past the EOL/EOP.

Thanks. Does not look applicable to the usecase which is just to read characters (graphic or not) from a file.

Get_Immediate as defined in the ARM looked to me as an escape from the page and line (and keyboard) abstractions. Guess not. Thanks.

--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 08/03/2022 16:43, Marius Amado-Alves wrote:

Sorry, Luke, I dont understand the question.

There is a procedure called Skip to get past the EOL/EOP.

Thanks. Does not look applicable to the usecase which is just to read characters (graphic or not) from a file.

Get_Immediate as defined in the ARM looked to me as an escape from the page and line (and keyboard) abstractions. Guess not. Thanks.

Yeah, it's been years since I touched any file i/o stuff.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 8 March 2022 at 12:53:17 UTC, Dmitry A. Kazakov wrote:

On 2022-03-08 13:20, Marius Amado-Alves wrote:

Text_IO should just get the character from the OS. Without assumptions that it is this or that key.

That is technically impossible under Windows. Windows does not deal with characters it does with scan codes which then might be converted to characters this or that way, or not at all.

You mean Text_IO scans the keyboard?!

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-03-09 12:26, Marius Amado-Alves wrote:

On Tuesday, 8 March 2022 at 12:53:17 UTC, Dmitry A. Kazakov wrote:

On 2022-03-08 13:20, Marius Amado-Alves wrote:

Text_IO should just get the character from the OS. Without assumptions that it is this or that key.

That is technically impossible under Windows. Windows does not deal with
characters it does with scan codes which then might be converted to
characters this or that way, or not at all.

You mean Text_IO scans the keyboard?!

Of course not, usually you have no direct access to it.

Specifically GNAT's Text_IO implementation under Windows seems to use Microsoft's getch from the C run-time:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/getch-getwch?view=msvc-170

So all translation happens in the layer emulating file descriptors on
top of Windows I/O system; on top of whatever sits below, console driver
etc.

Interestingly getch let you access some actual scan codes as follows
from the description. Though of course you get them only if you deal
with an actual console and not with a pipe etc.

The point is that "character" is a fiction unless you read a modem line
and even then.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)