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) _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
