Re: 64bit changes to gui

[Matt Rice]

On 2/17/13, Richard Frith-Macdonald <address@hidden> wrote:
>
> On 17 Feb 2013, at 11:33, Fred Kiefer wrote:
>
>> Now that I am almost through with the changes to CGFloat, NSInteger and
>> NSUInteger in gui I realized that I did not think about coding. When the
>> size of an instance variable changes from int to NSInteger what should
>> happen to the coding/decoding code? Lets take the tag of an NSControl as
>> the example. The old -initWithCoder: code may look something like this:
>>
>>      [aDecoder decodeValueOfObjCType: @encode(int) at: &_tag];
>>
>> Now _tag no longer is an int, is now is an NSInteger. Will that code still
>> work?
>> Should we change it to @encode(NSInteger)? (I think that is was base did)
>> But that will be something different depending on the machine the code
>> runs on? Is the coding mechanism able to handle that? And will this work
>> for CGFloat as well? And what about old archives, e.g. Gorm files?
>>
>> For the last batches of changes I no longer changed the types of the
>> instance variables. That is a valid workaround, but only delays the
>> decision what to do. Using local variables of the old type for
>> coding/decoding would also work, but again looks wrong to me.
>
> NSArchive/NSUnarchiver is supposed to cope with size differences between
> architectures automatically, but I'm not sure it will cope with different
> types without objecting (though I guess, if it doesn't,  we could make it do
> so).
> That is, if we encode a 32bit int on one machine, it's ok to decode it as a
> 64bit int, and if we encode a 64bit int, we can decode it as a 32bit int (as
> long as the original value can fit in a 32bit variable).

FWIW i remember adding some tests for this basictypes.m IIRC
Not sure if they've been updated for NSInteger and friends.