<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 19, 2008, at 3:09 PM, Fariborz Jahanian wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><br>Ran into this issue when looking at encoding of methods:<br><br>@interface Test<br>-(id) test3: (Test [3][4])b;<br>@end<br><br>@implementation Test<br>-(id) test3: (Test [3][4])b { }<br>@end<br><br><br>We do type-decay on arrays too early. So, encoding of the method type is not<br>same as gcc's. I also saw this note in clang:<br><br>// Perform the default function/array conversion (C99 6.7.5.3p[7,8]).<br> // Doing the promotion here has a win and a loss. The win is the type for<br> // both Decl's and DeclRefExpr's will match (a convenient invariant for the<br> // code generator). The loss is the orginal type isn't preserved. For example:<br> //<br> // void func(int parmvardecl[5]) { // convert "int [5]" to "int *"<br> // int blockvardecl[5];<br> // sizeof(parmvardecl); // size == 4<br> // sizeof(blockvardecl); // size == 20<br> // }<br> //<br> // For expressions, all implicit conversions are captured using the<br> // ImplicitCastExpr AST node (we have no such mechanism for Decl's).<br> //<br> // FIXME: If a source translation tool needs to see the original type, then<br> // we need to consider storing both types (in ParmVarDecl)...<br> //<br><br></div></blockquote><div><br></div>Yep, that's my comment/FIXME.</div><div><br><blockquote type="cite"><div>Should we do what FIXME suggests (for objc method params only). Or should we<br>do type-decay lazily. latter saves us a slot at the expense of more wide-spread change.<br>My preference is for the FIXME approach. But I know how sensitive we are to adding a<br>slot to AST node. :).<br><br></div></blockquote><div><br></div>Ah yes, GCC's wasteful tree nodes caused me extreme trauma as a young lad:-)</div><div><br></div><div>As you say, my preference is for the lazy approach. When I wrote this code, I was clearly too "lazy" to do it. Without some research, it's hard for me to estimate the difficulty. Since I didn't really need to original type, I simply added the FIXME.</div><div><br></div><div>A variation on the FIXME is to have a subclass of ParmVarDecl (e.g. ObjCParmVarDecl) that contains the original type (to support method encoding). This is still wasteful, however the waste is isolated to ObjC. Note that C++ is already wasting space (with the DefaultArg slot). Conceptually, I like the idea of having ObjC and C++ subclasses of ParmVarDecl. </div><div><br></div><div>What do you think?</div><div><br></div><div>snaroff</div><div><br></div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font></div><div>- Fariborz<br><br></div></blockquote></div><br></body></html>