linux-kernel - RE: SELECT() returns 1 But FIONREAD says (Input/output error)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <MDEHLPKNGKAHNMBLJOLKEEEAEEAC.davids@webmaster.com>
Date:	Fri, 1 Jun 2007 15:03:21 -0700
From:	"David Schwartz" <davids@...master.com>
To:	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: RE: SELECT() returns 1 But FIONREAD says (Input/output error)

> David Schwartz wrote:

> >> The misunderstanding is from the docs.
> >> The select() does not report device errors.
> >> Select will just "more precisely, to see if a read will not block".

> > This is a much slighter misunderstanding. The result of the 'select'
> > function tells you nothing about what a particular 'read' will
> > or will not do.

> The docs 'precisely' says that it does. I'm sorry if you cannot trouble
> yourself to read the man pages to address your issues with the correct
> functionality of the select call.

No, that's not what the docs say. That's what the docs are frequently
misunderstood to say, but that is not what they actually say. When they say,
for example, "see if a read will not block", they mean a hypothetical
concurrent read that does not take place, not a future actual read.

It's bad wording, but it is not incorrect unless you choose to misunderstand
it. For example, one could write that the 'access' function tells you if an
"'open' will succeed", but that doesn't mean an 'open' after an 'access'
*must* succeed.

Like all status-reporting functions, 'select' tells you information that is
accurate at some point in-between when you called it and when it returned
that value to you. But it makes no predictions about the future, and the
documentation does not say that it does. It does imply that it does, and
that's why it's important to correct this misconception whenever it comes
up.

POSIX's documentation is a bit clearer, saying "would block" rather than
"will block". This helps to make it clear that we're talking about a
hypothetical concurrent operation, not an actual future one.

DS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/