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

[Fariborz Jahanian]

On Apr 8, 2009, at 9:46 AM, Douglas Gregor wrote:

>
> 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.

What is the compelling reason not to allow K&R style definition, other  
than the trend in c standardization?
Maybe by convenience (I did not write this), it is meant that people  
who are use to using function pointers
can adapt blocks more quickly if K&R style is allowed.

>
> 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.

Blocks in c++ mode in gcc follow this rule.

- Fariborz

>
> 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/f6db13a6/attachment.html>