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 > <mpi-forum@lists.mpi-forum.org> 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 > <mpi-forum@lists.mpi-forum.org> 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 > > <mpi-forum@lists.mpi-forum.org> 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@lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > _______________________________________________ > mpi-forum mailing list > mpi-forum@lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum -- Jeff Squyres jsquy...@cisco.com _______________________________________________ mpi-forum mailing list mpi-forum@lists.mpi-forum.org https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
