What should aio_fsync (O_SYNC, NULL) do?

[Mark Brown]

At 5:50 PM +0200 7/26/00, Andreas Jaeger wrote:
> >>>>> Mark Brown writes:
>
>Mark> At 3:45 PM +0200 7/26/00, Andreas Jaeger wrote:
>>> Uli,
>>>
>>> I'm enhancing rt/tst-aio.c to test also aio_fsync.  My Posix Standard
>>> mentions (1003.1, 1996 Edition) on page 181 for aio_fsync:
>>> "If aiocb is NULL, then no status is returned..."
>>>
>>> Currently aio_fsync (O_SYNC, NULL) gives a segmentation fault.  The
>>> current Austin Draft does not mention NULL anymore.  Shall I add the
>>> test for NULL or not?
>
>Mark> Andreas,
>
>Mark> Under the rules that will govern the AG book, you may continue to handle
>Mark> NULL as specified in the 1003.1-1996 book -- which I personally
>Something which I also don't understand is the semantics of a NULL.
>The 1003.1-1996 standard only allows NULL but didn't say what's
>happening.
>Mark> prefer to a core dump :) All that the omission (if intentional)
>Mark> means is that implementations can handle NULL as they see fit.
>Are you sure?  Normally NULL is not a valid parameter - but
>1003.1-1996 mentions it as valid parameter.

In AG Draft 1 the original POSIX text is there. We changed this in
Draft 2 to:

|If the control block referenced by aiocbp becomes an illegal
|address prior to asynchronous I/O completion, then the behavior
|is undefined.

This is because in general we feel that handling of bad pointers etc.
is not really germaine to a source API spec, so we let the implementation
decide how to deal with it.

I personally like something other than a core dump. But this text
relieves you of the requirement to test for NULL.

mark
-- 
-------------------------
Mark S. Brown                                                   bmark@us.ibm.com
IBM RS/6000 AIX System Architecture                    512.838.3926  T/L678.3926
IBM Corporation, Austin, Texas