<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Jan 28, 2011, at 12:39 AM, Abramo Bagnara wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Il 28/01/2011 04:06, John McCall ha scritto:<br><blockquote type="cite"><blockquote type="cite">Note that however also with current svn trunk we have a problem with<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">this test: the assignment x = y should be compiled without warning in<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">C++ *but* it's an assignment between incompatible pointers in C (clang<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">currently does not emit any warning on both C and C++).<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">It's not an assignment between incompatible pointers in C. y is a T*, where T = int[1]; converting that to the type of x (const T*) is a 6.3.2.3p2 pointer conversion.<br></blockquote><br>It seems you're definitely right.<br></div></blockquote><div><br></div><div>Hmm. Actually, I think I'm wrong. :) In C, array types are never qualified, only their element types; so while my argument is sound in principle, it's not actually following the specification.</div><div><br></div><div>That said, this is quite arguably a flaw in the specification, and it's been so argued in quite a few places, as mentioned and linked from here:</div><div> <a href="http://stackoverflow.com/questions/305293/constant-array-types-in-c-flaw-in-standard">http://stackoverflow.com/questions/305293/constant-array-types-in-c-flaw-in-standard</a></div><div>so we should probably add a -pedantic warning for this at least. I've file <a href="http://llvm.org/bugs/show_bug.cgi?id=9082">http://llvm.org/bugs/show_bug.cgi?id=9082</a> to track this.</div><br><blockquote type="cite"><div>The weird thing is that three independent implementation (GNU, Intel and<br>Comeau) get the same *wrong* result in C... I'm astonished, I wonder how<br>this might be happened.<br></div></blockquote><div><br></div>FWIW, Intel and Comeau aren't independent implementations; they're both EDG-based.</div><div><br></div><div><blockquote type="cite"><div><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">returns the wrong result, how is possible to get the right element type<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">e.g. using TypeVisitor?<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I hadn't really considered the effects this would have on people using<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">TypeVisitor on a canonical type. Mostly, I wasn't aware that that was at all<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">common. If it is, maybe we should change TypeVisitor.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I don't understand how this might be feasible: we enter<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">TypeVisitor::Visit with a Type* and as a consequence in the ArrayType<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">dispatcher we have already lost any info about qualifier that should be<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">applied to element type. The fact is that currently a canonical<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">ArrayType has not enough info to know the qualifiers of its element, I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">believe this is an unfortunate situation.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This would obviously have to be done at the level of TypeVisitor::Visit(QualType).<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">That brings up a good point, actually — Visit(const Type*) is already stripping qualifiers off of every other type, so I'm not sure why I'm supposed to be particularly bothered that it strips the qualifiers off array types.<br></blockquote><br>I believe the case is different here: for every other type the<br>qualifiers stripping is local and has no effect on inner types, for<br>arrays the qualifier stripping in array alter the interpretation of<br>inner nodes (I think that RecursiveASTVisitor will suffer of this).<br></div></blockquote><div><br></div>That's true.</div><div><br><blockquote type="cite"><div>However I think that we will proceed changing our visitors to save the<br>array qualifiers for later reapplication to element type.<br></div></blockquote></div><br><div>Thank you. I'm sorry to keep changing the AST out from under you; we really do think this is the right technical design.</div><div><br></div><div>John.</div></body></html>