Like == but more strict. The == operator will do type conversion, so 0 == '' will actually be true, as an example. Sometimes (honestly, most times) you may want to compare more strictly.
The short answer is that your language needs === when it fucked up the semantics of ==, but it’s also too popular and you can’t fix it without breaking half the web.
It’s also important if you’re checking hashes (at least, it was - if you’re using correct hashing algorithm that isn’t ancient, you will not have this problem).
Because if you take for example “0e462097431906509019562988736854” (which is md5(“240610708”), but also applicable to most other hashing algorithms that hash to a hex string), if(“0e462097431906509019562988736854” == 0) is true. So any other data that hashes to any variantion of “0e[1-9]+” will pass the check, for example:
I did use md5 as an example because the strings are pretty short, but it’s applicable to a whole lot of other hashes. And the problem is that if you use one of the strings that hash to a magic hash in a vulnerable site, it will pass the password check for any user who’s password also hashes to a magic hash. There’s not really a high chance of that happening, but there’s still a lot of hashes that do hash to it.
I still don’t understand the
===
operator==
but for JavaScript. What you don’t understand is the==
of JavaScript.> 1 == 1 true > 1 == '1' true > 1 === '1' false
(from node REPL)
Basically it’s the real equals sign
Like
==
but more strict. The==
operator will do type conversion, so0 == ''
will actually be true, as an example. Sometimes (honestly, most times) you may want to compare more strictly.See this StackOverflow answer: https://stackoverflow.com/questions/359494/which-equals-operator-vs-should-be-used-in-javascript-comparisons
JS’s
==
has some gotchas and you almost never want to use it. So===
is what==
should have been.All examples are true:
"1" == true [1, 2] == "1,2" " " == false null == undefined
It isn’t that insane. But some invariants that you may expect don’t hold.
"" == 0 "0" == 0 "" != "0"
The other comments explains it in pretty good detail, but when I was learning my teacher explained it sort of like a mnemonic.
1 + 1 = 2 is read “one plus one equals two”
1 + 1 == 2 is read “one plus one is equal to two”
1 + 1 === 2 is read “one plus one is really equal to two”
And you hit the nail on the head, is that === is type explicit while == is implicit.
I’d use something like:
= becomes
== equals
=== is identical to
It’s funny how everyone thinks “equals” in this context should be “identical to” when, in normal language, it doesn’t really mean that at all!
The short answer is that your language needs === when it fucked up the semantics of ==, but it’s also too popular and you can’t fix it without breaking half the web.
It’s also important if you’re checking hashes (at least, it was - if you’re using correct hashing algorithm that isn’t ancient, you will not have this problem).
Because if you take for example “0e462097431906509019562988736854” (which is md5(“240610708”), but also applicable to most other hashing algorithms that hash to a hex string), if(“0e462097431906509019562988736854” == 0) is true. So any other data that hashes to any variantion of “0e[1-9]+” will pass the check, for example:
I did use md5 as an example because the strings are pretty short, but it’s applicable to a whole lot of other hashes. And the problem is that if you use one of the strings that hash to a magic hash in a vulnerable site, it will pass the password check for any user who’s password also hashes to a magic hash. There’s not really a high chance of that happening, but there’s still a lot of hashes that do hash to it.
that is terrifying
So in JavaScript there’s the assignment
and the comparator is
Since there’s no types JS will do implicit conversion before comparison when using == in a case like this
But with === it doesn’t. It means literally compare these
But this, however, will
Best answer. Thanks Lemmyoverflow.
Np. closed as duplicate
It’s like the ==, but there’s one more =