--- read_write.c.org Fri Mar 15 16:10:05 2002
+++ read_write.c Fri Mar 15 16:10:13 2002
@@ -241,10 +241,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)
Jim Hollenback wrote:
> According to readv(2) EINVAL is returned for an invalid
> argument.
Right.
> The examples given were count might be greater than
> MAX_IOVEC or zero.
Wrong, or at least confusingly phrased.
In the good old days, a man page described what the system did,
and the ERRORS section gave the reasons for the possible error
returns.
These days a man page describes a function present on many
Unix-like systems, and not all systems have precisely the
same behaviour. POSIX man pages therefore distinguish under
ERRORS the two possibilities "if foo then this error must be
returned", and "if foo then this error may be returned".
Linux man pages do not (yet) make this distinction -
adding this is a lot of careful work, and so far
nobody is doing this [hint..].
In other words, the ERRORS section in Linux man pages is
to be interpreted as "if foo then this error may be returned".
Note that it may not be desirable at all to do things that way,
there is no need for kernel patches, it just means that systems
exist with this behaviour, so that authors of portable programs
must take this into account.
Balbir Singh wrote:
> Apply this trivial patch, if you want the required behaviour
But the behaviour is not required.
Paul Larson makes the same mistake.
Andries
I agree it is not a big thing at all, zero not
returning any error. Yes! I read and understood the
MAY return an error, it makes complete sense.
I agree, the Linux man pages need a lot of work,
if they are going to be even close to reflecting
some of things in the kernel.
Thanks,
Balbir
--- [email protected] wrote:
> Jim Hollenback wrote:
>
> > According to readv(2) EINVAL is returned for an
> invalid
> > argument.
>
> Right.
>
> > The examples given were count might be greater
> than
> > MAX_IOVEC or zero.
>
> Wrong, or at least confusingly phrased.
>
>
> In the good old days, a man page described what the
> system did,
> and the ERRORS section gave the reasons for the
> possible error
> returns.
> These days a man page describes a function present
> on many
> Unix-like systems, and not all systems have
> precisely the
> same behaviour. POSIX man pages therefore
> distinguish under
> ERRORS the two possibilities "if foo then this error
> must be
> returned", and "if foo then this error may be
> returned".
>
> Linux man pages do not (yet) make this distinction -
> adding this is a lot of careful work, and so far
> nobody is doing this [hint..].
> In other words, the ERRORS section in Linux man
> pages is
> to be interpreted as "if foo then this error may be
> returned".
>
> Note that it may not be desirable at all to do
> things that way,
> there is no need for kernel patches, it just means
> that systems
> exist with this behaviour, so that authors of
> portable programs
> must take this into account.
>
> Balbir Singh wrote:
>
> > Apply this trivial patch, if you want the required
> behaviour
>
> But the behaviour is not required.
> Paul Larson makes the same mistake.
>
> Andries
__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards?
http://movies.yahoo.com/
Doesn't seem confusing at all.
RETURN VALUE
On success readv returns the number of bytes read. On
success writev returns the number of bytes written. On
error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid argument was given. For instance count
might be greater than MAX_IOVEC, or zero. fd could
also be attached to an object which is unsuit-
able for reading (for readv) or writing (for
writev).
I don't see much in the way of waffle words. If count is greater than
MAX_IOVEC or zero you get EINVAL. I suppose your next argument is if
count exceeds MAX_IOVEC a return of 0 is okay since, hopefully, nothing
was read? Where do you read a non-error return of zero is acceptable
for count of 0? I states EINVAL for a count of 0.
If your going to rework the manpage, then drop a count of 0 as an error,
otherwise fix the kernel with the trival patch.
Jim
On Mar 26, 9:01am, Balbir Singh wrote:
> Subject: Re: readv() return and errno
> I agree it is not a big thing at all, zero not
> returning any error. Yes! I read and understood the
> MAY return an error, it makes complete sense.
>
> I agree, the Linux man pages need a lot of work,
> if they are going to be even close to reflecting
> some of things in the kernel.
>
>
> Thanks,
> Balbir
>
> --- [email protected] wrote:
> > Jim Hollenback wrote:
> >
> > > According to readv(2) EINVAL is returned for an
> > invalid
> > > argument.
> >
> > Right.
> >
> > > The examples given were count might be greater
> > than
> > > MAX_IOVEC or zero.
> >
> > Wrong, or at least confusingly phrased.
> >
> >
> > In the good old days, a man page described what the
> > system did,
> > and the ERRORS section gave the reasons for the
> > possible error
> > returns.
> > These days a man page describes a function present
> > on many
> > Unix-like systems, and not all systems have
> > precisely the
> > same behaviour. POSIX man pages therefore
> > distinguish under
> > ERRORS the two possibilities "if foo then this error
> > must be
> > returned", and "if foo then this error may be
> > returned".
> >
> > Linux man pages do not (yet) make this distinction -
> > adding this is a lot of careful work, and so far
> > nobody is doing this [hint..].
> > In other words, the ERRORS section in Linux man
> > pages is
> > to be interpreted as "if foo then this error may be
> > returned".
> >
> > Note that it may not be desirable at all to do
> > things that way,
> > there is no need for kernel patches, it just means
> > that systems
> > exist with this behaviour, so that authors of
> > portable programs
> > must take this into account.
> >
> > Balbir Singh wrote:
> >
> > > Apply this trivial patch, if you want the required
> > behaviour
> >
> > But the behaviour is not required.
> > Paul Larson makes the same mistake.
> >
> > Andries
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Movies - coverage of the 74th Academy Awards?
> http://movies.yahoo.com/
>-- End of excerpt from Balbir Singh
> I don't see much in the way of waffle words. If count is greater than
> MAX_IOVEC or zero you get EINVAL. I suppose your next argument is if
SuS is definitive not the man page. That page btw is woefully out of date
> If your going to rework the manpage, then drop a count of 0 as an error=
> ,
> otherwise fix the kernel with the trival patch.
The man page is buggy if anything is.
From [email protected] Tue Mar 26 18:13:40 2002
Doesn't seem confusing at all.
RETURN VALUE
On success readv returns the number of bytes read. On
success writev returns the number of bytes written. On
error, -1 is returned, and errno is set appropriately.
ERRORS
EINVAL An invalid argument was given. For instance count
might be greater than MAX_IOVEC, or zero. fd could
also be attached to an object which is unsuit-
able for reading (for readv) or writing (for
writev).
I don't see much in the way of waffle words. If count is greater than
MAX_IOVEC or zero you get EINVAL.
Yes, without hesitation you choose the wrong interpretation.
That is why I explained in so much detail what the right
interpretation is. Since you perhaps still do not understand,
let me reiterate:
The above ERRORS section says: In case this call returns EINVAL
one of the possible reasons is that an invalid argument was given.
There do exist Unix-like systems (not necessarily Linux) that
consider a zero count invalid.
Andries
> The man page is buggy if anything is.
Hmm. So far nobody pointed out anything buggy.
Now that I look myself I see outdated prototypes
(like int instead of ssize_t).
What else did you find buggy?
Andries
> > The man page is buggy if anything is.
>
> Hmm. So far nobody pointed out anything buggy.
> Now that I look myself I see outdated prototypes
> (like int instead of ssize_t).
> What else did you find buggy?
Specifying zero vectors is not an error in Linux (and not required to be
by SuSv3)
> The above ERRORS section says: In case this call returns EINVAL
> one of the possible reasons is that an invalid argument was given.
> There do exist Unix-like systems (not necessarily Linux) that
> consider a zero count invalid.
Got me as well - by that meaning you are correct - the man page is only
wrong for ssize_t type stuff.
Sorry
Alan