This is a minor patch against 2.4.19-pre3 for readv/writev to have it
return EINVAL if count=0 is passed to it. According to the man page and
also the specifications for readv/writev, this is the correct behaviour.
Thanks,
Paul Larson
Index: linux24/fs/read_write.c
diff -u linux24/fs/read_write.c:1.1.1.1 linux24/fs/read_write.c:1.1.1.1.2.1
--- linux24/fs/read_write.c:1.1.1.1 Wed Mar 20 12:00:25 2002
+++ linux24/fs/read_write.c Wed Mar 20 12:19:06 2002
@@ -215,10 +215,9 @@
* First get the "struct iovec" from user memory and
* verify all the pointers
*/
- ret = 0;
+ ret = -EINVAL;
if (!count)
goto out_nofree;
- ret = -EINVAL;
if (count > UIO_MAXIOV)
goto out_nofree;
if (!file->f_op)
> This is a minor patch against 2.4.19-pre3 for readv/writev to have it
> return EINVAL if count=0 is passed to it. According to the man page and
> also the specifications for readv/writev, this is the correct behaviour.
I beg to disagree. The existing behaviour is compliant. The behaviour for
writing/reading 0 may optionally return -EINVAL. (Single Unix Spec v3).
Alan
I would disagree. According to the spec "The iovcnt argument is valid
if greater than 0 and less than or equal to {IOV_MAX}, as defined in
<limits.h>" (http://www.opengroup.org/onlinepubs/007904975/).
The behaviour you want to achieve is described as optional, besides
there is programs depending on the old behaviour (of my own at least :).
It's very handy to skip extra zero-parameter check...
-alex
On Wed, Mar 20, 2002 at 12:53:47PM -0600, Paul Larson wrote:
> This is a minor patch against 2.4.19-pre3 for readv/writev to have it
> return EINVAL if count=0 is passed to it. According to the man page and
> also the specifications for readv/writev, this is the correct behaviour.
>
On Thu, 2002-03-21 at 01:34, Alex Riesen wrote:
> I would disagree. According to the spec "The iovcnt argument is valid
> if greater than 0 and less than or equal to {IOV_MAX}, as defined in
> <limits.h>" (http://www.opengroup.org/onlinepubs/007904975/).
> The behaviour you want to achieve is described as optional, besides
> there is programs depending on the old behaviour (of my own at least :).
> It's very handy to skip extra zero-parameter check...
> -alex
^-This is the one I was referring to. Is there any reason for it to not
be in compliance with this?
"The iovcnt argument is valid if greater than 0 and less than or equal to {IOV_MAX}, as defined in
<limits.h>" (http://www.opengroup.org/onlinepubs/007904975/)
Sorry, I just noticed that there was a previous thread here in which a
patch was submitted by [email protected]. I think the same person
who started it might have been the same person that pointed out that one
of our LTP testcases was passing when it shouldn't be and brought it to
my attention. It doesn't look like that thread got resolved though.
Paul Larson
may be not. SunOS, HPUX, and AIX return EINVAL (unless it's their libc).
Maybe it is useful for compatibility with read/write.
And it's not really an error, after all, whereas EINVAL also means
overflow (sum of all iovec's longer than ssize_t) for readv/writev.
-alex
On Thu, Mar 21, 2002 at 07:28:50AM -0600, Paul Larson wrote:
> On Thu, 2002-03-21 at 01:34, Alex Riesen wrote:
> > I would disagree. According to the spec "The iovcnt argument is valid
> > if greater than 0 and less than or equal to {IOV_MAX}, as defined in
> > <limits.h>" (http://www.opengroup.org/onlinepubs/007904975/).
> > The behaviour you want to achieve is described as optional, besides
> > there is programs depending on the old behaviour (of my own at least :).
> > It's very handy to skip extra zero-parameter check...
> > -alex
> ^-This is the one I was referring to. Is there any reason for it to not
> be in compliance with this?
> "The iovcnt argument is valid if greater than 0 and less than or equal to {IOV_MAX}, as defined in
> <limits.h>" (http://www.opengroup.org/onlinepubs/007904975/)
>
> Sorry, I just noticed that there was a previous thread here in which a
> patch was submitted by [email protected]. I think the same person
> who started it might have been the same person that pointed out that one
> of our LTP testcases was passing when it shouldn't be and brought it to
> my attention. It doesn't look like that thread got resolved though.
>
> Paul Larson