readv() return and errno

readv() return and errno

[Jim Hollenback]

 In doing some testing on the project I'm working on I came
 across something that is causing a bit of confusion on my part.

 According to readv(2) EINVAL is returned for an invalid
 argument.  The examples given were count might be greater than
 MAX_IOVEC or zero. The test case I am working with has count = 0
 and I get return of 0 and errno 0 instead of the expected -1
 and errno EINVAL.

 Am I missing something?

Thanks!

Jim Hollenback

Re: readv() return and errno

[Alex Riesen]

On Fri, Mar 15, 2002 at 01:54:26PM -0800, Jim Hollenback wrote:
>  In doing some testing on the project I'm working on I came
>  across something that is causing a bit of confusion on my part.
> 
>  According to readv(2) EINVAL is returned for an invalid
>  argument.  The examples given were count might be greater than
>  MAX_IOVEC or zero. The test case I am working with has count = 0
>  and I get return of 0 and errno 0 instead of the expected -1
>  and errno EINVAL.
> 
>  Am I missing something?

http://www.opengroup.org/onlinepubs/007904975/
"The Open Group Base Specifications Issue 6", IEEE Std 1003.1-2001:

 The readv() function may fail if:

 [EINVAL]
 The iovcnt argument was less than or equal to 0, or greater than {IOV_MAX}.

Notice the "may"? From the same document:

 may

 Describes a feature or behavior that is optional for an implementation
 that conforms to IEEE Std 1003.1-2001. An application should not rely on
 the existence of the feature or behavior. An application that relies on
 such a feature or behavior cannot be assured to be portable across
 conforming implementations.

 To avoid ambiguity, the opposite of may is expressed as need not,
 instead of may not.
    
So the 0 there just mean nothing, exactly what you get.
 
-alex

Re: readv() return and errno

[Alan Cox]

> 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

Re: readv() return and errno

[Alan Cox]

> > 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)

Re: readv() return and errno

[Andries.Brouwer]

> 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

Re: readv() return and errno

[Andries.Brouwer]

    From jholly@cup.hp.com 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

Re: readv() return and errno

[Alan Cox]

> 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.

Re: readv() return and errno

[Jim Hollenback]

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
>
> --- Andries.Brouwer@cwi.nl 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

Re: readv() return and errno

[Balbir Singh]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 1877 bytes --]

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

--- Andries.Brouwer@cwi.nl 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/

Re: readv() return and errno

[Andries.Brouwer]

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

readv() return and errno

[Balbir Singh]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

You are right, the latest POSIX spec says

ERRORS
....
The readv() function may fail if:

[EINVAL]
The iovcnt argument was less than or equal to 0, or
greater than {IOV_MAX}

Apply this trivial patch, if you want the required
behaviour (see attached)

Balbir







List:     linux-kernel
Subject:  readv() return and errno
From:     "Jim Hollenback" <jholly@cup.hp.com>
Date:     2002-03-15 21:54:26
[Download message RAW]

In doing some testing on the project I'm working on I 
came across something that is causing a bit of 
confusion on my part.

According to readv(2) EINVAL is returned for an 
invalid  argument.  The examples given were count
might 
be greater than MAX_IOVEC or zero. The test case I am 
working with has count = 0 and I get return of 0 and 
errno 0 instead of the expected -1 and errno EINVAL.

Am I missing something?

Thanks!

Jim Hollenback

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

[-- Attachment #2: rw.patch.txt --]
[-- Type: text/plain, Size: 343 bytes --]

--- 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)