[Guido] > I bet you it's rejected on the basis of "the docs tell you not to mix > reading and writing on the same stream without intervening seek or > flush." If I were on the support line I would do that. So would I if I were a typical first-line support idiot <wink>. But the *implementers*-- if they ever see it --should be very keen to figure out how they managed to let the _iobuf get corrupted. *I'm* not mucking with their internals, nor doing wild pointer stores, nor anything else sneaky to subvert their locking protection. I wasn't even trying to break it. The only code reading from or storing into the _iobuf is theirs. They're ordinary stdio calls with ordinary arguments, and if *any* sequence of those can cause internal corruption, they've almost certainly got a problem that will manifest in other situations too. 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. but-willing-to-let-them-decide-whether-they-care-ly y'rs - tim
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