From: "Supalov, Alexander" Date: January 9, 2008 8:26:23 AM CST To: Subject: RE: [mpi-21] Proposal EH2: add const keyword to the C bindings Reply-To: mpi-21@XXXXXXXXXXXXX Hi, Thanks. What I meant is that 1) There are different levels of ANSI standard compliance, and there may be applications that can be compiled only in non-ANSI mode. The MPI standard should not break them. 2) A change in one binding might reveal or worsen issues in other bindings, and even though these may indeed be other bindings' problems, we should not engineer for potentially increasing the pain. Best regards. Alexander -- Dr Alexander Supalov Intel GmbH Hermuelheimer Strasse 8a 50321 Bruehl, Germany Phone: +49 2232 209034 Mobile: +49 173 511 8735 Fax: +49 2232 209029 -----Original Message----- From: owner-mpi-21@XXXXXXXXXXXXX Behalf Of Dries Kimpe Sent: Wednesday, January 09, 2008 3:17 PM To: mpi-21@XXXXXXXXXXXXX Subject: Re: [mpi-21] Proposal EH2: add const keyword to the C bindings * Supalov, Alexander [2008-01-0912:14:03]: > Let's not forget that gcc is not the only C compiler to consider. > There's Intel, Microsoft, PGI, and some other popular compilers. I just took gcc as an example, assuming it is ANSI C compliant. I was actually wondering what the ANSI C standard says about this. The example should hold for any compiler if it is standard compliant. Personally, I think that any function call to a function of which the compiler doesn't have the full source (inline functions) means all bets are off. Even if all the parameters are const. There is no way for the compiler to prove that the function is not going to call another function which might have a pointer to your data. (Or just does pointer arithmetic and ends up touching your const data) [This is the famous C/C++ aliasing problem] ... unless you're using restricted pointers. As such, the const keyword doesn't change/optimize any of the emitted code (unless _all_ code is visible, and in that case the const keyword isn't needed to help the compiler see that the data is not modified) > And let's not forget that most Fortran bindings are built on top of C > ones. What will happen to the copy-in/out done by some Fortran 90+ > compilers if the underlying C binding uses const declaration for the > inner C call, I don't know. Maybe this should be viewed a problem for the fortran bindings? The C bindings cannot possibly consider all possible languages (such as python) building on top of them. (garbage collection issues, variables being movable in memory, ...) Another example of this is the fortran problem with functions using 2 or more datatype parameters... (cfr. the fortran strict type checking problem) Greetings, Dries Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm --------------------------------------------------------------------- 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.