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

[Paul Johnson <pauljohn at ku dot edu>]

Thanks for the new gcc snap. I appreciate your work very much and I'm 
amazed by the magnitude of changes from snap to snap.  My number of 
problems in compiling Swarm with gcc is shrinking dramatically.  I have 
confirmed that, except for the three problems listed here, I can 
compile/run programs against the Swarm libraries built with gcc-20020909.

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?

Perhaps you could tell me if these "problems" of mine reflect changes in 
gcc policy or gcc bugs, so I will know where I stand.

1. This is an ordinary C thing, I suspect.  I can workaround this in our 
code, but don't know why gcc would change in this way. I can no longer 
compare unsigned ints and ints. It produces this warning:

../../../swarm-2.1.140.20020514/src/collections/Array.m: In function 
`-[Array(c) __lispOut::deep:]':
../../../swarm-2.1.140.20020514/src/collections/Array.m:493: warning: 
comparison between signed and unsigned
../../../swarm-2.1.140.20020514/src/collections/Array.m:499: warning: 
comparison between signed and unsigned
make[4]: *** [Array.lo] Error 1

It happens with code like:

int i;
unsigned count;
for (i=0; i< count; i++) ...

This previously (either in gcc-3.0.x or 3.2) did not cause a warning.

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.


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.

But I can't figure out why gcc didn't warn us before. Up through 
gcc-3.0.4, we did not get complaints about our usage.

But starting with 3.1, we now see a compiler warning:

../../../swarm-2.1.140.20020514/src/defobj/Customize.m: In function 
`+[Customize(s) _customizeBegin:]':
../../../swarm-2.1.140.20020514/src/defobj/Customize.m:106: warning: 
cannot find class (factory) method
../../../swarm-2.1.140.20020514/src/defobj/Customize.m:106: warning: 
return type for `createBegin:' defaults to id

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.

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. (next 
question is a more clear version of same issue, probably)

3.  This is another Obj-C thing, that appeared with gcc-3.1 and still is 
in 20020909. This is the one that makes me suspect there might in fact 
be a bug behind the problem in the previous question.


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.


Here's what the compiler says:
../../../swarm-2.1.140.20020514/src/simtools/ObjectSaver.m: In function 
`+[ObjectSaver save:toFileNamed:]':
../../../swarm-2.1.140.20020514/src/simtools/ObjectSaver.m:66: warning: 
cannot find class (factory) method
../../../swarm-2.1.140.20020514/src/simtools/ObjectSaver.m:66: warning: 
return type for `_crash_:' defaults to id



--
Paul E. Johnson                       email: pauljohn@ukans.edu
Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66045                FAX: (785) 864-5700