<div dir="ltr">I'm not especially happy with using CK_BitCast for something other than a bit cast -- that seems basically wrong to me. There's also a language design question here. If I have two pointers to different address spaces that happen to be the same bit-width, and I write:<div>
<br></div><div>  typedef int *p1 __attribute__((address_space(1)));</div><div>  typedef int *p2 __attribute__((address_space(2)));<br></div><div><br></div><div>  p2 f(p1 p) { return static_cast<p2>(p1); }</div><div>
  p2 g(p1 p) { return reinterpret_cast<p2>(p1); }</div><div><br></div><div>... I would probably expect 'f' to return me a pointer to the same memory (with potentially a different value) if that's possible, and to be an error if it's not possible. I would probably expect 'g' to return me a bitcasted pointer. That too suggests that we can't steal CK_BitCast to mean "do something other than a bitcast".</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 26, 2013 at 8:34 AM, David Tweed <span dir="ltr"><<a href="mailto:david.tweed@gmail.com" target="_blank">david.tweed@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
  Regarding your response, that seems reasonable. I guess it's up to the "address spaces for security" guys to validate clang's semantic checking with respect to their needs. (I'd been thinking about devious things like somehow creating an one of those pointer types and using it to put the "evasion of the security sandboxing" into the generated LLVM IR, but that's for the more security knowledgeable to deal with.)<br>

<br>
<a href="http://llvm-reviews.chandlerc.com/D2241" target="_blank">http://llvm-reviews.chandlerc.com/D2241</a><br>
</blockquote></div><br></div>