[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 10:23 AM, Fariborz Jahanian wrote:

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

Several reasons:

1) New language features for C shouldn't go against the trends in the  
C standardization world. It leads to more fragmentation in the  
community and undercuts the C committee.

2) K&R-style blocks, like K&R-style function pointers, are not type- 
safe: it's extremely easy to send the wrong number or wrong kind of  
arguments to block declared as, e.g., int (^ao)().

3) Programmers---especially C++ programmers---are very likely to  
accidentally write int (^a0)() when they mean int (^a0)(void), which  
means is very easy to accidentally disable type safety. This is *not*  
something you want for blocks, which are meant to be type-safe  
abstractions of closures.

4) If we don't ban K&R-style blocks now, we won't be able to do so in  
the future because the "legacy code" argument will carry some weight.  
It's the right thing to do, and it's much harder to do later.

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


Do we have any examples of this?

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