[Bug c/31887] bad warning converting qualified void* to qualified array pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31887 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- Invalid as qualifiers for arrays are not attached to the array type but rather to the element so there is no such thing as a const array.
[Bug c/31887] bad warning converting qualified void* to qualified array pointer
--- Comment #4 from bugs at 59A2 dot org 2008-11-17 12:24 --- There is no way to qualify an array type, but this sort of conversion is very useful. For instance, the optimizer produces better code for void foo(const double a[], int m, int n) { const double (*b)[n] = (const double(*)[n])a; /* use b[i][j] in inner loops */ } than when `a[i*n+j]' is used (without manually hoisting arithmetic out of inner loops). With -Wcast-qual, a warning is given since the qualifier does not apply to the array type, only the elements. Note that this example is very similar to the example given in http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf page 87 (physical page 94). Clearly the cast above should be possible, although there is no way to express it in a way that is compatible with C99 paragraph 6.7.3.8. I propose that -Wcast-qual promote qualifiers on array elements to the array itself when determining whether a cast discards qualifiers. That is, not warn for casts like the one above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31887
[Bug c/31887] bad warning converting qualified void* to qualified array pointer
--- Comment #3 from raeburn at raeburn dot org 2007-08-15 06:03 --- Section 6.7.3 says: If the specification of an array type includes any type qualifiers, the element type is so-qualified, not the array type. The more I think about it, the more I think the compiler is technically correct, though I think this is probably a bug in the standard. I brought this up on comp.std.c a couple weeks or so ago, though, and while Doug Gwyn, whose interpretation on these things I generally respect, seemed to indicate that my current interpretation is wrong (and that it should indeed be const array of 8 chars), he didn't provide references to that effect, so I'm not sure where that interpretation comes from. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31887
[Bug c/31887] bad warning converting qualified void* to qualified array pointer
--- Comment #2 from raeburn at raeburn dot org 2007-05-11 08:05 --- Subject: Re: bad warning converting qualified void* to qualified array pointer On May 10, 2007, at 19:00, pinskia at gcc dot gnu dot org wrote: I think only void* can be done with an implicat cast so we go from const void* to void* and then to const block*. ISO/IEC 9899-1999 section 6.5.16.1 (assignment constraints) includes: - one operand is a pointer to an object or incomplete type and the other is a pointer to a qualified or unqualified version of void, and the type pointed to by the left has all the qualifiers of the type pointed to by the right. So I'm pretty sure we don't automatically lose on the const-ness in the general case. What I'm less sure about is how the array type plays into it. According to 6.7.3, const block means array [8] of const unsigned char, so is there an argument to be made that assigning a pointer-to-const value to an lvalue of type pointer to an unqualified array type (containing a type that happens to be const- qualified) isn't allowed? I don't think it would be logical, but that doesn't guarantee that that's how the standard actually works. Ken -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31887
[Bug c/31887] bad warning converting qualified void* to qualified array pointer
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-05-11 00:00 --- I think only void* can be done with an implicat cast so we go from const void* to void* and then to const block*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31887