2010-03-18 9 views
0

J'ai trouvé ce que je pense être un bogue avec Ivar et Objective-C runtime. J'utilise XCode 3.2.1 et les bibliothèques associées, en développant une application 64 bits sur X86_64 (MacBook Pro).Les définitions Ivar montrent un codage de type «long» comme un codage de type «long long»

Lorsque je m'attendrais à ce que le codage de type pour le "longVal" suivant soit "l", le codage Ivar montre un 'q' (qui est un 'long long').

Quelqu'un d'autre voit cela? Code simplifié et la sortie suivante:

code:

#import <Foundation/Foundation.h> 
#import <objc/runtime.h> 
@interface Bug : NSObject 
{ 
    long  longVal; 
    long long longerVal; 
} 
@property (nonatomic,assign) long longVal; 
@property (nonatomic,assign) long long longerVal; 
@end 

@implementation Bug 

@synthesize longVal,longerVal; 

@end 


int main (int argc, const char * argv[]) { 
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; 
    unsigned int ivarCount=0; 
    Ivar *ivars= class_copyIvarList([Bug class], &ivarCount); 

    for(unsigned int x=0;x<ivarCount;x++) { 
     NSLog(@"Name [%@] encoding [%@]", 
     [NSString stringWithCString:ivar_getName(ivars[x]) encoding:NSUTF8StringEncoding], 
       [NSString stringWithCString:ivar_getTypeEncoding(ivars[x]) encoding:NSUTF8StringEncoding]); 
    } 

    [pool drain]; 
    return 0; 
} 

Et voici la sortie de la console de débogage:

This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys000 
Loading program into debugger… 
sharedlibrary apply-load-rules all 
Program loaded. 
run 
[Switching to process 6048] 
Running… 
2010-03-17 22:16:29.138 ivarbug[6048:a0f] Name [longVal] encoding [q] 
2010-03-17 22:16:29.146 ivarbug[6048:a0f] Name [longerVal] encoding [q] 
(gdb) continue 

Pas une jolie photo!

- Frank

+0

Ce que dit zneak; tain't un bug. Cependant, il y a beaucoup d'autres bugs avec '@ encode' et des amis. En bas de ce chemin se trouvent les pièges. Veuillez vous assurer que vous déposez des bogues contre des problèmes spécifiques et un bogue détaillant ce que vous essayez de faire. – bbum

Répondre

2

Ce n'est pas un bug. Le compilateur GCC, sous une architecture 64 bits, choisit de représenter long comme des entiers de 64 bits. Vous pouvez le vérifier vous-même:

printf("%lu\n", sizeof(long)); // will give "8" 

Pour rappel, la norme C ne définit que les tailles minimales pour les types entiers. long est seulement garanti d'être au moins 32 bits.

+0

zneak, Paul et bbum: Exécution d'un [bug performSelector: @selector (setLongVal :) withObject: [NSNumber numberWithLong: (long) 87]]; résultats en: 2010-03-18 06: 55: 48.163 ivarbug [1006: a0f] Sortie de bogue après performSelector [longVal [4296082976]] –

+0

Cependant, l'utilisation de NSInvocation semble fonctionner pour le type. Il utilisait le 'performSelector' qui a soulevé mes sourcils pour commencer et pourquoi j'ai commencé à creuser po –

+0

@Frank C .: Ceci n'est pas non plus un bug. Votre propriété attend une valeur 'long', et vous leur donnez une valeur' NSNumber * '. Vous ne pouvez pas utiliser 'execSelector: withObject:' pour les méthodes dont les types d'arguments ne sont pas 'id'; cela a coïncidé "travaillé" parce que "long" et les pointeurs sont de la même taille sous le modèle LP64. Ce que vous avez maintenant est probablement l'adresse mémoire de votre objet NSNumber. Voir le document pour 'performSelector: withObject:'. – zneak

0

Mac OS X, Linux et la plupart des autres systèmes d'exploitation 64 bits utilisent le modèle LP64, où les longs et les pointeurs sont 64 bits, tandis que les ints sont 32 bits.

Questions connexes