Why does (= 0 nil) return false, but (= nil 0) return true?

[oadbd]

Hi, new to janet.

In the docs under comparision operators it says
(= nil nil) # true -- nil always equal to itself and only itself

However, I find if I do something like
(= (string/find "foo" "bar") 0) this will return true

Switching it up to the following works as expected.
(= 0 (string/find "foo" "bar"))

[bakpakin]

What platform are you on? Cannot reproduce on my machine.

Janet 1.31.0-local windows/x64/msvc - '(doc)' for help
repl:1:> (= 0 (string/find "foo" "bar"))
false
repl:2:> (= 0 (string/find "foo" "bar") 0)
false
repl:3:> (= (string/find "foo" "bar") 0)
false
repl:4:>

[oadbd]

[bidulock]

I did just try compiling the latest version also with the same results.

Janet 1.31.0-910b9cf1 macos/aarch64/clang - '(doc)' for help
repl:1:> (= nil 0)
true
repl:2:>

Just trying out a few other releases a bit randomly 1.15.0 has the same result, but 1.0.0 seems to work

Janet 1.0.0-d66f8333  Copyright (C) 2017-2019 Calvin Rose
janet:0:> (= nil 0)
false
janet:10:>

Since the expected behaviour is (= nil 0) to be false, I can spend some time tomorrow bisecting this to find the commit that introduced it and create an issue in github if that helps.

[ianthehenry]

It looks like eqim/neqim don't check the type of the LHS, and on platforms without nanboxing casting nil to a double gives you numeric zero -- (= false 0) is also true for the same reason. If you don't use an immediate 0 it works as expected -- e.g. (= nil (- 1 1)) is false. With nanboxing I think this is always safe because there's no way to write an immediate NaN.

(I think if you could figure out how to write the floating point number represented by 0x1 as a Janet literal you could get (= true ...) to give you the wrong result too... which would be kinda fun but not worth figuring out how to print the full decimal expansion...)

[sogaiu]

May be these are the lines in question (just following up on ianthehenry's analysis)?

janet/src/core/vm.c

Lines 863 to 865 in 910b9cf

	VM_OP(JOP_EQUALS_IMMEDIATE)
	stack[A] = janet_wrap_boolean(janet_unwrap_number(stack[B]) == (double) CS);
	vm_pcnext();

janet/src/core/vm.c

Lines 871 to 873 in 910b9cf

	VM_OP(JOP_NOT_EQUALS_IMMEDIATE)
	stack[A] = janet_wrap_boolean(janet_unwrap_number(stack[B]) != (double) CS);
	vm_pcnext();

[oadbd]

I did run a bisect and I believe the issue shows up in this commit aefde67

Making this change does fix the issue, but I doubt this is the real fix, as it looks like @ianthehenry and @sogaiu have already narrowed things down. But I'll leave this here if it helps.

index 46ecfeb0..4a211293 100644
--- a/src/core/cfuns.c
+++ b/src/core/cfuns.c
@@ -349,7 +349,7 @@ static JanetSlot do_lte(JanetFopts opts, JanetSlot *args) {
     return compreduce(opts, args, JOP_LESS_THAN_EQUAL, 0, 0);
 }
 static JanetSlot do_eq(JanetFopts opts, JanetSlot *args) {
-    return compreduce(opts, args, JOP_EQUALS, JOP_EQUALS_IMMEDIATE, 0);
+    return compreduce(opts, args, JOP_EQUALS, 0, 0);
 }
 static JanetSlot do_neq(JanetFopts opts, JanetSlot *args) {
     return compreduce(opts, args, JOP_NOT_EQUALS, JOP_NOT_EQUALS_IMMEDIATE, 1);

[bakpakin]

Should be fixed in 7b4c3bd