On Mar 3, 2011, at 3:30 PM, Fab Tillier wrote:

You forgot to fix 'lb'. Also, it needs to be a signed value so that sentinel values such as MPI_UNDEFINED can exist. So there. :P

--enable-picky

Having explicit 64-bit support might be a Big Deal to some implementations that don't care about large counts. One of the goals of abstracting the count is that it allows those who don't care to define MPI_Count as int, and just have the X functions weak symbols for the non-X functions.

Eh; I don't care about the weak symbol feature. I see your point about some MPI's not caring about 64 bit counts; they could just return MPI_UNDEFINED or somesuch...?

There's also precedent for variable width parameters such as size_t (and long in Linux) that also break ABI when the type changes size, but that hasn't been a problem - if anything it has allowed programs to be more portable rather than less.

How so?

Codes that use MPI_Count would have to recompile when the value of MPI_Count changes, but no source changes should be necessary.

The key word there being "should".

The whole issue of ABI is so much bigger than this (how do you handle string lengths, how do you handle pre-defined constants like MPI_COMM_WORLD, etc...) that MPI_Count changing size is really minor.

My point is that we shouldn't add one *more* thing that makes ABI difficult.

A recompile when moving from 64-bit to 128-bit is really going to be the least of people's problems.

That's not the issue here -- what if they just get an MPI that supports 128 bit filesystems (that already exist, BTW)? So it's not necessarily that the whole hardware is 128-bit capable, but rather some parts of their app may be able to use 128 bit support (although probably not in the near future). -- Jeff Squyres jsquyres_at_[hidden] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/