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

> Am 08.01.2021 um 01:23 schrieb Riccardo Mottola <[email protected]>:
> 
> 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