On Oct 11, 2011, at 10:33 AM, John McCall wrote:
> On Oct 11, 2011, at 10:02 AM, Jakob Stoklund Olesen wrote:
>> On Oct 11, 2011, at 8:30 AM, Douglas Gregor wrote:
>>> Alternatively, we could take returns_twice out of the type system entirely.
>>> Is there value in declaring a function pointer to a returns_twice function,
>>> and having that be a distinct type from a similar function pointer to any
>>> function? If not, then perhaps returns_twice should be just a declaration
>>> attribute, and not have any impact on the type system.
>>
>> The thought of calling vfork() through a function pointer is very scary
>> indeed, but the calling function needs to know that the called function may
>> return twice.
>>
>> The returns_twice attribute affects code generation in the caller, not in
>> the callee.
>>
>> I think that means it needs to be a type attribute.
>>
>> However, if we allow this:
>>
>> int (*fptr)(jmp_buf) = &setjmp;
>>
>> We lose the information anyway.
>
> Note that there *is* a subtyping relationship here: a normal function can be
> safely used as a returns_twice function (which simply never actually returns
> twice). But that's useless.
Yes, that's useless. And doing this properly in the type system means
forbidding the code above, which means that putting returns_twice into the type
system breaks currently-working code… for what?
> I agree that abstractly this ought to be a type attribute, and I don't think
> it would be difficult to take advantage of the current 'noreturn conversion'
> hooks to make the (unsafe) implicit conversion work, but I'm not sure there's
> any real value to adding this complexity.
I see added risk and added incompatibility with GCC, but no added value. I'd
prefer that this go in as a Decl-only attribute for now, and we can revisit
making it a type attribute down the road if we see any benefits.
- Doug
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
