Why is Javascript unsafe?

Why is Javascript unsafe?

Attached: js-logo-badge.png (512x512, 27K)

Other urls found in this thread:

en.wikipedia.org/wiki/ECMAScript#Versions
github.com/getify/You-Dont-Know-JS/blob/master/types & grammar/ch4.md#sanity-check
twitter.com/SFWRedditGifs

It's as safe as the environment running it

Unsafe in what sense?

>JS is as safe as the Congo basin

Everyone here says it's unsafe, why is that?

Because they take the Dinglebop and they smooth it out with a bunch of Schleem, The Schleem is then repurposed for later batches.

xD

Javashit is inherently unsafe because it allows any website you visit to cause your browser to execute machine code, albeit in a virtual machine. If your VM is bug-free, then there's nothing to worry about, but no VM is bug-free. Therefore, it's inherently unsafe.

Javascript is perfectly safe. Niggerbrowsers like Chome are unsafe.

0.1 + 0.2 === 0.3

>your browser will execute whatever the fuck code a website throws at it

Gee OP, i wonder how can that ever go wrong..

navigator.geolocation.getCurrentPosition(position => console.log(position));

Nope, can't run this code without the user consent.

ITT: people who don't know the difference between w3c APIs and a VM + scripting language with bindings for that API
this issue is totally unrelated to the scripting language itself
>I am 12 and don't know how floating point numbers work

Attached: 1523053220448.png (563x861, 575K)

It is fucking malicious. In any use.
It can be used in webpages for completely malicious things, but it's use is malicious in general. It's slow and is the prime langauge to use to program bloatware.

That makes sense if you understand how the language works.

0 == "0"


The 0 gets type coerced into a string since you're comparing it to a string. If you did === then it would be false (since no type coercion).

0 == []

Again type coercion. 0 is a "falsy" value, as is a null array.

"0" == []


It's type coerced into a string, so you have "0" == "" which is false.

>language has two methods of checking if values are equal
>both are built for different purposes
>one is built to ignore value type and generally known to be not secure if type of value is important in any check
>other one is specifically built to deal with those kinds of situation

It's like you fucking complain that \n and \t both are space characters

No it doesn't you fucking retard, no sane language should allow coercion, it should always compare the truthiness of both sides of the types mismatch

JavaScript (ES7) is only as safe as the browser and the environment it runs in. This is true among many other languages.

>it should always compare the truthiness of both sides of the types mismatch
So 4 == 7.5 should be true in "sane" languages that have distinct integer and floating point types? They are of different types and are both truthy, so according to you the result should be true.

there is no ES7... the naming scheme got changed to year numbers

I get all those case scenarios, but how come [] == false is true, but if ([]) {/* code */} will run the code when [] is supposed to be false?

There is ES7, and there is ES8 too.

There is a specific syntax for an exact true and not truthy match you fucking mongoid

wrong
en.wikipedia.org/wiki/ECMAScript#Versions

Because it's java

This is true in any language.

Incorrect and misleading. You can only execute code in the browser environment. You can't arbitrarily starting deleting files from a user's file system, for example.

Not confusing if you know the type coercion rules.

because you use it.

>type coercion rules.

Why is that even a thing?

>hurr just use ===
Why does === even exist? Java doesn't need it. C++ doesn't need it. The fact that this shitty operator exists is proof of the awfulness of JS.

According to the standard, empty arrays (and all other arrays) are truthy, so that if statement is expected behavior.

The == operator on the other hand does not use the truthiness of a value when comparing it to a boolean. The == doesn't actually give a shit about truthiness at all, and is defined by several really annoying sections of the ECMAScript standard. When comparing an object to a boolean, the == operator will convert the object to a primitive, and convert the boolean to a number. The ToPrimitive process will first run the valueOf method on the array, notice that the result is still [] which is still an object, and discard that result and move on to calling toString(), which arrays override to be .join(), which for an empty array will return an empty string. The ToNumber process for false obviously results in 0. Now the comparison is '' == 0. Comparing strings to numbers is defined to convert to comparing the ToNumber of the string against the number. ToNumber of an empty string is 0. The comparison is now 0 == 0. Since both have the same type, the comparison is defined to convert to strict equality, and we're finally left with 0 === 0 which is true

A more concise list of conversions to explain what happens in [] == false

([] == false) // Given
(ToPrimitive([]) == toNumber(false)) // (Object == Boolean) -> (ToPrimitive(Object) == ToNumber(Boolean))
('' == 0) // (ToPrimitive([]) -> ''), (ToNumber(false) -> 0)
(ToNumber('') == 0) // (String == Number) -> (ToNumber(String) == Number)
(0 == 0) // (ToNumber('') -> 0)
(0 === 0) // (Number == Number) -> (Number === Number)
true // (0 === 0) -> true

sed -i / == / ===/g *

Wow javascript so hard.

Lol getting consent from a user is like getting consent from your sister; it's easy.

how does it choose what type to convert to for coercion?
In the first one, it seems to choose the right operand's type.
"Falsy" seems to imply an integral value, so an integer or another primitive, which would mean the second example shows it choosing the left operand's type.
In the third one, coercion chooses string, so it's using the left operand's type.

Are there rules for what type it chooses? Why do those rules require something as hand-wavey as "falsy?"

>how does it choose what type to convert to for coercion?
The ECMAScript standard defines a set of rules for it in section 7.2.14
>In the first one, it seems to choose the right operand's type.
It's actually "choosing" the left operand's type. Much of what said is wrong. The standard says that if the left operand is a number and the right operand is a string, the right operand is converted to a number and the comparison is performed that way.
>"Falsy" seems to imply an integral value
The loose comparison operator does not use the concept of "falsy" at all.
>the second example shows it choosing the left operand's type
The second example triggers section 7.2.14 rule 8, which defines behavior for comparing a left hand side number/string to a right hand side object. The rule demands that the object be converted to a primitive (the array becomes an empty string). The result then triggers the same rule as the first example, which further transforms the empty string into a number (empty string becomes 0)
>In the third one, coercion chooses string
Same rule as second example. String compared to object results in the object being converted to a primitive, which turns the array into an empty string

You'll get a lot more milage out of actually reading the standard than trying to guess what's happening or listening to people who don't know what they're talking about.

>Are there rules for what type it chooses?
yes
>Why do those rules require something as hand-wavey as "falsy?"
they don't, and also "falsey" is strictly defined. It's not hand-wavy.

>This is true in any language.
It's not true in any language with a proper numeric tower, like Lisp.

>needing to understand a complex set of rules to predict how == works
May as well use brainfuck at that point

Oh
As I was my teachers call it ES7 old habits my bad

Or you could just not attempt nonsensical comparisons if you don't want to learn how the language handles them

>needing to make up a word for "false, but not actually" isn't hand-wavey
>>>/wdg/
back to your containment thread

>needing to make up a word for "false, but not actually"
The standard itself never uses the word "falsey". "falsey" is a strictly defined word that refers to any element in the set of all possible values that result in false when used as an argument to the standard-defined abstract ToBoolean routine. That set is {undefined, null, false, +0, -0, NaN, ''}. All other values are defined to be truthy.
"falsey" isn't "false but not really". It's "any value which results in false when coerced to a boolean". 0 and null are "falsey" in C.

underrated

you should add to this the rule to never compare something to false

github.com/getify/You-Dont-Know-JS/blob/master/types & grammar/ch4.md#sanity-check

I wish people would read a book once in a while.

Attached: for-the-retards.png (853x960, 793K)