Mon 16 Mar 2009 11:25:24 AM UTC, comment #2:
Thanks, we should get this improvement put into gcc.
I'm recategorising it as a change request though, as there doesn't seem to be any bug involved, just a small inefficiency.
I guess the implied 'bug' was the suggestion that sel_get_name() should always return the same value for the same selector, but I see no such promise in the documentation. Indeed the fact that you are explicitly required to use a function to test for selector equality (rather than testing for pointer equality) seems to imply that you must not expect a pointer equality test to work for selector names either.
|
Sun 15 Mar 2009 11:22:47 AM UTC, comment #1:
Here is a more direct example, where three selectors with the same name, but different types, are registered. Each time, the name string is replaced with a new copy.
Attached is a patch that fixes this by moving everything related to the new_name variable in __sel_register_typed_name inside the if (is_new) branch.
$ cat main.m
#import <Foundation/Foundation.h>
int main (int argc, const char **argv)
{
char *name = "test";
NSLog(@"name ptr: %d", name);
NSLog(@"register1");
SEL sel1 = sel_register_typed_name(name, "@8@0:4");
NSLog(@"%d %d %s", sel1, sel_get_name(sel1), sel_get_type(sel1));
NSLog(@"register2");
SEL sel2 = sel_register_typed_name(name, "v8@0:4");
NSLog(@"%d %d %s", sel1, sel_get_name(sel1), sel_get_type(sel1));
NSLog(@"%d %d %s", sel2, sel_get_name(sel2), sel_get_type(sel2));
NSLog(@"register2");
SEL sel3 = sel_register_typed_name(name, NULL);
NSLog(@"%d %d %s", sel1, sel_get_name(sel1), sel_get_type(sel1));
NSLog(@"%d %d %s", sel2, sel_get_name(sel2), sel_get_type(sel2));
NSLog(@"%d %d %s", sel3, sel_get_name(sel3), sel_get_type(sel3));
return 0;
}
$ make && obj/test
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 ...
2009-03-15 11:20:02.145 test[26773] name ptr: 134515274
2009-03-15 11:20:02.149 test[26773] register1
2009-03-15 11:20:02.151 test[26773] 148128376 148754376 @8@0:4
2009-03-15 11:20:02.155 test[26773] register2
2009-03-15 11:20:02.158 test[26773] 148128376 148827072 @8@0:4
2009-03-15 11:20:02.161 test[26773] 148128368 148827072 v8@0:4
2009-03-15 11:20:02.164 test[26773] register2
2009-03-15 11:20:02.168 test[26773] 148128376 148826744 @8@0:4
2009-03-15 11:20:02.171 test[26773] 148128368 148826744 v8@0:4
2009-03-15 11:20:02.174 test[26773] 148128360 148826744 (null)
(file #17695)
|
Sat 14 Mar 2009 10:30:06 PM UTC, original submission:
While working on library code for Étoilé, a strange situation was encountered that may be caused by a bug in libobjc. The issue is with pointers to the name strings in selectors changing unexpectedly.
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 v8@0:4
2009-03-14 22:22:10.406 test[23586] 134520200 134519897 test v8@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 v8@0:4
2009-03-14 22:22:10.416 test[23586] 134520200 145449736 test v8@0:4
|