[cfe-commits] [PATCH] Treat "int (^x)()" as "int (^x)(void)" instead of a K&R style prototype

[Douglas Gregor]

On May 31, 2009, at 11:31 AM, Chris Lattner wrote:

>
> On May 31, 2009, at 8:58 AM, Fariborz Jahanian wrote:
>
>> For blocks in gcc we followed the rules for function pointers in the
>> host language wrt to block pointers.
>> This change will make it more c++-ish and may break some of our
>> internal projects.
>> But it is a new feature and it is good to tighten up the rules. So it
>> is OK.
>
> While I sympathize with wanting to tighten up new features, this makes
> block pointers work differently than function pointers.  Is it really
> worth it?  What problem does this solve?


Problem #1: Type safety. A block pointer "int (^b)()" creates a block  
pointer that is hard to use properly. For example, bind it to a block  
literal like ^(char x) { ... } and you're already in trouble, since  
the literal expects a char but calling b('x') will promote the char to  
an int (yay, K&R). Plus, all of the problems of having functions  
without prototypes---e.g., the fact that it's easy to mismatch  
arguments with the actual, expected parameters---will now apply to  
blocks. There's no history to force us into the type-unsafe path, so  
why go there?

Problem #2: Gratuitous incompatibility with C++. We're defining a new  
feature for the C language, and then defining it differently in C++.  
Why, especially when we have a unified front end for the two  
languages? Such differences just lead to more incompatibilities and  
more confusion, especially if library developers accidentally use  
something like "int (^b)()" in a header that's meant to be used in  
both C and C++.

Problem #3: The C committee probably won't like it. Reading through  
the recent issues regarding functions and function pointers without  
prototypes, and in particular their responses to requests for  
clarification about interactions between functions/function pointers  
without prototypes and those with prototypes, one gets the feeling  
that the C committee wishes that functions without prototypes would  
just go away. I'm guessing they would reject the K&R-like behavior of  
block pointers. (But that's the conjecture of an outsider who has read  
a bunch of their issues in this area)

	- Doug