From: Dries Kimpe Date: January 9, 2008 8:16:38 AM CST To: mpi-21@XXXXXXXXXXXXX Subject: Re: [mpi-21] Proposal EH2: add const keyword to the C bindings Reply-To: mpi-21@XXXXXXXXXXXXX * Supalov, Alexander [2008-01-09 12: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