> Think like an implementer here <0.5 wink>: they've lost track of how many > characters are in the buffer despite a locking scheme whose purpose is to > prevent that. If it were my implementation, that would be a top-priority > bug no matter how silly the first program I saw that triggered it. The locking prevents concurrent threads accessing the stream. But mixing reads and writes (without intervening fseek etc.) is illegal use of the stream, and the C standard allows them to be lax here, even if the program was single-threaded. In other words: the locking is so good that it serializes the sequence of reads and writes; but if the sequence of reads and writes is illegal, they don't guarantee anything. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4