Re: gcc-20020909, Objective-C, and compiling the Swarm libraries

[Nicola Pero <nicola at brainstorm dot co dot uk>]

> The protocol bug was the first I ever submitted in GNATs. The new 
> shapshot makes that go away.  Is it now customary for me to go in there 
> and close that report?

Thanks - don't worry about closing reports - I'll go there and check the
bug reports and close your report at the first occasion I got some time
for GCC (I hope today or tomorrow).

 
> We run into this a lot because some things in gcc itself use int where 
> one might expect unsigned. Consider
> 
> line 207 of objc-api.h:
> 
> typedef struct objc_ivar_list {
>    int   ivar_count;
> 
> Comparing that against an unsigned used to be OK, but no longer.

Interesting.

I've seen similar cases (objc_protocol_list I think) having been changed
from an int to a size_t.  Maybe that would help.

 
> 2.  This is an Obj-C thing, I suspect. My opinion is that this reflects 
> IMPROVED class checking in gcc, but some of my teammates think it is 
> just a bug like the protocol one you appear to have fixed (as far as I 
> can tell, anyway) in gcc-20020909.
> 
> We have a super class Customize that does not implement its own factory 
> method
> 
> +createBegin: aZone;
> 
> But in several of Customize's other class methods, it does have commands 
> like
> 
> [self createBegin: zone];
> 
> The Customize class is never directly instantiated, only sublcasses from 
> it are ever instantiated, and all those classes do have +createBegin: 
> methods. So if we just ignore that warning, then all is well.

You can also declare the method in the superclass, but not implement it.  
The warning will go away the same.

 
> But I can't figure out why gcc didn't warn us before.

Older gcc didn't perform such a good typechecking :-)


> In Customize.h and Customize.m, I can insert a +createBegin: method that 
> does nothing and this warning message goes away, but one wonders if that 
> is what gcc intends.

Yes - I'd suggest declaring it in a category of Customize, and never
implementing the category - then all warnings should (cleanly) go away.
 

> It almost appears that all factory methods must be declared in a header 
> file in order for gcc to like them.  We think that's a new thing.

Yes - it is - but it's definitely for the better.



> In this case, a file ObjectSaver.m has a class method in it:
> 
> + (void)_crash_: anObject
> {
>    raiseEvent (SaveError,
>                "Could not save %s properly (factory)\n",
>                  [anObject name]);
> }
> 
> Inside ObjectSaver.m, that method gets used as in line 7 of this class 
> method:
> 
> 
> + save: anObject toFileNamed: (const char *)aFileName
> {
>    id anObj, aFileObject;
> 
>    aFileObject = [OutFile create: [anObject getZone] setName: aFileName];
> 
>    if (!aFileObject)
>      [self _crash_: aFileObject];
> 
>    anObj = [self create: [aFileObject getZone]];
>    [anObj setFileObject: aFileObject];
>    [anObj saveObject: anObject];
>    [anObj drop];
>    [aFileObject drop];
> 
>    return self;
> }
> 
> 
> If we put +_crash_: into the header file ObjectSaver.h, then the warning 
> goes away. But we don't understand why the class method, which is used 
> only in ObjectSaver.m, must be put into the header file.

The golden rule applies: the method must be seen by the compiler *before*
you call it.

You have two ways of doing it:

 - declaring the method in an @interface which is seen by the compiler
before the method call (that @interface can well be inside the .m file!  
you can declare public methods in the .h file, and private ones in the .m,
inside a category).

 - implementing the method before you call it.  So if you move +_crash_
before +save:toFileName: in the implementation file, the warning should go
away even if you have no declaration for it.