Hi Fred, 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: > Hi David, > > 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) > > Cheers > Fred > > Am 26.02.2011 14:10, schrieb David Chisnall: >> Author: theraven >> Date: Sat Feb 26 14:10:49 2011 >> New Revision: 32376 >> >> URL: http://svn.gna.org/viewcvs/gnustep?rev=32376&view=rev >> Log: >> Move method declarations on blocks from EtoileFoundation into GNUstep. >> >> >> Added: >> libs/base/trunk/Source/GSBlocks.m >> Modified: >> libs/base/trunk/Source/GNUmakefile -- Sent from my brain _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev