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

Richard Frith-Macdonald <[email protected]>
Newsgroups gmane.comp.lib.gnustep.devel
Message-ID <[email protected]>

> On 7 Jan 2021, at 17:12, Wolfgang Lux <[email protected]> wrote:
> 
> Am 07.01.2021 um 14:33 schrieb Riccardo Mottola <[email protected]>:
>> 
>> Hi all,
>> 
>> 
>> Wolfgang Lux wrote:
>>> Yes. Changing the type you pass to the {en,de}codeValueOfObjCType methods is a, errm, not so bright idea. The types are included in the binary archives. So, trying to decode a value with a different type will give you an error (for your own safety and sanity). Trying to encode values with a different type is even worse, as you would be creating archives that cannot be read by anybody else (because they are expecting some other type). If you (have to) make such changes, be sure to introduce a new archive version and be sure to include backward compatibility code for reading the old archive format.
>> 
>> I had a call with Gregory yesterday.. since this is a delciate subject I made a branch with a proposed initial change (as I have other controls failing, it will not be the conly class affected either)
>> 
>> BE-64-Fixes
>> 
>> What do you think?
> 
> I think that introducing a new archive format to address the issue with the _highlightsByMask and _altStateMask attributes is a bit over the top. Either decoding the attributes as NSUInteger values as Fred mentioned or decoding them as unsigned int into a temporary variable and then copying the values from those temporary variable into the respective attribute would do. BTW, I don't consider the latter a hack. It's a perfectly sane solution for dealing with backward compatible archives.
> 


I just had a chance for a quick look.
It sounds like the problem is he code 

      [aCoder encodeValueOfObjCType: @encode(unsigned int)
              at: &_highlightsByMask];

where _highlightsByMask is actually NSInteger (signed 64bit)

If you are on a big endian machine,  that would presumably encode the upper 32bits of the value ... which are probably all zero ... so the data never gets into the archive.

So I agree, the bugfix would be to copy _highlightsByMask (lower 32bits) into a 32bit unsigned integer value first

uint32_t tmp = (uint32_t) _highlightsByMask
[aCoder encodeValueOfObjCType: @encode(unsigned int) at: &tmp];

So the correct value is stored in the archive.

A similar change would be needed to decode into a uint32_t and then copy that into place.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.