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

[Fred Kiefer]

> Am 08.01.2021 um 01:23 schrieb Riccardo Mottola <riccardo.mottola@libero.it>:
> 
> Richard Frith-Macdonald wrote:
>> Changing the type of the masks from NSInteger to uint32_t would also fix the 
>> encoding/decoding of course.  Maybe that has other issues though.
> 
> perhaps we should try a mixed approach: encode/decode in the format with 
> uint32_t and int32_t, but then always cast to NSUInteger/NSInteger. That way 
> we have that data "Fixed" as 32bits in the Gorm file from whatever platform 
> we write into, but then cast/convert it to whatever we need.

I still prefer your original approach as it is less intrusive. There definitely 
is no use for two different encodings. I also see no big issue in living with 
the old, wrong encoding of these values as unsigned.

> A big doubt I have always is about typdefs, if they are signed or not, since 
> I think to remember this is architecture/compiler dependent. I tried to leave 
> that out to the compiler for now.

I think this is mostly true for char and maybe for enums, otherwise it should 
be well defined.

> I just finished a first proposal, what do you think?

What I like about your change is that we now make explicit the actual size that 
gets stored in the archive. This is always the same and should be the same 
independent of the architecture the code runs on. It would be a big improvement 
to have that changed all over GNUstep.

> The keyed path has two bFlags, which I think and I am worried about the code 
> where buttonCellFlags are copied with a memcpy.. of which size? it needs to 
> be of uint32_t to fit in memory, but is it?.. later is copied back with the 
> struct size. Scary.

The good thing here is that in all these flag structures (and we have plenty of 
them) we explicitly state the size of each element in bits. So nothing to worry 
here, apart from the sign.

Fred