<div dir="ltr">On Mon, May 13, 2013 at 9:08 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, May 13, 2013 at 9:05 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>

> On Mon, May 13, 2013 at 5:59 PM, Aaron Ballman <<a href="mailto:aaron@aaronballman.com">aaron@aaronballman.com</a>><br>
> wrote:<br>
>><br>
>> On Mon, May 13, 2013 at 8:51 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>><br>
>> wrote:<br>
>> > You have ''__foo'' in some of your diagnostics. These should only use a<br>
>> > single level of quotes.<br>
>><br>
>> The quotes were used for consistency with other diagnostics involving<br>
>> attributes.  I'll look into it again though.<br>
>><br>
>> > Should these really be handled as declaration attributes? They look like<br>
>> > they would more naturally be type attributes. Can you do this:<br>
>> ><br>
>> >   void * __sptr * __uptr p;<br>
>><br>
>> I think eventually they (along with __ptr32 and __ptr64) will have to<br>
>> move over to ExtQuals (or somewhere near there) because they're really<br>
>> type qualifers more than declaration attributes.  But I was modeling<br>
>> after existing constructs.  And yes, you can do that, though it's<br>
>> basically pointless because there's not a __ptrXX involved.  But you<br>
>> are correct, this really highlights that __ptrXX and __sptr/__uptr<br>
>> need to move to types instead of declarations.<br>
>><br>
>> Do you think ExtQuals would be an appropriate place, or do you have a<br>
>> better suggestion?<br>
><br>
><br>
> ExtQuals (or rather, Qualifiers) does not have any spare bits. Do these<br>
> qualifiers affect the canonical type? That is, can you overload on this?<br>
> Does MSVC accept this:<br>
><br>
> void f(int * __uptr __ptr32 * p) {}<br>
> void f(int * __sptr __ptr32 * p) {}<br>
<br>
</div></div>You cannot -- same with __ptr32 vs __ptr64</blockquote><div><br></div><div style>Huh.  I would've expected that to work since they bothered to have a separate mangling for ptr64.  But I see the same behavior.</div>
</div></div></div>