#4873 issue fixed

[rezwanahmedsami]

Fixed: #4873

[laytan]

This is not correct, == on strings does not just check the pointer, but also the content.

[rezwanahmedsami]

This is not correct, == on strings does not just check the pointer, but also the content.

what you think ?

What will be the correct way?

[laytan]

Also check the content?

[laytan]

Or error in the frontend that this is not a valid thing

[rezwanahmedsami]

Or error in the frontend that this is not a valid thing

If you can give me an explanation, what can be wrong?

Then it will be easy for me to catch it.

Because I stay busy with office work most of the time.

So I can't get much time to investigate it.

So, can you help me with that?

Just point out the right thing for me.

[laytan]

I'm going to close this because I am not interested in holding your hand here

[FourteenBrush]

This is not correct, == on strings does not just check the pointer, but also the content.

@laytan in this case a comparison is being made between an array and the nil value of an array (all zeroes) (lb_emit_comp_against_nil). Even though the array might store strings, we should still emit a memcmp 0 over the whole array right?

Could this be reopened if so?

[laytan]

Ah you are right, my bad, I didn't clock that this was only for comparing against nil.

[laytan]

One thing that would still be inconsistent here is that str == "" doesn't care about the pointer, just the length.

For example:

val := transmute(string)runtime.Raw_String{
	data = auto_cast uintptr(0xDEADBEEF),
	len  = 0,
}
assert(val == "")

holds true, no assertion, while with this patch, this would assert:

vals := [1]string{val}
assert(vals == "")

So this may still not be correct.

[FourteenBrush]

Hmm I see that counts for other types too, consider an array of maps, dynamic arrays etc, those also only check their data pointer So yes sadly still incorrect

EDIT: never mind, these types are not simply comparable