https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93672
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> --- On second thoughts, I don't think that fix is right. istream::ignore takes an int_type for the delimiter, so passing it a char_type with a negative value will confuse it. For example, str.ignore(n, '\xff`) will treat the delimiter as EOF and ignore up to n chars, ignoring any '\xff` characters that might be in the stream buffer's get area. That means it's wrong to call ignore(n, '\xff') on a platform where char is signed, because it won't do what you expect (unless you're really intending to treat \xff as EOF). This case is similar, it ignores up to n characters, or until sgetc() returns a character equal to '\x80' ... but that can never happen because sgetc() never returns a negative value unless it reaches EOF. So there is a gcc bug here, because we should not loop forever. But the problem is that we use inconsistent conditions for deciding whether we've found the delimiter.
