> Are you saying that a C99 compiler won’t complaint if the user passes a 64b int to a 32b int argument? That’s a pretty stupid compiler if you ask me.

It is perfectly valid in C *and* C++ to pass a 64bit integer value as an argument to a 32bit integer parameter. The 64bit integer value will be converted to 32bit integer and thus potentially truncated. Depending on the original value this may result in a negative or positive 32bit signed integer value so depending on the size you want to send, MPI_Send may or may not detect the overflow.

Passing a pointer to a 64bit integer (int64_t*) for a parameter that is a pointer to a 32bit integer (int32_t*) is a bit different. In C, this is still valid and the compiler will only issue a warning about the type mismatch. C++ handles types stricter and pointers are not implicitly converted.


> I’m fine with putting MPI C11 in separate header that can #error if C11 isn’t supported.

I don't have a strong opinion on this and I don't know if this (and the implications of introducing a new header file) has been discussed in the forum already. Maybe Jeff S has considered this already?

> In any case, we can’t design MPI around ignorant users who don’t read about features they’re using.

I'm not advocating to change the design, i.e., I'm not arguing against having C11 _Generic selectors. I just think it would be beneficial to clearly mark the potential caveat.

Joseph


On 8/2/19 7:19 AM, Jeff Hammond wrote:
Are you saying that a C99 compiler won’t complaint if the user passes a 64b int to a 32b int argument? That’s a pretty stupid compiler if you ask me.

I’m fine with putting MPI C11 in separate header that can #error if C11 isn’t supported. That’s a pretty obvious user experience win that costs nothing. We are basically doing that for Fortran already.

Maclaren can just skip C11 and teach MPI in Fortran 2008 or C99 with the _x symbols if the C11 is too scary.

In any case, we can’t design MPI around ignorant users who don’t read about features they’re using. Doing so makes it impossible to do anything at all because there’s always somebody too ignorant to use some feature correctly, and the union of the ignorance covers all nontrivial changes.

Jeff

On Thu, Aug 1, 2019 at 7:28 AM Joseph Schuchart via mpi-forum <mpi-forum@lists.mpi-forum.org <mailto:mpi-forum@lists.mpi-forum.org>> wrote:

    I think the point he wanted to make was that you won't see a
    compile-time error if you /think/ you're using the MPI_Count overloads
    but are in fact not, i.e., you are modernizing a legacy code base that
    is stuck in the nineties and you introduce MPI_Count for size arguments
    because the standard says you may do so now without a clear warning
    that
    this is only possible if you bump to C11. The compiler won't warn you,
    the MPI standard may mention it in a subsection somewhere, which of
    course you didn't read because you haven't had the time to read all ~1k
    pages of 4.0, yet. Having a clear note attached to listings that these
    overloads are constrained to C11 may help reduce the risk of
    introducing
    another caveat. MPI developers may be (more) familiar with the
    differences between C99 and C11 but the average developer of HPC
    software likely is not. And there are plenty of codes out there that
    constrain themselves to ancient language versions, for reasons unknown
    to me...

    Joseph

    On 8/1/19 12:56 PM, Jeff Hammond via mpi-forum wrote:
     > That’s why there will be C90/C99 compatible symbols as well. If
    you don’t like C11, don’t use it. Nothing will happen. BigCount will
    still work.
     >
     > C11 has been the default in GCC and Clang for a while. What
    compilers are going to limit users to C99 for years to come?
     >
     > Jeff
     >
     >> On Aug 1, 2019, at 3:23 AM, N.M. Maclaren via mpi-forum
    <mpi-forum@lists.mpi-forum.org
    <mailto:mpi-forum@lists.mpi-forum.org>> wrote:
     >>
     >>> On Jul 30 2019, Jeff Squyres (jsquyres) via mpi-forum wrote:
     >>>
     >>> B. C11 _Generic polymorphism kinda sucks, *and* we're in a
    transition period where not all C compilers are C11-capable. Hence,
    we're exposing up to *3* C bindings per MPI procedure to
    applications (including explicitly exposing the "_x" variant where
    relevant).
     >>
     >> This following point may have already been debated, so please
    excuse me if
     >> has.  Let's skip the politics, for the sake of all our blood
    pressures.
     >>
     >> The executive summary is that the failure mode pointed out by Joseph
     >> Schuchart is going to be a very, very serious problem for
    BigCount users,
     >> and continue for the forseeable future.  I would guess until at
    least
     >> 2025, and possibly long after that.
     >>
     >> Speaking as someone who may be teaching MPI programming again,
    with an
     >> emphasis on reliability and portability, I would almost
    certainly add
     >> warnings that would be, roughly: "Don't touch BigCount if you
    can find a
     >> way round it; and be paranoid about it if you use it."  I
    already do that
     >> about I/O attributes, for similar reasons.  That isn't good.
     >>
     >> I don't know how you would document that, but the MPI standard
    already
     >> has gotchas that aren't easy to find, and adding another one
    isn't good,
     >> either.
     >>
     >> The explanation:
     >>
     >> C99 was not received favourably by most of the C-using community
    (I don't
     >> mean compilers here).  I tracked a dozen important, active
    projects, and
     >> it was 2010/11 (yes, over a decade) before even half of them
    converted
     >> from C90 to C99 as a base.  I last checked a few years ago, but
    quite a
     >> few C99 features were still not reliably available in compilers;
    I know
     >> that many of the ones I found still aren't.  Courses are another
    problem,
     >> because they rarely include warnings about gotchas caused by
    standards
     >> differences (and there are lots between C90 and C99).
     >>
     >> I haven't tracked C11 as carefully, but the evidence I have seen
    is that it
     >> received even less interest and acceptance than C99, so people
    are going
     >> to be using C99 compilers for a LONG time yet.  There is also
    the problem
     >> that C is not a language that is upwards compatible between
    versions, but
     >> C++ takes more notice, so C++ compilers' C support (which is
    arguably more
     >> important than direct C support, because people call MPI using
    C++'s C
     >> interface) is often in conflict.  This is almost certainly a
    case where
     >> that will be true, but it may not affect these interfaces - I
    can't say.
     >>
     >> The result is that C code (and, worse, libraries) often require
    specific
     >> versions (i.e. not just 'any standard later than'). I agree that
    it looks
     >> likely that generic interfaces are going to be one of the more
    widely
     >> implemented parts of C99, but don't discount the problem of
    people using
     >> multiple libraries where other ones constrain the C version for
    other
     >> reasons.
     >>
     >> _______________________________________________
     >> mpi-forum mailing list
     >> mpi-forum@lists.mpi-forum.org <mailto: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 <mailto: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 <mailto:mpi-forum@lists.mpi-forum.org>
    https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

--
Jeff Hammond
jeff.scie...@gmail.com <mailto:jeff.scie...@gmail.com>
http://jeffhammond.github.io/
_______________________________________________
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

Reply via email to