aio_error/3-1.c

Quoted 22 lines

I've been reading POSIX documentation for some time now and even reading glibc source code and the result is that aio_error/3-1.c doesn't test anyting and should be removed.

The test is trying to assert EINVAL from aio_error accordingly to:

http://www.opengroup.org/onlinepubs/009695399/functions/aio_error.html

...

The aio_error() function may fail if:

       [EINVAL]
           The aiocbp argument does not refer to an asynchronous operation whose return status has not yet been retrieved.

...

As far as I understand this, it's says you may get EINVAL if you call aio_error() on finished aiocb second (and more) times.

Quoted 2 lines

This is implemented on linux as "return aiocb->__error_code" so IMHO there is no way to test this.

I think that the original developers misinterpreted the test
requirements. aio_error is _always_ supposed to return errno values, not -1 and set the global errno. Otherwise it wouldn't make sense because asynchronous I/O would be more synchronous than anything else.

Quoted 83 lines

Quoted 83 lines

Quoted 22 lines

Quoted 22 lines

I've been reading POSIX documentation for some time now and even reading glibc source code and the result is that aio_error/3-1.c doesn't test anyting and should be removed.

The test is trying to assert EINVAL from aio_error accordingly to:

http://www.opengroup.org/onlinepubs/009695399/functions/aio_error.html

...

The aio_error() function may fail if:

       [EINVAL]
           The aiocbp argument does not refer to an asynchronous operation whose return status has not yet been retrieved.

...

As far as I understand this, it's says you may get EINVAL if you call aio_error() on finished aiocb second (and more) times.

Quoted 7 lines

Quoted 2 lines

This is implemented on linux as "return aiocb->__error_code" so IMHO there is no way to test this.

    I think that the original developers misinterpreted the test requirements. aio_error is _always_ supposed to return errno values, not -1 and set the global errno. Otherwise it wouldn't make sense because asynchronous I/O would be more synchronous than anything else.

This is not the only problem here. Accordinly to POSIX aio_error() output is defined only when you pass correct aiocb (that means struct aiocb that is already used for some aio_{write,read,fsync,...}) and the value may not be stored pernamently, so if you read it once, it could return EINVAL second time.

...

memset (&aiocb, 0, sizeof (struct aiocb));

aiocb.aio_fildes = fd;
aiocb.aio_buf = buf;
aiocb.aio_reqprio = -1;
aiocb.aio_nbytes = BUF_SIZE;

/*
 * Here return from aio_error() is not defined as
 * there was no aio operation done on aiocb.
 *
 * On linux you get value that is stored in struct aiocb->__error_code
 * and as aiocb is filled with zeroes on the beginning, this
 * returns also zero.
 */
ret = aio_error(&aiocb);

if (aio_write(&aiocb) == -1) {
       /* quening write operation has failed */
       return 1;
}

/*
 * Wait for completion.
 */
while ((ret = aio_error(&aiocb)) == EINPROGRESS)
       sleep(1);

/* Here we have status from aio_write in ret */

/*
 * And here we may get EINVAL instead of status from previous
 * aio_write()
 */
ret = aio_error(&aiocb);

So what I'm saying is that if you really want to write correct test for 3-1.c you need to:

1. Create aio data transfer
2. Wait for completion
3. Get aio return status by aio_error()
4. Get it once more and it should either be EINVAL or same value that you got first time.

Quoted 5 lines

Quoted 1 line

Which seems to be a little dumb to test to me, so I vote for removing 3-1.c from ltp.

   I'll do some comparison with other existing testcases, as well as look at the requirements for 3-1 further tonight -- but my initial look at your argument seems sound.

Looking at the tort again in SUSv4, the logic that you're arguing
seems incorrect:

The aio_error() function may fail if:

[EINVAL]
The aiocbp argument does not refer to an asynchronous
operation whose return status has not yet been retrieved.

It's pretty blatant that EINVAL should apply to aio_error when
aiocbp is passed in which doesn't point to a valid file descriptor linked to some sort of aio operation. If Linux is improperly caching the aio_error, then Linux needs to be corrected to meet the POSIX requirements if the test is supposed to pass and the behavior isn't already documented in the OS specific documentation (manpages, whatever). Same thing applies for all OSes trying to meet the golden POSIX standard.
The ERROR clause's wording is lousy though, so I'll bring this up
with opengroup.

I'll have it returned PTS_UNRESOLVED instead of PTS_FAIL instead.