[cfe-commits] r68583 - in /cfe/trunk: lib/CodeGen/CGBlocks.cpp lib/CodeGen/CGCall.cpp lib/CodeGen/CodeGenTypes.h test/CodeGen/blocks.c

[Douglas Gregor]

On Apr 8, 2009, at 7:59 AM, fjahanian wrote:

>
> On Apr 8, 2009, at 5:02 AM, steve naroff wrote:
>
>>
>> On Apr 7, 2009, at 11:01 PM, Eli Friedman wrote:
>>
>>> On Tue, Apr 7, 2009 at 7:56 PM, Anders Carlsson <andersca at mac.com>  
>>> wrote:
>>>> Author: andersca
>>>> Date: Tue Apr  7 21:55:55 2009
>>>> New Revision: 68583
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=68583&view=rev
>>>> Log:
>>>> Don't assume that a block always has a FunctionProtoType. Fixes rdar://6768379.
>>>
>>> Maybe we should make "int (^a0)()" and "int (^a0)(void)" equivalent?
>>
>> I agree with you. IIRC this is what I originally implemented (in  
>> clang). I forget what motivated us to support K&R style as a  
>> "convenience" (see excerpt below). Fariborz?
>
> In gcc,  initially we followed the rules for function pointers for  
> lack of a detailed specification.
> As usage of blocks start getting traction, we tightened the rules as  
> outlined below.

Okay, that's this part:

>>  A Block that takes no arguments must specify void in the argument  
>> list [voidarg.c].  An empty parameter list does not represent, as  
>> K&R provide, an unspecified argument list.  Note: both gcc and  
>> clang support K&R style as a convenience.
>>

I don't understand what it means for a feature to be a "convenience".  
Either blocks support can support K&R-style functions without  
prototypes or they can't. There's no "legacy" code to worry about,  
here, so it doesn't make any sense to say, "this is wrong, but these  
compilers support it."

Personally, I feel that blocks should always require prototypes. It's  
a new feature without any legacy code to support, and prototypes are  
the way forward: the C committee seems to favor prototypes, and of  
course C++ always uses prototypes.

For Clang, we should either warn about or reject code like:

	int (^a0)()

in C, treat it as int (^a0)(void), and provide a fix-it hint  
suggesting the introduction of "void".

In C++, it already means the same thing as int (^a0)(void), so there's  
nothing to do.

If we aren't doing this already, why not?

	- Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20090408/09b28d91/attachment.html>