RE: [mpi-21] Proposal EH2: add const keyword to the C bindings

["Supalov, Alexander" <alexander.supalov@xxxxxxxxx>]

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 [mailto:owner-mpi-21@xxxxxxxxxxxxx] On
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 <alexander.supalov@xxxxxxxxx> [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

---------------------------------------------------------------------
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.