> Hello,
> > And, I'd like to point out one more time, we know of cases
> > where a blocking
> > read after a select will block. For example, if someone
> > interposes OpenSSL
> > between select/read/write and the OS. Someone *can* do this and
> > people *do*
> > do this.
> I'd like to point out one more time, that most of your arguments is
> not related to this discussion.
Should I just take your word for it?
> We have two file descriptors and we
> relay data between them.
You mean that's what you *think* you're doing. You have no way of
knowing
what's going on under the hood. You have no way of knowing whether, for
example, encryption has been invisibly added and the fact that you don't
know that is not grounds for breaking because of it.
> If you build system with interposes OpenSSL
> between select/read/write and the OS - fine, if you build system with
> "sophisticated timeout handing" - fine, but this is unrelated to this
> discussion.
I'm sorry, how is it unrelated?
> Your next argument will be:
> "if you do select() and space shuttle is flying ..."
I don't get your attitude. You have a set of specific guarantees. The
guarantees are adequate to make your code guaranteed to work. You insist on
writing code that relies on a guarantee you don't have. It breaks, because
the thing that wasn't guaranteed didn't happen.
I am saying that's not surprising. Lots of code built on guarantees you
don't have break. I can cite example after example where people built code
based on guarantees they didn't have, not able to to think of any possible
way their code could break at the time, but lo and behold, later it broke.
Those who stuck to the guarantees they actually had don't have this
problem. When things change, they keep the guarantees you actually have.
I can come up with example after example where at the time the broken
code
was written, *nobody* could imagine any way to break it. Everyone knew it
wasn't guaranteed to work, but some people foolishly argued that it was
guaranteed to work because nobody could think of a way to break it. The
future *proved* them wrong.
Can I say for sure it will happen in this case? No. But I have seen it
happen too many times causing too much pain to not feel obligated to point
it out. The code is broken. It happens to work. Tomorrow it might not happen
to work.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
