[Guido]
> 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.
We're never going to agree on this one, you know.
My definition of "bug" here has nothing to do with the std: something's "a
bug" if it's not functioning as designed. That's all. So if the
implementers would say "oops! that should not have happened!", then to me
it's "a bug". It so happens I believe the MS implementers would consider
this to be a bug under that defn. Multi-threaded libraries have to be
written to a much higher level than the C std guarantees (been there, done
that, and so have you), and this is specifically corruption in a crucial
area vulnerable to races. They have a timing hole! That's clear. If the
MS implementers don't believe that's "a bug", then I'd say they're too
unprofessional to be allowed in the same country as a multithreaded library
<0.1 wink>.
Your definition of "bug" seems to be more "I don't want it in Python's open
bug list, so I'll do what Tim usually does and appeal to the std in a
transparent effort to convince someone that it's not really 'a bug' -- then
maybe I'll get it off of Python's bug list".
I'm sure you'll agree that's a fair summary of both sides <wink>.
it's-a-bug-and-it's-no-longer-on-python's-open-bug-list-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