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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
