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

Reply via email to