Floats are displayed incorrectly

[luckman212]

• macOS 12.4
• Xplist v1.2.45

Floats are not displayed properly. See below

Also should the type be shown as float instead of real?

[ic005k]

Received. Please provide the original plist file, and I will analyze it on my side.

[ic005k]

You are opening a binary file, which seems to be a problem regarding accuracy when converting data.

[ic005k]

Also, may I ask if your MacOS version is 12.4 (21F79)?

[luckman212]

Thanks. Yes, I updated yesterday to 12.4 21F79
Attached is the plist I was looking at
com.aptonic.Dropzone-setapp.plist.zip

[ic005k]

This doesn't seem to be any problem, and when you preview the original file (select this file and hit the spacebar), it shows the data as shown in the figure.
The value of 4.3 is automatically rounded by the system. I don't know, for the moment, why the system would change this value to 4.3 and not keep the other decimal places?

[ic005k]

If this value is used to define the version number, then why didn't the original file just set this value to 4.3, but 4.29999...?
This is a bit confusing to me.
Actually Xplist did nothing, it just showed the value as is (4.29999...).

[luckman212]

Hmm that is actually strange. All of the normal tools I have to deal with binary plists (defaults, plutil, plistbuddy, python plistlib...) report the value as "4.3". How did you even see the raw value?

[ic005k]

How did you even see the raw value?

select this file and hit the spacebar

[ic005k]

macOS, the spacebar is enough to preview the file. I am also currently using macOS 12.4 (21F79)

[luckman212]

Hmm. I see what you mean. However, even Xcode renders this value as 4.3.

I made a small Python script to dump the contents, and also I see 4.3 there.

$ plist-parse.py ~/Library/Preferences/com.aptonic.Dropzone-setapp.plist CurrentAppVersion
4.3

I don't know what the correct answer is here, but so far the only tool that outputs as a real (4.2999999999999998) is Xplist.

[ic005k]

It has been updated, please upgrade to the latest version.
Any questions or suggestions are welcome, thank you.

[luckman212]

Thank you. But I am skeptical of this code. I looked at how the fix was implemented. It makes me nervous that data is going to be changed or inaccurately represented.

I was able to reproduce the strange rounding with the following command:

$ plutil -extract CurrentAppVersion xml1 -o - -- ~/Library/Preferences/com.aptonic.Dropzone-setapp.plist 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<real>4.2999999999999998</real>
</plist>

So it seems your program may not be alone after all in how it displays this data. I will keep investigating. But for now I suggest maybe rolling back this fix.

update: it is not exactly the same, but feels like this could be closely related to this bug: https://www.cocoanetics.com/2012/09/radar-cgrectmakewithdictionaryrepresentation/

In the end this is probably something I should ask the developer of that app about- it's probably best to store the version as a String value, and use an Int to store the build number. So it won't be subjected to rounding errors like this.

[ic005k]

It doesn't matter, Xplist must perform this rounding operation in order to be consistent with Xcode's parsing.
I don't know if this makes complete sense, but at least it shows up correctly.
Don't worry, I'll still keep an eye on this and update Xplist in due course.

[ic005k]

But for now I suggest maybe rolling back this fix.

Okay.

[ic005k]

In fact, I always thought Xplist's parsing was the most correct because it shows the original values of the data without ever doing any rounding on the original values of the data.

[ic005k]

It is now rolled back, please feel free to let me know if you have any questions or ideas, thanks.