Re: applications that fail to build with new gnustep from svn

[David Chisnall]

On 5 Apr 2011, at 18:36, Sebastian Reitenbach wrote:

>>> GRText.m:253:13: error: cannot pass object with interface type
>>> 'NSColor' by-
>>> value through variadic method
>>>             strokeColor[0], strokeColor[1], strokeColor[2],
>>> strokeColor[3]];
>>>             ^

This is being rejected by clang because the code is nonsense.  strokeColor is 
an ivar inherited from GRDrawableObject.  It is an NSColor*.  If this is 
intended to be an array of NSColor objects, then the code should be 
&strokeColor[0], but I don't see anything in the code that is initialising more 
than the first element.

strokeColor[0] has undefined semantics in Objective-C.  The error message could 
be more helpful, but the error is real.

>>> ./PRCustTraceEdges.h:21:127: warning: declaration of 'enum
>>> medianForms' will
>>> not be visible outside of this function

Valid warning.  Enums should be declared before they are used.  If the enum 
declaration happens after its first use, then it is treated as a different 
type, so a correct compiler will reject the two as being different types.

You may be able to turn this off by adding -std=c89, which relaxes this 
restriction slightly.

>>> PRCustTraceEdges.m:86:23: warning: unused variable 'destBytesPerRow' [-
>>> Wunused-variable]
>>>     int               destBytesPerRow;
>>>                       ^

Not an important, just an artefact of the fact that C89 doesn't make it easy to 
respect the principle of least possible scope, so these are often missed.

>>> PCParser.m:127:24: error: initializer element is not a compile-time
>>> constant
>>> static SEL selString = @selector(string:);
>>>                        ^~~~~~~~~~~~~~~~~~

@selector() is not a compile-time constant (it's actually a const LValue, of 
all things).  Apple's GCC will also reject this.  I did have a patch to clang 
that accepted it, but I removed it because it just encourages this pattern, 
which is stupid (@selector() expressions are constants, you're just adding a 
load and a store, preventing some pointer comparisons to work, and using twice 
as many cache lines as you need to with it - this code will be slower than 
using @selector() directly).

David