[Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A
Supalov, Alexander
alexander.supalov at [hidden]
Fri Aug 7 06:43:52 CDT 2009
Dear Brian,
Thanks. I understood Bill's email as a request to report all possible issues with backward compatibility. Hence the reference to the attributes.
Best regards.
Alexander
-----Original Message-----
From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Barrett, Brian W
Sent: Thursday, August 06, 2009 5:57 PM
To: MPI 2.2
Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A
Alexander -
I'm not sure why you had to hijack a thread on a possibly valid issue with
MPI 2.2 by bringing up a completely different issue, but I believe it
seriously distracts from an important discussion.
However, to answer your complaint regarding ticket #55, Bill was quite
specific: "making previously valid (and unambiguous) MPI 2.1 programs
invalid". Yes, the changes in #55 will make any codes which followed the
examples instead of the text more clearly invalid, but they were invalid
already as the examples are not part of the official standard language.
Further, given the ambiguity (meaning the standards committee had multiple
very long discussions about what the standard currently met) in the
difference between deprecated and new Fortran functions, it would be nearly
impossible to claim that that existing codes met the unambiguous threshold.
Finally, the meaning of the standards text did not change, but was clarified
to make its existing meaning more clear, as seen by the long thread between
Rajeev, Rolf, and Jeff on existing text vs. new text.
So although the change may cause compatibility problems with incorrectly
written applications, the Forum handled ticket #55 properly. If you
disagreed with specific parts of the text, the 10 months of discussion over
the text was the proper time for constructive comments. The relentless
attack on tickets you don't like, even after tickets have passed vote with
clearly correct procedures, is rather distracting from real issues.
Brian
On 8/6/09 4:52 AM, "Supalov, Alexander" <alexander.supalov_at_[hidden]> wrote:
> Hi,
>
> The passed inter-language attribute changes (#55) do break existing programs
> according to our investigation.
>
> Best regards.
>
> Alexander
>
> -----Original Message-----
> From: mpi-22-bounces_at_[hidden]
> [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp
> Sent: Thursday, August 06, 2009 2:42 AM
> To: MPI 2.2
> Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in
> Appendix A
>
> In terms of what we can do with this, only if the ticket was out of
> scope can it be withdrawn. That is, if it violates the rules for
> valid MPI 2.2 items by, for example, making previously valid (and
> unambiguous) MPI 2.1 programs invalid. If we discover something like
> that, we'll probably need to delay the standard. I don't believe
> we've reached that threshold yet.
>
> Bill
>
> On Aug 4, 2009, at 12:21 PM, Erez Haba wrote:
>
>> I agree David, and as I said, it might be nitpicking :)
>>
>> Most compliers would probably optimize the cast out (Microsoft
>> compiler sure does); however the question still remains; do
>> implementers have to change the definition of their constant
>> variables to meet this table?
>>
>>
>> As for the second item, the point I'm making is that adding the
>> 'const' qualifier for the types in the tables does not help clarity
>> and it does quite the opposite. Would adding 'const' to
>> MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps?
>>
>> Which brings me to my third note which is, the use of 'const' in
>> these tables is not consistent. Some types get the const modifiers
>> and some do not.
>>
>>
>> David, per your comment below, and to the audience, please note that
>> this ticket is not just a trivial text change to the standard, as it
>> introduces types for constants that were not assigned in the
>> standard before.
>> As you said below David, adding 'const' makes them non-lvalue for
>> the specific C binding.
>>
>>
>> I know that this ticket has passed 2nd vote, imho, wrongly without
>> giving enough consideration to its content; as it was introduced as
>> text only change. See the large number of abstains (including me).
>> However it's up to us to decide. I don't know what the rules say,
>> and if there is a way to take back this ticket without taking the
>> entire chapter out.
>>
>> Thoughts??
>>
>> Thanks,
>> .Erez
>>
>> -----Original Message-----
>> From: mpi-22-bounces_at_[hidden]
>> [mailto:mpi-22-bounces_at_[hidden]
>> ] On Behalf Of Dave Goodell
>> Sent: Monday, August 03, 2009 2:00 PM
>> To: MPI 2.2
>> Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined
>> constants in Appendix A
>>
>> On Aug 3, 2009, at 12:36 PM, Erez Haba wrote:
>>
>>> This might be nitpicking but wouldn't that force implementation to
>>> typecast their definition of error codes? For example,
>>>
>>> #define MPI_ERR_BUFFER 0
>>>
>>> Is not a correct definition with the proposed change, because it is
>>> not typed.
>>
>> I think that the "Constants with the type const int may also be
>> implemented as literal integer constants substituted by the
>> preprocessor" bit on lines 23-24 helps implementors realize that they
>> don't need to insert a cast here. Also, the type of the integer
>> constant 0 is typed as the first integer type in {int, long int, long
>> long int} that can express the value, which is required to be int in
>> this particular case.
>>
>>> Thus, it needs to change to
>>>
>>> #define MPI_ERR_BUFFER (int)0 // you don't really need to define
>>> it as (const int)0
>>>
>>> as a result the following statement
>>>
>>> short x = MPI_ERR_BUFFER;
>>>
>>> which compiled correctly before, would break with this change.
>>
>> To the best of my knowledge this is still perfectly legitimate C.
>> Section 6.5.16.1 of my copy of the C99 standard seems to corroborate
>> this:
>>
>> -------8<--------
>> Semantics
>>
>> 2 In simple assignment (=), the value of the right operand is
>> converted to the type of the assignment expression and replaces the
>> value stored in the object designated by the left operand.
>> -------8<--------
>>
>> GCC doesn't give a warning for this assignment, even when you add a
>> bunch of warning flags. It does warn if the value is something too
>> large for the short type (like 0xdeadbeef), although of course only
>> for direct assignments like this when the compiler still knows the
>> origin of the value. Does the Microsoft compiler behave differently?
>>
>>> Second comment.
>>>
>>> Adding the 'const' modifier to all types is very confusing imho. I
>>> understand that it meant to make it clear that the values are
>>> constants and should not change, but still is very confusing.
>>>
>>> For example,
>>>
>>> C Type: void * const
>>> MPI_BOTTOM
>>>
>>> This means that the value of MPI_BOTTOM is constant and not the
>>> memory it points to. however at first look you might think that it's
>>> the later. (if it was, it would break any application that uses it
>>> because the API's do not take a pointer to const void)
>>
>> I'm not sure that there's a lot we can do if people can't properly
>> read cv-qualified C types. This is a standards document, not a
>> tutorial. I don't think that this is intentionally misleading or
>> difficult to read.
>>
>>> In any case implementers should define MPI_BOTTOM as
>>>
>>> #define MPI_BOTTOM (void*)0
>>>
>>> Rather than
>>>
>>> #define MPI_BOTTOM (void* const)0
>>>
>>> As the value is constant and you don't need to add the const
>>> modifier.
>>
>> The reason you don't really need the const here is that casts create
>> rvalues. So it has the same effect as a cast to the unqualified type.
>> This, combined with the constant initializer rule in MPI-2.1 section
>> 2.5.4, is one reason that choosing "const int" as the type for these
>> constants is debatable.
>>
>>> Note that the 'constness' of these values is already stated in the
>>> title of the section '19.1.1 Defined Constants'
>>
>> I don't agree. The semantic constness of these constants is implied
>> by the title, but not the specific language implementation constness.
>> In the standard we could say "X, Y, and Z are constants (their values
>> never change) with the exact type `int'". Depending on the exact uses
>> with the rest of the API this would be perfectly valid, although we
>> might lose some error checking assistance from C compilers.
>>
>> The title together with MPI-2.1 section 2.5.4 indicates that most of
>> these are compile-time constants that may be used for initialization,
>> so you could say that the constness doesn't matter since these may
>> never be stored in link-time constant variables. However using
>> "const" as a way of indicating that these constants are "non-
>> lvalue" (and in particular, "non-(modifiable lvalue)") is fine by me.
>>
>> -Dave
>>
>> _______________________________________________
>> mpi-22 mailing list
>> mpi-22_at_[hidden]
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>>
>>
>> _______________________________________________
>> mpi-22 mailing list
>> mpi-22_at_[hidden]
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>
> William Gropp
> Deputy Director for Research
> Institute for Advanced Computing Applications and Technologies
> Paul and Cynthia Saylor Professor of Computer Science
> University of Illinois Urbana-Champaign
>
>
>
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
> ---------------------------------------------------------------------
> Intel GmbH
> Dornacher Strasse 1
> 85622 Feldkirchen/Muenchen Germany
> Sitz der Gesellschaft: Feldkirchen bei Muenchen
> Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
> Registergericht: Muenchen HRB 47456 Ust.-IdNr.
> VAT Registration No.: DE129385895
> Citibank Frankfurt (BLZ 502 109 00) 600119052
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> _______________________________________________
> mpi-22 mailing list
> mpi-22_at_[hidden]
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
>
_______________________________________________
mpi-22 mailing list
mpi-22_at_[hidden]
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22
---------------------------------------------------------------------
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen Germany
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer
Registergericht: Muenchen HRB 47456 Ust.-IdNr.
VAT Registration No.: DE129385895
Citibank Frankfurt (BLZ 502 109 00) 600119052
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
More information about the Mpi-22
mailing list