[Mpi-forum] Giving up on C11 _Generic

[Jim Dinan]

This example is a bit more representative of how we would use this to
implement the MPI bindings (renamed "bar" macro to "foo" and shifted down
to enable the name aliasing):

#include <stdio.h>



static void foo(int j) {

    printf("foo(j) = %d\n", j);

}


#define foo(j) foo(sizeof(j) > sizeof(int) ? -1 : j)


int main(int argc, char *argv[]) {

    /* 8589934592LL == 2^33 */

    long long i = 8589934592LL + 11;

    foo(i);

    return 0;

}

foo(j) = -1

 ~Jim.

On Wed, Aug 7, 2019 at 4:16 PM Jim Dinan <james.dinan at gmail.com> wrote:

> Jeff,
>
> You can wrap the function in a macro that checks for truncation:
>
> #include <stdio.h>
>
>
>
> #define bar(j) foo(sizeof(j) > sizeof(int) ? -1 : j)
>
>
> static void foo(int j) {
>
>     printf("foo(j) = %d\n", j);
>
> }
>
>
> int main(int argc, char *argv[]) {
>
>     /* 8589934592LL == 2^33 */
>
>     long long i = 8589934592LL + 11;
>
>     foo(i);
>
>     bar(i);
>
>     return 0;
>
> }
>
> foo(j) = 11
>
> foo(j) = -1
>
>  ~Jim.
>
> On Wed, Aug 7, 2019 at 9:59 AM Jeff Squyres (jsquyres) via mpi-forum <
> mpi-forum at lists.mpi-forum.org> wrote:
>
>> SHORT VERSION
>> =============
>>
>> Due to the possibility of silently introducing errors into user
>> applications, the BigCount WG no longer thinks that C11 _Generic is a good
>> idea.  We are therefore dropping that from our proposal.  The new proposal
>> will therefore essentially just be the addition of a bunch of
>> MPI_Count-enabled "_x" functions in C, combined with the addition of a
>> bunch of polymorphic MPI_Count-enabled interfaces in Fortran.
>>
>> MORE DETAIL
>> ===========
>>
>> Joseph Schuchart raised a very important point in a recent mailing
>> thread: the following C/C++ code does not raise a compiler warning:
>>
>> -----
>> #include <stdio.h>
>>
>> static void foo(int j) {
>>     printf("foo(j) = %d\n", j);
>> }
>>
>> int main(int argc, char *argv[]) {
>>     /* 8589934592LL == 2^33 */
>>     long long i = 8589934592LL + 11;
>>     foo(i);
>>     return 0;
>> }
>> -----
>>
>> If you compile and run this program on a commodity x86-64 platform, a)
>> you won't get a warning from the compiler, and b) you'll see "11" printed
>> out.  I tried with gcc 9 and clang 8 -- both with the C and C++ compilers.
>> I even tried with "-Wall -pedantic".  No warnings.
>>
>> This is because casting from a larger int type to a smaller int type is
>> perfectly valid C/C++.
>>
>> Because of this, there is a possibility that we could be silently
>> introducing errors into user applications.  Consider:
>>
>> 1. An application upgrades its "count" parameters to type MPI_Count for
>> all calls to MPI_Send.
>>    --> Recall that "MPI_Count" already exists in MPI-3.1, and is likely
>> of type (long long) on commodity x86-64 platforms
>> 2. The application then uses values in that "count" parameter that are
>> greater than 2^32.
>>
>> If the user's MPI implementation and compiler both support C11 _Generic,
>> everything is great.
>>
>> But if either the MPI implementation or the compiler do not support C11
>> _Generic, ***the "count" value will be silently truncated at run time***.
>>
>> This seems like a very bad idea, from a design standpoint.
>>
>> We have therefore come full circle: we are back to adding a bunch of "_x"
>> functions for C, and there will be no polymorphism (in C).  Sorry, folks.
>>
>> Note that Fortran does not have similar problems:
>>
>> 1. Fortran compilers have supported polymorphism for 20+ years
>> 2. Fortran does not automatically cast between INTEGER values of
>> different sizes
>>
>> After much debate, the BigCount WG has decided that C11 _Generic just
>> isn't worth it.  That's no reason to penalize Fortran, though.
>>
>> --
>> Jeff Squyres
>> jsquyres at cisco.com
>>
>> _______________________________________________
>> mpi-forum mailing list
>> mpi-forum at lists.mpi-forum.org
>> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpi-forum/attachments/20190807/9130d72e/attachment-0001.html>