[Bug ada/66390] New: Text_IO.Get_Line does not correctly handle missing line marker for last line in all cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66390 Bug ID: 66390 Summary: Text_IO.Get_Line does not correctly handle missing line marker for last line in all cases Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: tornenvi at gmail dot com Target Milestone: --- Created attachment 35685 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35685&action=edit Program file For a "non canonical" file as described in the reference manual gcc\ada\doc\gnat_rm\the_implementation_of_standard_i_o.html#text-io which has no line marker at the end of file, then it is possible for Get_Line to return the incorrect length. Note that a "non canonical" file is a "standard" file in windows so this use case is common. The program file attached FileRead.adb simply reads the first line of a text file into a 6 character buffer, and outputs the length of the line read, the line and the line again as hex. I compile FileRead.adb with gnatmake FileRead.adb I use windows notepad to create the test file Test.txt. note that windows notepad will not place a end of line marker at the end of the file. When using Test.txt with the one line of text ABCD with no blank line at the end of the file I get output 1 below -- Output 1 -- Length= 4 Line=[ABCDXX] Line as hex=[414243445858] -- as expected. However if Test.txt is the one line of text ABCDE with no blank line at the end of the file then I get output 2 below -- Output 2 - Length= 6 Line=[ABCDE ] Line as hex=[4142434445ff] - I receive an unexpected length of 6, expected 5. The fact that the last two characters are not 'XX' is acceptable since ARM A.10.7 19 says "The values of characters not assigned are not specified." I get the same output 2 if I compile the program with GNAT GPL 2014, 2013,2012 or 2011 or with mingw FSF GNAT 4.7.0-1 or 4.8.1-4. However if I compile with mingw FSF GNAT 4.5.2-1 , 4.5.0-1, 4.4.0 or 3.4.5 then I get the expected output 3 below -- Output 3 - Length= 5 Line=[ABCDEX] Line as hex=[414243444558] - Under windows the one line text file does not have an end of line character (usually CRLF) which means it is not a canonical text file as described here gcc\ada\doc\gnat_rm\the_implementation_of_standard_i_o.html#text-io however that section also states that text_io can be use to read non canonical text files and the very last line of that section says "Every LF character is considered to end a line, and there is an implied LF character at the end of the file." this indicates to me that there should be an implied LF at the end of the file and I should be getting the expected output 3 result for all the compilers. The program works correctly for test.txt with 4 and less or 6 and more characters. I believe the problem is in \gcc\ada\a-tigeli.adb at line 187 a comment says -- If we get EOF after already reading data, this is an incomplete -- last line, in which case no End_Error should be raised. however at line 193 there is no test to check that the last character read 'ch' is the EOF marker instead it adds it the Item buffer and increments the length. I suggest line 193 be changed from elsif ch /= LM then to elsif ch /= LM and ch /= EOF then
[Bug ada/66390] Text_IO.Get_Line does not correctly handle missing line marker for last line in all cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66390 --- Comment #1 from tornenvi at gmail dot com --- Created attachment 35686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35686&action=edit Test case file Test.txt that shows the issue for the program FileRead
[Bug ada/66390] Text_IO.Get_Line does not correctly handle missing line marker for last line in all cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66390 --- Comment #2 from tornenvi at gmail dot com --- also note that line 84 of \gcc\ada\a-tigeli.adb reads memset (S, 10, size_t (N)); I believe the hardcoded '10' here should be 'LM'
[Bug ada/104767] New: GNAT.Serial_Communications windows package allows/causes multiple closing of the same windows handle.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104767 Bug ID: 104767 Summary: GNAT.Serial_Communications windows package allows/causes multiple closing of the same windows handle. Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: tornenvi at gmail dot com Target Milestone: --- Created attachment 52554 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52554&action=edit Patch to set handle to -1 on close. There is an error in the GNAT Ada package GNAT.Serial_Communications, as implemented in the file gcc/ada/libgnat/g-sercom__mingw.adb in the gcc git sources. Which is ultimately installed as 10.3.1\adainclude\g-sercom.adb on an windows installation. This package does not correctly clean up the Port.H handle in the Close procedure. The end result is that when Connect (or Close) is called for a second time it will silently close the previous window handle again. If the previous windows handle has been reassigned (this happens often under windows 10 at least) then whatever other random device,interface, file I/O will fail when its handle is unexpectedly closed. This situation can be very difficult to identify. I Also believe that the Ada implementation may use windows handles to implement its task system, so this bug can lead to unexpected application crashes. The issue was detected in V10.3.1 of GCC but appears to be in the current HEAD commit ea4911c4fa629a97d22b6e48975d8f1c4e04549d The attached patch implements the fix. Note that this error appears to have been introduced when it was changed to allow for some changes for the Linux implementation in commit 55d4e2ba076049f88c24011f2f63aa226e6c87a0 Importantly the Linux implementation does not appear to have the same fault, since it does not attempt to silently Close the serial port on Connect. So the two implementations are different in behavior. I would suggest that the package be changed to raise an exception in the Connect function if the handle is not '-1' instead of silently closing the handle, but such a change does break backwards compatibility.
[Bug ada/104767] GNAT.Serial_Communications windows package allows/causes multiple closing of the same windows handle.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104767 --- Comment #1 from tornenvi at gmail dot com --- Bug report should be referring to calls to 'Open' instead of 'Connect'.
[Bug ada/104767] GNAT.Serial_Communications windows package allows/causes multiple closing of the same windows handle.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104767 --- Comment #2 from tornenvi at gmail dot com --- Created attachment 52558 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52558&action=edit Test program to demonstrate problem Adding test program code gnatserialerrortest2.adb to highlight the problem. The program requires two serial ports, the comport numbers are hard coded for simplicity, testers will have to modify the code with the comports for their own test environment.
[Bug ada/66390] Text_IO.Get_Line does not correctly handle missing line marker for last line in all cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66390 tornenvi at gmail dot com changed: What|Removed |Added Resolution|WONTFIX |FIXED --- Comment #5 from tornenvi at gmail dot com --- Appears to have been fixed in 2016 with commit c7518e6f52aad178875818666fcfc92ff4e08e8f
