[Mpi3-rma] Target displacement sign issue

[Jeff Hammond]

Is it possible for implementations to prevent the user from attaching
memory to a dynamic window that would cause this overflow?  For
example, MPI_Win_attach could fail if the base+size indicated that
addresses could be used that were greater than the capacity of
MPI_Aint?  That seems like a way better option than breaking backwards
compatibility or attaching all sorts of caveats to the use of MPI_Aint
that a user is never going to remember.

Jeff

On Tue, Aug 28, 2012 at 10:00 AM, Jim Dinan <dinan at mcs.anl.gov> wrote:
> Sorry, this wasn't too clear.  A more detailed explanation of the problem
> is:
>
> Passing a dynamic window displacement to an RMA operation currently requires
> the user to put an address (which is an unsigned quantity) into an MPI_Aint
> (which is signed).  With the current spec, passing a negative displacement
> to an RMA operation is an error.  When interpreted as signed integers,
> dynamic window displacements (i.e. addresses) can be negative because the
> unsigned to signed conversion effectively overflows.
>
>  ~Jim.
>
>
> On 8/28/12 9:49 AM, Jeff Hammond wrote:
>>
>> I do not understand this:
>>
>> "displacements associated with dynamic windows are addresses
>> (unsigned) and can range into the space of negative integers"
>>
>> How can they "range into the space of negative integers" if they are
>> unsigned?
>>
>> Jeff
>>
>> On Tue, Aug 28, 2012 at 9:46 AM, Jim Dinan <dinan at mcs.anl.gov> wrote:
>>>
>>> Hi All,
>>>
>>> Currently, target displacements in put/get/acc/etc are defined to be
>>> non-negative integers of type, MPI_Aint.  MPI_Aint is defined to be a
>>> signed
>>> integer.  However, displacements associated with dynamic windows are
>>> addresses (unsigned) and can range into the space of negative integers.
>>>
>>> It seems like the least impact change would be to add a special case that
>>> the displacement argument will be interpreted as unsigned for dynamic
>>> windows.  Changing the interface to take an 'unsigned MPI_Aint' would be
>>> the
>>> most clear (and preserve the existing and intended new semantics), but
>>> would
>>> break backward compatibility.
>>>
>>> Interested to hear your thoughts.
>>>
>>>   ~Jim.
>
> _______________________________________________
> mpi3-rma mailing list
> mpi3-rma at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-rma



-- 
Jeff Hammond
Argonne Leadership Computing Facility
University of Chicago Computation Institute
jhammond at alcf.anl.gov / (630) 252-5381
http://www.linkedin.com/in/jeffhammond
https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond