<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Nov 17, 2008, at 9:54 AM, Eli Friedman wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; ">On Mon, Nov 17, 2008 at 9:49 AM, Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>> wrote:<br><blockquote type="cite">My question is whether or not Sema should insert an implicit cast here from<br></blockquote><blockquote type="cite">long long to int? It seems strange that there is an implicit cast from<br></blockquote><blockquote type="cite">short to int but not from long long to int.<br></blockquote><br>Actually, if I recall correctly, there isn't an implicit cast either<br>way for the case of array subscripting.</span></blockquote><div><br></div><div>Hi Eli,</div><div><br></div><div>I think too much of the original thread got lost. Your right that there is no implicit cast for array subscripting. We do insert implicit casts for pointer arithmetic. For example:</div><div><br></div><div><div>void f(int *p) {</div><div> short i = 0;</div><div> long long k = 0;</div><div><br></div><div> int x;</div><div> x = *(p + i); // implicit cast for 'i' from short to int</div><div> x += *(p + k); // no implicit cast for 'k' from long long to int</div><div> </div><div> return x;</div><div>}</div></div><div><br></div><div>The standard says that E1[E2] is the same as *(E1 + E2), so I was curious why there was no implicit cast from long long to int when doing pointer arithmetic. I also think that we should probably have an implicit cast when performing array indexing, but that's a separate matter from my original question.</div><div><br></div><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><br>The issue with inserting an implicit cast from long long to int is<br>that conceptually, it isn't there! The fact that we truncate long<br>long to i32 in CodeGen is really just an artifact of the<br>implementation on 32-bit machines.<br></span></blockquote></div><div><br></div><div>Regardless of Codegen, conceptually the types are changing. Even for the following code we insert an implicit cast from 'long' to 'int' even on a 32-bit machine:</div><div><br></div><div> long x = 0;</div><div> int y = x;</div><div><br></div><div>Obviously, in the case of a 64-bit machine the implicit cast becomes even more valuable since it implies a truncation during CodeGen.</div><div><br></div><div>For the array indexing (or rather pointer arithmetic), is it not the case that the 'long long' is being converted (always) to an integer with the same width as a pointer? Moreover, the sign of the integer type is changing. This seems like something that should be semantically captured in the ASTs.</div></body></html>