http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45953
Summary: Registering untyped selector mutates existing selector
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libobjc
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nic...@gcc.gnu.org
Created attachment 22005
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22005
Patch to improve the efficiency of registering selectors with the same name
This bug originates from GNUstep,
https://savannah.gnu.org/bugs/?25869
It is a small inefficiency in the runtime. Here is the original report from
Truls Becken. I also attach his patch.
-------------------------------------
A test case is shown below, where four -test messages all use the same typed
selector. An interleaved -valueForKey: message registers an untyped selector
with the same name. At that moment, the typed selector is modified to use the
same string pointer as the new untyped selector.
One would think that this should be the other way around. The newer selector
should use the same string as the existing one, not modify one that is already
registered.
This is using libobjc from the GNUstep Subversion repository at r28049. GNUstep
Base is from the same svn revision.
$ cat GNUmakefile
include $(GNUSTEP_MAKEFILES)/common.make
TOOL_NAME = test
${TOOL_NAME}_OBJC_FILES = main.m
include $(GNUSTEP_MAKEFILES)/tool.make
$ cat main.m
#import <Foundation/Foundation.h>
@interface Foo : NSObject {}
- (void) test;
@end
@implementation Foo
- (void) test
{
NSLog(@"%d %d %s %s", _cmd, sel_get_name(_cmd),
sel_get_name(_cmd), sel_get_type(_cmd));
}
@end
int main (int argc, const char **argv)
{
[NSAutoreleasePool new];
id foo = [Foo new];
[foo test];
[foo test];
[foo valueForKey: @"test"];
[foo test];
[foo test];
return 0;
}
$ make
This is gnustep-make 2.0.8. Type 'make print-gnustep-make-help' for help.
Making all for tool test...
Compiling file main.m ...
Linking tool test ...
$ obj/test
2009-03-14 22:22:10.401 test[23586] 134520200 134519897 test v...@0:4
2009-03-14 22:22:10.406 test[23586] 134520200 134519897 test v...@0:4
2009-03-14 22:22:10.410 test[23586] 144773752 145449736 test (null)
2009-03-14 22:22:10.413 test[23586] 134520200 145449736 test v...@0:4
2009-03-14 22:22:10.416 test[23586] 134520200 145449736 test v...@0:4
