I've found real-world instances of 128bit ints in plists

[DannyThomas]

This was running under macOS 11.4beta upgraded from 10.13
so was originally confused by sandboxing.

I'm writing a utility to report differences in plist files.
This means I'm recursively traversing all files under:
/Library/Preferences
~/Library/Preferences
using Mac::PropertyList::parse_plist_file. I'm using v1.502,
albeit by not properly installing but by unpacking and copying
the 'lib' directory, which is normally OK for Pure-Perl modules.

After modifying my script to ignore non-plist files and
allowing Terminal full-access to the disk, I was getting
croak "Integer > 8 bytes = $length"

After applying the attached diff, I got the following output
with no croaks(). The file-path is printed by my script before
it calls parse_plist_file
/Users/dthomas/Library/Preferences/.GlobalPreferences.plist
128bit int has top 64bits of zero
00000000 00000000 00000000 000007D0
so truncate it to a 64bit int
/Users/dthomas/Library/Preferences/com.apple.finder.plist
128bit int has top 64bits of zero
00000000 00000000 00000000 00000001
so truncate it to a 64bit int
/Users/dthomas/Library/Preferences/com.apple.ncprefs.plist
128bit int has top 64bits of zero
00000000 00000000 80000000 00000000
so truncate it to a 64bit int
128bit int has top 64bits of zero
00000000 00000000 80000000 00000007
so truncate it to a 64bit int
128bit int has top 64bits of zero
00000000 00000000 80000000 00000000
so truncate it to a 64bit int
128bit int has top 64bits of zero
00000000 00000000 80000000 00000007
so truncate it to a 64bit int
128bit int has top 64bits of zero
00000000 00000000 80000000 00000000
so truncate it to a 64bit int
128bit int has top 64bits of zero
00000000 00000000 80000000 00000000
so truncate it to a 64bit int
128bit int has top 64bits of zero
00000000 00000000 80000000 00000000
so truncate it to a 64bit int

Originally I thought I might have to provide some support for
128bit integers. But since all the cases I've seen can be
truncated, there's no need.

NB The irony is the length bits of ints/reals in
https://github.com/opensource-apple/CF/blob/master/CFBinaryPList.c
are marked '0nnn', whereas 'nnnn' was the case in the older
https://opensource.apple.com/source/CF/CF-550/CFBinaryPList.c

I thought I could create a test file with one attribute having a
128bit integer value
$ defaults write t1 128bit-integer -int 1208925819614629174706176
which is 2^80
$ plutil -convert xml1 -o - ~/Library/Preferences/t1.plist

128bit-integer 9223372036854775807 My script does not report the attribute valeu being 128bits, so it looks like defaults silently truncates integers to < 2^64. [ReadBinary.pm.diff.txt](https://github.com/briandfoy/mac-propertylist/files/6527406/ReadBinary.pm.diff.txt)

[briandfoy]

Okay, noted. I'll need to investigate.

[DannyThomas]

On 26 May 2021 at 5:07:29 am, brian d foy ***@***.***) wrote: Okay, noted. I'll need to investigate. Thanks. I used to know unsigned arithmetic better, but truncating the top zero 64bits of cases like 00000000 00000000 80000000 00000000 00000000 00000000 80000000 00000007 (which in this case is probably used as a set of bits), ends up as a negative int? It doesn’t really matter to me as I’m not trying to interpret (most) values in plists, but I really wish all the default values existed in System & User preference plists. Cheers, Danny

[briandfoy]

I played around with this and couldn't get anything to make 128-bit integers.

There's a lot I could do here, but I'm curious about the sign issue. We can't simply ignore the top bytes because that may be where the sign bit is. But, maybe those octets really don't matter and the sign bit is with the lower 64 bits.

If you can create a file with a 128-bit, let me know. I'd like to look at it, especially if it's a binary plist.

[briandfoy]

Just an update - I have some local code that I haven't pushed because I don't like it yet, and I'm kinda waiting for more complaints. If this is pressing, I can spend more time on it, but there always seems to be more pressing things. It's a good report and I'm not blocked on anything other than time.

[DannyThomas]

It's a good report and I'm not blocked on anything other than time. Yep, I haven’t looked at Property Lists for months. I can’t afford a context switch at the moment, but I can tell you about “merchant silicon” Danny D On 22 January 2022 at 8:31:26 am, brian d foy ***@***.***) wrote: Just an update - I have some local code that I haven't pushed because I don't like it yet, and I'm kinda waiting for more complaints. If this is pressing, I can spend more time on it, but there always seems to be more pressing things. It's a good report and I'm not blocked on anything other than time. — Reply to this email directly, view it on GitHub <#10 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFS3CJBPIG5YBV6J3TA44TUXHND5ANCNFSM45LGNQGA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>