checking if 8769 covers everything regarding partial datatypes

[markalle]

@bosilca recently made
#8769
and I'm not yet sure it's handling everything with the partial datatypes.

It's also possible I'm misusing the calls, so this is a bug report for continued investigation/discussion.

I made a testcase below that's based off the partial.c that George checked in. In unpacks 3 ints a few different ways and doesn't always get the right results.

Testcase: https://gist.github.com/markalle/eb0e67c5135c63c1ceac857de1ae3202

% cd test/datatype
% cp partial2.c partial.c
% rm -f partial
% make partial
% mpirun -np 1 ./partial

[markalle]

Update: my first gist had a bug (at iov[0].iov_base = packed + length) and it works fine now with the pointer math there fixed to use (char*).

But the reason I was making that test is I wanted to test big-endian to make it do a conversion, so I've made that test here:
https://gist.github.com/markalle/ac88752093058857d98d7441a466e65b

Is the above expected to work?

[markalle]

@bosilca Thoughts on this not appearing to work when the endianness is forcing conversions to be needed? Would opal_convertor_unpack() only be used in this partial-datatype + needing conversion method for messaging between heterogeneous ranks? If so then that wouldn't be real high priority for me. But I don't know if that's the context where the above path would happen

[gpaulsen]

@markalle What should we do with this Issue? Can we close it, or is it a problem?

[github-actions]

It looks like this issue is expecting a response, but hasn't gotten one yet. If there are no responses in the next 2 weeks, we'll assume that the issue has been abandoned and will close it.

[github-actions]

Per the above comment, it has been a month with no reply on this issue. It looks like this issue has been abandoned.

I'm going to close this issue. If I'm wrong and this issue is not abandoned, please feel free to re-open it. Thank you!