Re: [Gnustep-cvs] r32376 - in /libs/base/trunk/Source: GNUmakefile GSBlocks.m

[Fred Kiefer]

Now you did the fixes that I listed as the easy ones. You still didn't
add a proper heading for the file. Nor did you write a solution for
stupid linkers. Your idea of using #if __has_feature(blocks) should
work, but somebody has to put it in there.

Fred

Am 26.02.2011 20:28, schrieb David Chisnall:
> This should just need the loop rewriting in C89 syntax (done in r32382) and a 
> few other tweaks.  The forward declaration warnings were caused by my 
> declaring the function and forgetting that I was calling it via a macro 
> normally.
> 
> The point of having this stuff in base is so that people can use blocks in 
> their code.  Without it, attempts to send -retain / -copy / -release to 
> blocks do badly wrong things, while developers expect them to Just Work™.  
> This is independent of whether the compiler used for -base supports 
> blocks[1], because the compiler used for -base may not be the same as the 
> compiler used for other code.
> 
> David
> 
> [1] You don't need a configure check for this, the following will work, and 
> is used in NSRegularExpression and a few other places:
> 
> #if __has_feature(blocks)
> // code that uses blocks
> #endif
> 
> On 26 Feb 2011, at 14:33, Fred Kiefer wrote:
>> I am getting a lot of errors from gcc 4.5 with this change:
>>
>> Compiling file GSBlocks.m ...
>> GSBlocks.m: In function ‘+[GSBlock load]’:
>> GSBlocks.m:25:2: error: ‘for’ loop initial declarations are only allowed
>> in C99 mode
>> GSBlocks.m:25:2: note: use option -std=c99 or -std=gnu99 to compile your
>> code
>> GSBlocks.m:30:2: warning: ISO C90 forbids mixed declarations and code
>> GSBlocks.m: In function ‘-[GSBlock copyWithZone:]’:
>> GSBlocks.m:35:2: warning: implicit declaration of function ‘Block_copy’
>> GSBlocks.m:35:2: warning: return makes pointer from integer without a cast
>> GSBlocks.m: In function ‘-[GSBlock copy]’:
>> GSBlocks.m:39:2: warning: return makes pointer from integer without a cast
>> GSBlocks.m: In function ‘-[GSBlock retain]’:
>> GSBlocks.m:43:2: warning: return makes pointer from integer without a cast
>> GSBlocks.m: In function ‘-[GSBlock release]’:
>> GSBlocks.m:47:2: warning: implicit declaration of function ‘Block_release’
>>
>> Now most of this would be resolvable by sticking to old C conventions
>> and renaming the locally declared functions by removing the underscore.
>> But what would happen then? When linking this file the block functions
>> would still be missing. A clever linker wont complain about that, but
>> will this also work on Windows? And what is the whole point of adding
>> support for blocks into base, when the compiler and runtime don't
>> support them?
>> What we need here is a proper detection of block support in the
>> configure step. And while you are at it, would you mind to put in a
>> correct header for this file? (copyright, licence and what so ever)