Dick Treumann followed up:
>It seems the authors of xlc (the compiler I use) do not agree that this
>mismatch is only worthy of a warning. The following example produces a
>serious error on xlc.
>
>int foo( int*);
>
>int foo(const int *i) {}
>
>I understand the argument that it should be a warning but am not sure
>the ISO C standard supports the argument. Clearly,
>
>int foo(const int*);
>
>int foo(int *i){}
>
>should be a serious error and I did not find a place in the older ANSI
>document I have which distinguishes one redeclaration from the other.
Here is what I managed to extract from the ANSI C document. I also
took a quick look through summaries of the ISO addendum and corrigenda
to see if there were relevant changes. (My apologies to those trying
to correlate ISO section numbers with obsolete ANSI section numbers.)
Given:
a1. int foo( int * );
b1. int foo( const int *i ) {}
*or*
a2. int foo( const int *i);
b2. int foo( int *i ) {}
1. Both pairs of declarations are compatible. (ANSI 3.5.4.3)
[ Note especially regarding parameter type comparisons
in determining compatibility of function types:
"For each parameter declared with qualified type, its
type for these comparisons is the unqualified version of
its declared type."]
2. Since they are compatible, declaration a1(a2) is a legal
prototype for definition b1(b2). (ANSI 3.1.2.6)
*Assuming* I haven't made a mistake in reading 3.5.4.3, or missed some
additional relevant text in the standard, it looks like:
Given source code which uses a1 (a2) as a prototype for b1 (b2) and
does the appropriate casting, a compiler:
(i) shouldn't issue an error, since neither (a1,b1)
nor (a2,b2) violates a syntax rule or constraint
(ii) may issue a warning for one, both, or neither
of (a1,b1) and (a2,b2)
This agrees with Jim and disagrees with xlc.
-Ian
P.S. The above notwithstanding, if a program (say in foo or a
function called by foo) attempts to modify an object which
was declared "const int bar" and whose address was then
passed to foo, "the behavior is undefined". (ANSI 3.5.3)
You also aren't going to get much benefit from const-based
optimizations by writing this type of code.
-- Ian E. Stockdale MRJ Technology Solutions, NASA Ames Research Center ies@nas.nasa.gov (415) 604-4628