The Linux man-page for aio_write says
The buffer area being written out must not be accessed during the operation or undefined results may occur.
My emphasis on "accessed", which strictly interpreted is not only stores to the buffer, but also loads from the buffer.
The man-page on Mac OS X says
Modifications of the Asynchronous I/O Control Block structure or the buffer contents after the request has been enqueued, but before the request has completed, are not allowed.
This sounds slightly more reasonable; the buffer can be read from, but not modified. The consequences of a violation are still left vague, though.
Thinking about how this might be implemented in the OS, I can't why a read access would ever be a problem, and the only problem I can imagine from a concurrent write would be that the actual data written could be some arbitrary mix of the initial buffer contents and the concurrent stores to the buffer.
Undefined behaviour opens up a lot of possibilities, however, and with that in mind we could get SIGSEGV on access (the underlying page was locked to prevent concurrent access?), or reads could return garbage data (the file system does in-place encryption or compression?), or the file could be left with permanently unreadable blocks (block checksummed, then modified concurrently, then written out?). Undefined behaviour does not even exclude crashing the storage device firmware, or the OS.
My question is, what could actually, reasonably happen, given the systems and hardware we have? I assume the language is left intentionally vague to not constrain future implementations.
Linux, BSD (MacOS is a BSD flavour), POSIX say different things.
POSIX says:
For any system action that changes the process memory space while an asynchronous I/O is outstanding to the address range being changed, the result of that action is undefined.
Linux manual seems more restrictive, two possibilites:
BSD also says:
If the request is successfully enqueued, the value of iocb-_aio_offset can be modified during the request as context, so this value must not be referenced after the request is enqueued
thus explicitly forbids some read accesses (to the control structure).
As Martin said in comment: I don't know why anyone would want to access the structs/buffers/s before I/O completion is notified. But it is also too restrictive: ok, that is clear for write access, but one can imagine (while not common) a scenario where you want read access to the buffer during the IO (writing a framebuffer content while displaying it - or alike).
Whatever, if you violate the restrictions anything bad may happen, so don't violate them.