5 ms·
On (2): implicit type promotions with unsigned and signed types can make it no-so-easy in C. FWIW, I always test with bytes with the sign bit on (on two's compl
by astrobe_ 6y ago
On (2): implicit type promotions with unsigned and signed types can make it no-so-easy in C. FWIW, I always test with bytes with the sign bit on (on two's complement architectures, never worked with others) when I do stuff like that.
On (3): never perform equality tests on FP numbers in languages that use IEEE standard FP format.
On (4): I have worked both with ASCIIZ and counted strings, I think both have their pros and cons. But if you are writing stuff that has any contact with C/C++, it's often a bad idea to go against the stream. No, auto-adding a final 0 to your counted strings won't save the day every time.
- a1369209993 6y agoNever perform equality tests on FP numbers period - it defeats the purpose of using floating point. This is not specific to the IEEE format.
- imtringued 6y agoTell that to lua and javascript developers who only have access to FP numbers.
- a1369209993 6y agoshrug They also only have access to IEEE FP numbers, so that applies equally much to the parent.
- astrobe_ 6y agoIf my memory serves, IEEE FP is accurate for those real numbers that are also integers (at least on some range). JS users are safe as long as they stay within the integer algebra (ie they don't use division, mainly, or perhaps round up the result). Lua users have the extra option to recompile their interpreter it uses integers.
- a1369209993 6y agoThat's fair as far as it goes (I pedantically should have said general-purpose FP numbers), but, again, applies equally well (actually more so, since they were talking about IEEE FP specifically) to the parent post.