Bug#629994: sendfile returns early without user-visible reason
On Fri, Jun 10, 2011 at 08:17:22AM -0500, Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Well, the relevant posix manpage for read is read, not the one for write.
> > read is clear.
>
> I looked at both. I suppose we will have to agree to disagree here ---
Yes, but thats your lack of understanding prose logic, not a valid
disagreement:
> in standardese "may" and "shall" both have clear meanings, and unless I
> missed something obvious the wording you pointed to did not place the
> requirement we are talking about on the implementation.
Thats true - the wording, paraphrased, is "an implementation may return less
under these conditions".
That indeed is true. It is not *required* to return less, only *allowed*
to. It is indeed not "the implemenentation shall return less under these
conditions".
The point is that nowhere else is it *allowed* to return less under
*other* conditions. posix read *has* to try to read those bytes, and linux
read doesn't.
If you really still disagree, then please quote where the standard
*allows* the exception to the semantics of read, namely that it doesn'T
need to attempt to read those bytes, because it's clearly not doing it -
if it attempted that, then it would be able to read them.
This is the source of the confusion. The standard is clear enough here,
the problem is not "may" vs. "shall" but that you ignore that nowhere does
it allow this behaviour. What I quoted is only the list of allowed
exceptions, where the implementation may deviate.
Again, it is absolutely clear both to posix as well as to common sense
what read should do: it should read what i ask it to read. The standard
specifies a list of conditions where it is allowed NOT to do that. It also
specifies a list of things it may do elsewhere, but none of these allow
the behaviour, namely *not* trying to read those bytes.
> Not that it matters much, since on one hand the text is obviously less
> clear than ideal and there are people in the Austin Group who would be
The text is absolutely clear. The problem is that you are confused about the
prose logic. Again, the structure is like this:
a) read does A.
b) read may not do A under these conditions.
According to you, that means
c) read may not do A under any conditions.
But thats not what is written there.
Or maybe you expect this:
a) read shall A.
But thats not true either - the normative portion of the standard is
normative, not just sentences that have "shall" or "may" in them.
> better) and on the other hand, Linux does not follow Posix rigidly
> anyway.
Well, then programs such as dd which are currently broken for large
blocksizes, need to be fixed. Example on a 8.7gb file:
dd if=x of=/dev/null bs=1072x1024x1024
7+1 records in
7+1 records out
dd if=x of=/dev/null bs=3072x1024x1024
0+5 records in
0+5 records out
If you now add a conversion or reblocking you have instant data loss. Some
tars or other programs break with large blocksizes etc.
I find it rather disingenious to argue whether linux is posix or not. As I
wrote multiple times, the behaviour is expected by *existing* programs, is
historically correct, and is expected even by programs in debian, whether
posix or not. gnu programs expect it. You acknowledges this at least
partially yourself. Why bother with totally ridiculous misinterpretations
of POSIX? What's the win for debian to talk this bug down that breaks
existing applications?
To me, it doesn't matter that much if all userspace programs get fixed to
work around this bug, or if the kernel gets fixed, or nothing gets fixed.
However, this is obviously a problem in the kernel, and not with all those
userspace prorgams that work portably on other systems but not on any
gnu/linux system.
I mean, whats the point? Are you really arguing that all these userspace
programs are broken? Good luck convincing their authors.
I also find it weird that there are people replying to me who clearly
didn't even bother to read the bugreport.
> But I had thought I could point to that easy avenue for improving
> documentation and portability in the wider world.
Sure, here's one for dd, you can adapt it for other programs, but don't
expect me to list all of them.
"dd is broken for blocksizes near or large than 2gb, as the linux
kernel isn't capable of reading more then 0x7fff000 bytes in one go,
and dd expects psoix compliance, which linux does not care for.".
(or whatever the limit is)
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
Reply to: