Some points:

1. C11 _Generic support in an MPI implementation has to be optional, at least 
for now, because not all compilers support C11 _Generic (just like the F08 
bindings are still optional, and just like aspects of the C++ bindings were 
optional back in the '90s when C++ compilers still hadn't implemented all of 
the required features).

2. Given that an MPI implementation and/or compiler may or may not support 
MPI_Count-enabled C11 _Generic-style polymorphism for functions like MPI_Send, 
and given the defined behavior of the C/C++ language in terms of casting a 
large int down into a small int, it is quite possible that a valid MPI-4 
enabled application (i.e., using MPI_Count params with >2^32 values for 
functions like MPI_Send) with a valid MPI implementation can get truncated at 
run time.   **That is bad** (Dan's email exemplified this point)

--> Jeff Hammond has pointed out that there are some compiler flags (outside of 
-Wall) that can emit such warnings.
--> Jim Dinan has pointed out that implementations can add additional sizeof 
checks via macros. 

Fair points.  However, my response to both is: this is just making it hard for 
the average user to utilize the functionality correctly.  Sure, we can say 
"it's the users' fault", but the fact is that the language polymorphism 
mechanism itself is pretty weak and downright confusing (as a Forum, we've been 
discussing this for ***months*** -- how will average users/programmers to sort 
this stuff out?).

Let me ask a simple question: how will users to write portable MPI programs in 
C with large count values?

Answer: they will explicitly call MPI_Send_x(), and not rely on C11 _Generic.

Which then raises the question: what's the point of using C11 _Generic?  Its 
main functionality can lead to [potentially] silent run-time errors, and/or 
require additional error checking in every single code path by the 
implementation.  That just seems like bad design, IMNSHO.  That's why the WG 
decided to bring this to the Forum list (especially given the compressed 
timeframe for MPI-4).

> On Aug 8, 2019, at 7:37 AM, Jim Dinan via mpi-forum 
> <> wrote:
> In fairness, unsafe conversions are a feature of the C language, I assume 
> since very early on.  Assignment gets a pass to do horribly unsafe 
> conversions.  Unfortunately, when calling a function (with a prototype), the 
> argument expressions are converted as if by assignment, which is the 
> underlying cause for the truncation sadness.
>  ~Jim.
> On Thu, Aug 8, 2019 at 9:45 AM Jeff Hammond via mpi-forum 
> <> wrote:
> That you use code that does unsafe conversions really has nothing to do with 
> the business of the MPI Forum. 
> Again, if you think C89 is the best C, then use and teach that. No one here 
> is trying to make you use C11.
> Jeff
> > On Aug 8, 2019, at 5:56 AM, N.M. Maclaren via mpi-forum 
> > <> wrote:
> > 
> >> On Aug 7 2019, Jeff Hammond via mpi-forum wrote:
> >> 
> >> "silently truncated at run time" is trivially addressed with -Wconversion
> >> or -Wshorten-64-to-32.  The example program below is addressed by this.
> > 
> > Unfortunately, no.  While I have no trouble using such options on MY
> > code, I have frequently found them unusable on imported packages, because
> > of the flood of non-errors they generate.  For example, the following
> > code is both common and reasonable, and includes narrowing conversions:
> > 
> >   int i;
> >   i = sizeof(double);
> >   float x;
> >   x = 1.0;
> _______________________________________________
> mpi-forum mailing list
> _______________________________________________
> mpi-forum mailing list

Jeff Squyres

mpi-forum mailing list

Reply via email to