Would defining the structs as packed make a difference for the comparisson?
Sandor Szatmari On Aug 24, 2013, at 17:01, Jean-Daniel Dupas <devli...@shadowlab.org> wrote: > > Le 24 août 2013 à 22:09, Andreas Grosam <agro...@onlinehome.de> a écrit : > >> What's the purpose of NSValue's class method >> >> + (NSValue *)valueWithBytes:(const void *)value objCType:(const char *)type; >> ? >> >> It seems, NSValue will simply memcpy the content of value, and "somehow" >> determine the size in bytes from the string given in type. Is that reliable >> at all? (I have major doubts). >> >> >> It also seems, despite making the illusion having knowledge about the >> underlaying type, NSData fails to compare correctly two NSData objects which >> have been initialized by the same "Objective-C" type. >> >> >> That is, this code is generally "unsafe": >> >> struct a_s { >> unsigned char _b; >> long _l; >> }; >> >> -(void) foo { >> struct a_s; >> >> // suppose, we scramble some bits on the stack … >> >> a._b = 0; >> a._l = 1; >> >> b._b = a._b; >> b._l = a._l; >> >> NSValue *a_encoded = [NSValue valueWithBytes:&a objCType:@encode(struct >> a_s)]; >> NSValue *b_encoded = [NSValue valueWithBytes:&b objCType:@encode(struct >> a_s)]; >> >> assert([a_encoded isEqualToValue: b_encoded]); // May fail! >> } >> >> >> The assert may fail, since apparently NSData simply performs a memcpy. This >> of course fails miserably if we intended to compare the _struct_ values. >> >> Nonetheless, NSData pretends to be able to return the correct result when >> comparing the encoded values. Well, of course this may be considered by >> NSData as correct - despite it's different to comparing the corresponding >> struct values - since only NSData knows and defines what makes a NSValue >> equal to another ;) > > When compiling a struct, the compiler add padding where needed so that each > field is aligned as required by the ABI. The padding can contains any value > and nothing force it to be initialized to 0. > When you memcpy a struct, you include the padding, which can contains > anything. When you restore the value, all field are restored properly though, > but there is no guarantee that a memcmp of two struct with all field > containing the same value will always returns the same result. > >> So again, I cannot see where this feature can be ever sensible, and does not >> simultaneously introduce more harm than use. >> >> Additionally, I'm worried about the fact, that a *particular Apple library* >> will use the above technique to *compare structs*. > > > That's not a problem specifics to NSValue. You should know what you do when > manipulating structs. > > -- Jean-Daniel > > > > > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/admin.szatmari.net%40gmail.com > > This email sent to admin.szatmari....@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com