MC-208005Reference equality of NaNs is exposed
The bug
The internal reference equality of the NBT NaNf/NaNd affects the result of some commands.
How to reproduce
- Open the world with the command storage file in the Attachments.
/data modify storage mc-208005: a set from storage mc-208005: b
→
Modified storage mc-208005:/data modify storage mc-208005: a set from storage mc-208005: b
Expected behavior
The result is the same as above.
Actual behavior
Nothing changed. The specified properties already have these values
The result will be the same until the world is closed.
Code analysis
@Override public boolean equals(Object $$0) { if (this == $$0) { return true; } else { return $$0 instanceof FloatTag && this.data == ((FloatTag)$$0).data; } }
Because the two NaNs are different instances at the time of the first modification, this == $$0 returns false, and this.data == ((FloatTag)$00).data also returns false, which means they are not equal. This will cause the modification to succeed, and they will be the same instance.
In the second and subsequent modifications, since they are the same instance, this == $$0 returns true, which means they are equal. Thus, the modification will not succeed.
Attachments1
- Unresolved
intsuc- 8
- 5
- Confirmed
- Commands
- nbt
1.16.4 - 25w04a
1.16.4 20w49a 20w51a 21w03a 1.16.5 21w05b 21w08b 21w10a 21w11a 21w13a 21w15a 21w16a 21w19a 1.17-pre1 1.17 1.17.1 21w37a 1.18.1 22w03a 22w05a 1.18.2-pre1 1.18.2 22w11a 22w12a 1.19-rc2 1.19 1.19.1 1.19.2 1.19.3-rc1 1.19.3-rc2 1.19.3 23w03a 23w05a 1.19.4 23w12a 23w17a 23w18a 1.20 1.20.1 23w31a 1.20.2 23w42a 23w45a 23w46a 1.20.4 24w03a 24w04a 24w14a 24w33a 1.21.1 1.21.4 25w04a
Created Issue:
Reference equality of NaNs is exposed
The bug
The internal reference equality of the NBT NaNf/NaNd affects the result of some commands.
How to reproduce
- Open the world with the command storage file in the Attachment.
→
→
Code analysis
All numerical values except NaN are numerically equal to themselves, and thus reference equality of them implies numerical equality of them.
However, in the case of NaN, the above property does not hold since NaN is never numerically equal to NaN. This causes reference equality of two NaNs to be exposed to the user.
The bug
The internal reference equality of the NBT NaNf/NaNd affects the result of some commands.
How to reproduce
- Open the world with the command storage file in the Attachment.
→
→
Code analysis
All numerical values except NaN are numerically equal to themselves, and thus reference equality of them implies numerical equality of them.
However, in the case of NaN, the above property does not hold since NaN is never numerically equal to NaN. This causes reference equality of two NaNs to be exposed to the user.
The bug
The internal reference equality of the NBT NaNf/NaNd affects the result of some commands.
How to reproduce
- Open the world with the command storage file in the Attachments.
→
→
Code analysis
All numerical values except NaN are numerically equal to themselves, and thus reference equality of them implies numerical equality of them.
However, in the case of NaN, the above property does not hold since NaN is never numerically equal to NaN. This causes reference equality of two NaNs to be exposed to the user.
The bug
The internal reference equality of the NBT NaNf/NaNd affects the result of some commands.
How to reproduce
- Open the world with the command storage file in the Attachments.
→
→
Code analysis
All numerical values except NaN are numerically equal to themselves, and thus reference equality of them implies numerical equality of them.
However, in the case of NaN, the above property does not hold since NaN is never numerically equal to NaN. This causes reference equality of two NaNs to be exposed to the user.The bug
The internal reference equality of the NBT NaNf/NaNd affects the result of some commands.
How to reproduce
- Open the world with the command storage file in the Attachments.
→
→
Code analysis
Since NaN is never numerically equal to NaN, the equivalence of two NaNs depends only on reference equality of them. This causes reference equality of two NaNs to be exposed to the user.
![[Helper] Johnibur](../../../data/avatars/users/28381.png){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
![[Mod] ampolive](../../../data/avatars/users/18949.svg){kind=small}
The bug
The internal reference equality of the NBT NaNf/NaNd affects the result of some commands.
How to reproduce
- Open the world with the command storage file in the Attachments.
→
→
Code analysis
Since NaN is never numerically equal to NaN, the equivalence of two NaNs depends only on reference equality of them. This causes reference equality of two NaNs to be exposed to the user.
The bug
The internal reference equality of the NBT NaNf/NaNd affects the result of some commands.
How to reproduce
- Open the world with the command storage file in the Attachments.
→
Expected behavior
The result is the same as above.
Actual behavior
The result will be the same until the world is closed.Code analysis
net.minecraft.nbt.FloatTag.java@Override public boolean equals(Object $$0) { if (this == $$0) { return true; } else { return $$0 instanceof FloatTag && this.data == ((FloatTag)$$0).data; } }Because the two NaNs are different instances at the time of the first modification, this == $$0 returns false, and this.data == ((FloatTag)$00).data also returns false, which means they are not equal. This will cause the modification to succeed, and they will be the same instance.
In the second and subsequent modifications, since they are the same instance, this == $$0 returns true, which means they are equal. Thus, the modification will not succeed.