#1042 Formatted reads lose decimal digits after binary stream read

[Baljak]

With UCRT builds of libgfortran on Windows, an unformatted ACCESS='STREAM' read can change the process LC_NUMERIC from C to the Windows user locale. This bug does not occur on MinGW MSVCRT versions.

On Windows systems whose numeric locale is not dot-based, for example French Windows where LC_NUMERIC becomes French_France.1252, subsequent formatted/list-directed Fortran reads of dot-decimal real numbers are silently misparsed.

Examples:

"7.999999e-05" is read as 7
"0.202" is read as 0
"1.05" is read as 1
No read error is reported.

This is a bug I originally opened on MSYS2 GitHub: https://github.com/msys2/MINGW-packages/issues/29825.
A related issue has been also opened (not by me) on the official GCC bug tracker: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121759

I attached a reproducer in the present ticket.

What the program prints:

lc_numeric  initial                   =  C
parse       initial                   =  0.8000
lc_numeric  after stream read         =  French_France.1252
parse       after stream read         =  7.0000
lc_numeric  after setlocale c         =  C
parse       after setlocale c         =  0.8000
lc_numeric  after more stream reads   =  C
parse       after more stream reads   =  0.8000

The important part is:

lc_numeric  after stream read         =  French_France.1252
parse       after stream read         =  7.0000

The real value should be 0.8000, but after the stream read it is parsed as 7.0000.

A fix has been included in MYS2: https://github.com/msys2/MINGW-packages/pull/30705.

[Baljak]

This is the first time I've created a ticket on SourceForge. I made a mistake at the end by starting a sentence that I shouldn't have, and I can't even delete it. Can you give me permission to edit my ticket?

[NightStrike]

I removed the sentence for you, but as you can see, the record of the change is still there.

[Baljak]

Thank you! Could you also remove the period? Otherwise, the link doesn't work.