[Bug stdio/28258] New: fseek(3) under certain circumstances can loop endlessly with wide character streams

[Bug stdio/28258] New: fseek(3) under certain circumstances can loop endlessly with wide character streams

[infor at rudhar dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28258

            Bug ID: 28258
           Summary: fseek(3) under certain circumstances can loop
                    endlessly with wide character streams
           Product: glibc
           Version: 2.34
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: stdio
          Assignee: unassigned at sourceware dot org
          Reporter: infor at rudhar dot com
  Target Milestone: ---

When doing an fseek to a position just after the start of a valid UTF-8
character, after that character itself has been read with fgetcw just before,
fseek will get into an infinite loop.

Happens in glibc 2.28 (Debian), 2.31 (Mint 20.1 & Ubuntu 20.4), 2.33 (Ubuntu
20.10), 2.34 (Mint; glibc compiled from freshly downloaded GNU sources). 

Full description in 
https://rudhar.com/sfreview/siworin/siworin14.htm and 
https://rudhar.com/sfreview/siworin/siworin15.htm

Self-contained demonstration programs are in
https://rudhar.com/sfreview/siworin/src/ .

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/28258] fseek(3) under certain circumstances can loop endlessly with wide character streams

[infor at rudhar dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28258

--- Comment #1 from Ruud Harmsen <infor at rudhar dot com> ---
Earlier on, the endless loop in fseek happened when I fseeked to an invalid
byte after the start of a valid character.
Now however, I found it can also happen when going to a valid byte, that is
after an invalid character.
The reverse situation.

Also, before, it happened in a testing program that wasn't a realistic
representation of real life.
But now, the loop occurs when I tried to make a real-life application robust
against invalid input. Every high-quality program should have such robustness.
With GNU glibc 2.31, I can now only achieve that robustness in a weird,
possibly even illegal way, because the proper way to do it causes this endless
loop.

Therefore in my opinion this bug deserves more attention than it has received
so far, and it should be fixed, urgently.

A more detailed explanation is in my web article
https://rudhar.com/sfreview/siworin/siworin17.htm . A minimal self-contained
demonstration of the bug is in https://rudhar.com/sfreview/siworin/src/, under
the name siworin17.c . 

Meanwhile I know accurately where in the library sources the infinite loop
occurs. More on that later.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/28258] fseek(3) under certain circumstances can loop endlessly with wide character streams

[infor at rudhar dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28258

--- Comment #2 from Ruud Harmsen <infor at rudhar dot com> ---
The loop is in source file libio/wfileops.c, function adjust_wide_data, and the
repeated lines are 567, 568, 576, 582. Applies to GNU glibc versions 2.31 and
2.34.

More comments: http://rhar.info/sfreview/siworin/siworin18.htm .

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/28258] fseek(3) under certain circumstances can loop endlessly with wide character streams

[infor at rudhar dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28258

Ruud Harmsen <infor at rudhar dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|minor                       |normal
           Priority|P2                          |P1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/28258] fseek(3) under certain circumstances can loop endlessly with wide character streams

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28258

Carlos O'Donell <carlos at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |carlos at redhat dot com

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
Just a note here that glibc supports ",ccs=STRING" which allows the stream to
convert the data in the stream based on that coded character set. Thus when
seeking you need to complete the conversion, which should be possible, and
getting stuck in the loop is certainly a bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.