[Bug c/16602] Spurious warnings about pointer to array -> const pointer to array conversion

2010-03-11 Thread ilatypov at infradead dot org


--- Comment #9 from ilatypov at infradead dot org  2010-03-12 03:49 ---
(In reply to comment #7)
> I am reopening the bug cause I still don't have a clue why "pointer to array 
> of
> ints" typed expression is assignment incompatible with a "pointer to array of
> const ints" typed lvalue. Especially when "pointer to int" typed expression IS
> assignment compatible with "pointer to const int" typed lvalue. This is what 
> is
> this bug all about.

Comment #9 to bug 33076 showed me a link explaining how constness of a multiply
referenced value cannot be promised, and, therefore, C propagates the compile
-time constness requirement up the assignment chain in cases where the level of
pointer indirection is greater than 1.  

  http://c-faq.com/ansi/constmismatch.html

I came up with a similar example for the "array of const ints".   It shows that
the const promise might have been violated inside the function if
multiply-indirected lvalue constness was relaxed.

typedef const int carr_t[8];
typedef int arr_t[8];

void foo(carr_t *carrp) {
arr_t *hacker;
carr_t **holder = &hacker;  // a warning

(*holder) = carrp;  // "hacker = carrp" in disguise, but both sides are
(carr_t *)

(*hacker)[ 0 ] = 9; // no warning
}

void bar(void) {
arr_t arr = { 1, 2, 3, 4, 5, 6, 7, 8 };
foo(arr);   // a warning
}


-- 

ilatypov at infradead dot org changed:

   What|Removed |Added
------------
 CC|        |ilatypov at infradead dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16602



[Bug c/16602] Spurious warnings about pointer to array -> const pointer to array conversion

2010-03-15 Thread ilatypov at infradead dot org


--- Comment #10 from ilatypov at infradead dot org  2010-03-15 19:47 ---
(In reply to comment #9)
> constness of a multiply
> referenced value cannot be promised, and, therefore, C propagates the compile
> -time constness requirement up the assignment chain in cases where the level 
> of
> pointer indirection is greater than 1.  

The specs mention this case, too.

  Constraints

 1 One of the following shall hold:99)

   [..]

   - both operands are pointers to qualified or unqualified versions of
compatible types, and the type pointed to by the left has all the qualifiers of
the type pointed to by the right;


 [..]

 6 EXAMPLE 3 Consider the fragment:

   const char **cpp;
   char *p;
   const char c = 'A';

   cpp = &p; // constraint violation
   *cpp = &c; // valid
   *p = 0; // valid

   The first assignment is unsafe because it would allow the following valid
code to attempt to change the value of the const object c.

from section 6.5.16.1 "Simple assignment", n1336.pdf,

http://www.open-std.org/jtc1/sc22/wg14/www/projects


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16602