"valid object" preconditions

[Dan Bonachea]

Preconditions for rput/rget in Ch 6 currently include wording like:

1180 Precondition: T must be Serializable. dest must be a pointer to valid memory.
...
1187 Precondition: T must be Serializable. src and dest must be pointers to valid
1188 memory. The memory referenced by the intervals [src, src+count) and
1189 [dest, dest+count) must not overlap.

The phrase "valid memory" is not defined anywhere in this document or by C++11.

I think instead we probably want to say something like "dest is a pointer to an object of type T". In particular, this implies not only that dest is non-NULL, but also that it is properly aligned to contain an object of type T.

Functions that take an array should probably specify that [src,src+count) all point to array elements of type T (ie that you didn't overflow the array).

[Dan Bonachea]

This also applies to rput_then_rpc, which currently lacks this precondition entirely

[Former user]

Here's what I'm going to spec about address validity:

• For rput/rget of a single value: "references a valid object of type T".
• For rput/rget of multiple values: "addresses in intervals [src,src+n) and [dst,dst+n) must reference valid objects of type T". In the case of n=0 this permits src,dst to be anything
• For rput_then_rpc: "addresses in [src,src+n) and [dst,dst+n) reference valid T objects, and either dst or dst-1 must point to a valid T object"

[Dan Bonachea]

We now have preconditions of the form:

rput: "dest must reference a valid object of type T."
rget: "src must reference a valid object of type T."

The phrase "valid object" is an improvement over "valid memory", but I suspect it's still the wrong phrase for us to be using. In particular, we should not be requiring anything about the "before" contents of RMA destination memory (which in many important cases is uninitialized storage). Further, now that we've removed serialization from RMA and specified they only byte-copy, all that we actually require is that the pointers themselves are "valid", as in non-null and referencing live storage that is correctly aligned to hold an object of type T. RMA doesn't care at all about the "validity" of the object representation stored in that memory (source or dest).

The "valid object" phrase only appears twice in the entire C++17 spec, once when specifying that references may not be bound to null pointers, and the second in a random (somewhat informal) note. It only appears once in the C11 spec, when referring to trap representations.

Can we come up with a better way to state this aspect of the preconditions on memory regions to RMA, VIS and data movement collectives? (I'm more comfortable leaving it on atomics and computational collectives where we actually do computation on the contents of the objects).

Pull request #11 is tangentially relevant.

The "solution" here may just be to refer to some "common requirements" section in the C++ library spec that also applies to functions in our library. Eg C11 7.1.4 has this text, that applies to all library functions in the C spec unless otherwise noted:

If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined. If a function argument is described as being an array, the pointer actually passed to the function shall have a value such that all address computations and accesses to objects (that would be valid if the pointer did point to the first element of such an array) are in fact valid.

The C++ [res.on.arguments] section has similar text we could reference.

[Amir Kamil]

Merged in d57cd44.