Re: NSControls failing to set status/label on BigEndian/64bit

[Wolfgang Lux]

Am 06.01.2021 um 23:11 schrieb Fred Kiefer <fredkiefer@gmx.de>:
> 
> 
> 
>> Am 06.01.2021 um 22:57 schrieb Wolfgang Lux <wolfgang.lux@gmail.com>:
>> 
>>> good catch. We have two differences here 32bit vs 64bit, but also signed vs 
>>> unsigned!
>> 
>> the difference between signed and unsigned is irrelevant for encoding and 
>> decoding, as you pass a pointer to the memory being encoded or decoded. 
>> However, the size of the value you want to encode or decode should agree 
>> with the type that is used for coding.
> 
> Things are even a bit more complicated here. Richard tries very hard to 
> handle different integer and float types in NSUnarchiver. The code tries to 
> match the data in the archive to the expected type and that works for many 
> cases. For some reason, I am not sure whether this is intentional, it does 
> not map between unsigned and signed. So although you are correct that this is 
> not a good idea, the code would work with
> 
> [aDecoder decodeValueOfObjCType: @encode(NSUInteger)
>                                   at: &_highlightsByMask];

Ah, thanks. I (obviously) wasn't aware of that extra smartness in the decoding 
function. The code makes sense to me as NSInteger expands to different types 
depending on whether you are on 32-bit or 64-bit architecture. Same for the 
NSUInteger. On the other hand, signed types should not become unsigned or vice 
versa if you change your architecture.

So perhaps the mistake here (apart from not type in the decodeValueOfObjCType 
call) was that _highlightsByMask and _altStateMask attributes were changed from 
unsigned int to NSInteger rather than NSUInteger? Although, admittedly, the 
real mistake was that those fields were unsigned ints in the first place, given 
that the corresponding methods always used to have (signed) int arguments and 
results (at least since the OpenStep era). 

> Most likely we have this issue in other places of gui as well. We were just 
> lucky that the bits in little endian systems fall into the expected places.

Yes, presumably somebody should inspect the code to check that all attributes 
that were changed from int or unsigned int to NSInteger and NSUInteger had 
their decoders and encoders changed accordingly.

Wolfgang