JavaScript Puzzlers!

JavaScript Puzzlers: Puzzles to Make You Think (and write fewer bugs)
Charles Bihis | Computer Scientist

© 2013 Adobe Systems Incorporated. All Rights Reserved. Adobe Confidential. 1

Who am I?

 Charles Bihis
 Computer Scientist
 Adobe Identity Team

 Blog: blogs.adobe.com/charles
 Twitter: @charlesbihis
 GitHub: github.com/charlesbihis


What can I expect?

 What are we going to talk about?  What are we NOT going to talk about?
 Puzzlers!  3rd- party libraries or frameworks
 Maximus the Confused!  e.g. jQuery, Node.js, etc.
 Block Party!
 That’s Odd!  Bugs
 Let’s Print Some ZIP-Codes!
 Say What?!
 Loopty Loop!
 A Case of Mistaken Identity
 Why Are We Bankrupt?!

 Will deal with only pure JavaScript
 (i.e. no libraries!)


What is a Puzzler?

A Puzzler is a very simple programming puzzle that demonstrates or exploits
weird behaviours and quirky edge-cases of a given programming language.


How does this work?

1. Code – I introduce the code.

2. Question – I pose a multiple-choice question and you guess what the
answer is…think hard!

3. Walkthrough – I walk through a reasonable explanation.

4. Answer – I tell you the real answer.

5. Moral – How can you avoid making mistakes like this in your own code.


JavaScript Puzzler – Maximus the Confused!

var commodusRule = 'thumbsUp';
alert('Maximus the ' + (commodusRule === 'thumbsUp') ? 'Gladiator' : 'Merciful');

What does this print?

a) Maximus the Gladiator c) Error

b) Maximus the Merciful d) None of the above

 prints only "Gladiator"


But why?

 Order of operations dictates that the binary “+” operator takes precedence over the conditional “?”
operator.

'Maximus the ' + (commodusRule === 'thumbsUp') ? 'Gladiator' : 'Merciful';

*Reference: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Operators/Operator_Precedence

But why?

operator.

'Maximus the true' ? 'Gladiator' : 'Merciful';


But why?

operator.

'Gladiator';


But why?

operator.

'Gladiator';

 According to the MDN (Mozilla Developer Network), the binary “+” operator has a precedence of 6
while the conditional “?” operator has a precedence of 15.

 Note: This is below MOST commonly used operators (i.e. “*”, “/”, “%”, “<“, “>>” “!=”, “===“, etc).


JavaScript Puzzler – Maximus the Confused…FIXED!

alert('Maximus the ' + (commodusRule === 'thumbsUp') ? 'Gladiator' : 'Merciful');


JavaScript Puzzler – Maximus the Confused…FIXED!

alert('Maximus the ' + (commodusRule === 'thumbsUp' ? 'Gladiator' : 'Merciful'));


Moral

 Be aware of order-of-operations!

 Be explicit and place parenthesis accordingly to ensure correct
and predictable order of execution.


JavaScript Puzzler – Block Party!

// global var
var name = "World!";

(function() {
// check if "name" defined a) “Hello, World!”
if (typeof name === "undefined") {
// local "shadow" var b) “Hello, Mr. Bond.”
var name = "Mr. Bond.";
alert("Hello, " + name);
c) “Hello, ”
} else {
} d) None of the above

})();


But why?

1. No block scope!

for (var i = 0; i < MAX; i++)
{
// do something
}
alert(i); // Note: "i" exists here!

2. “Hoisting”

alert(i); // Note: "i" exists here too!
{
// do something
}


But why?

1. No block scope!

{
// do something
}
alert(i); // Note: "i" exists here!

2. “Hoisting”
var i;
alert(i); // Note: "i" exists here too!
for (i = 0; i < MAX; i++)
{
// do something
}

JavaScript Puzzler – Block Party…FIXED!

// global var

(function() {
// check if "name" defined
// local "shadow" var
} else {
}
})();



// global var

(function() {
var name; // declaration hoisted here
// local "shadow" var
name = "Mr. Bond."; // assignment remains here
} else {
}
})();



// global var

(function() {
} else {
}
})();


Moral

 There is no block-level scoping in JavaScript

 Declare ALL of your variables at the top of your function


JavaScript Puzzler – That’s Odd!

(function(){
var values = [7, 4, '13', Infinity, -9];
for (var i = 0; i < values.length; i++) {
if (isOdd(values[i])) {
alert(values[i]); a) 7, 13
}
} b) 7, 13, Infinity, -9
})();

c) 7, -9
function isOdd(num) {
return num % 2 == 1;
} d) 7, 13, -9


But why?

 Let’s take a closer look…

7 % 2 = 1 // displays
4 % 2 = 2 // does NOT display
13 % 2 = 1 // displays
Infinity % 2 = NaN // does NOT display
-9 % 2 = -1 // does NOT display


But why?

 -9 % 2 = -1? Really?

 JavaScript shares the same behavior as the Java implementation of the modulus (%) operator.
That is, it must satisfy the following identity function for all integer values a and non-zero integer
values b.

(a / b) * b + (a % b) == a

 A side-implication of this behavior is that the result will have the same sign as the left operand!


JavaScript Puzzler – That’s Odd…FIXED!

(function(){
alert(values[i]);
}
}
})();

return num % 2 == 1;
}


JavaScript Puzzler – That’s Odd…FIXED!

(function(){
alert(values[i]);
}
}
})();

return num % 2 != 0;
}


Moral

 Be careful about the signs of operands when using the modulus
operator.


JavaScript Puzzler – Let’s Print Some ZIP Codes!
// array of 5 valid zip-codes
var zipCodes = new Array("93021", What does this print?
"02392",
"20341", a) 93021
"08163", 19
 Firefox
20341
"32959"); 32959

// let's do something with each zip-code b) 93021
// for now, display them 2392
20341  Chrome
for (var i = 0; i < zipCodes.length; i++) {
8163
32959
// sanity check
if (!isNaN(parseInt(zipCodes[i])) && c) 93021
parseInt(zipCodes[i]) > 0) { 20341
alert(parseInt(zipCodes[i])); 32959
}
d) It varies

}

But why?

 Syntax

var num = parseInt(string, radix); // "radix" is optional

 When you omit the optional “radix” parameter, the following behavior takes place:
 If the input string begins with “0x” or “0X”, radix of 16 is used (i.e. hexadecimal)
 If the input string begins with “0”, radix 8 is used (i.e. octal) OR radix 10 is used (i.e. decimal)
 If the input string begins with any other values, radix 10 is used (i.e. decimal)

 Particularly when dealing with string values with leading 0’s, Mozilla had this to say…

Exactly which radix is chosen is implementation-dependent.
For this reason ALWAYS SPECIFY A RADIX WHEN USING parseInt.

*Reference: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/parseInt

But why?

 Another important note about the parseInt() API…

If parseInt encounters a character that is not a numeral in the
specified radix, it ignores it and all succeeding characters
and returns the integer value parsed up to that point.

 A closer look…

parseInt("93021") = 93021 // displays
parseInt("02392") = (2 * 8) + (3 * 1) = 19 // displays
parseInt("08163") = 0 // does NOT display

*Reference: https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/parseInt

JavaScript Puzzler – Let’s Print Some ZIP Codes…FIXED!
var zipCodes = new Array("93021",
"02392",
"20341",
"08163",
"32959");

// let's do something with each zip-code
// for now, display them

// sanity check
if (!isNaN(parseInt(zipCodes[i])) &&
parseInt(zipCodes[i]) > 0) {
alert(parseInt(zipCodes[i]));
}

}

JavaScript Puzzler – Let’s Print Some ZIP Codes…FIXED!
var zipCodes = new Array("93021",
"02392",
"20341",
"08163",
"32959");

// let's do something with each zip-code
// for now, display them

// sanity check
if (!isNaN(parseInt(zipCodes[i], 10)) && // radix value added
parseInt(zipCodes[i], 10) > 0) { // here too
alert(parseInt(zipCodes[i], 10)); // and here too
}

}

Moral

 parseInt() takes an optional radix parameter.

 Omitting this optional parameter will cause unpredictable
behavior across browsers.

 Be explicit and ALWAYS include the radix parameter.


JavaScript Puzzler – Say What?!

function sayHello(name) {
alert('Hello, ' + name);
}

sayHello('</script><script>alert("BOOM!");</script>');


a) alert("BOOM!“);

b) Hello, </script><script>alert("BOOM!");</script>

c) BOOM!

d) Error


But why?

 Let’s take a look at the code again…

}



But why?


<script>
}

</script>

 When a browser renders a page, first the HTML parser will parse the page and tokenize out all of
the tags.
 Only after this is done, will it then allow the JavaScript parser to tokenize and execute whatever
tokens the HTML parser believes are JavaScript scripts!


But why?


<script>
}

</script>

 Armed with this knowledge, we can see that the HTML parser will send 2 scripts to the JavaScript
parser to tokenize and execute…
 <script>function sayHello(name) { alert('Hello, ' + name); } sayHello('</script>
 <script>alert("BOOM!");</script>


A closer look

 Again, the HTML parser will send these two script tags to the JavaScript parser…
 <script>function sayHello(name) { alert('Hello, ' + name); } sayHello('</script>
 <script>alert("BOOM!");</script>

 If that name parameter is user-controlled, perhaps taken as input from the browser, or pulled from
a datasource, whatever, then this is an open invitation for XSS attacks!

 Errors like this can expose huge security holes which may allow an attacker to potentially take
over a user’s browser!


JavaScript Puzzler – Say What?!...FIXED!

 In this particular case, the fix must be done on the server-side.

 We want to eliminate the <script></script> tags from appearing in the source in the first place.

 Suggested solution is to use the OWASP ESAPI APIs…
 Stands for “The Open Web Application Security Project” “Enterprise Security API”
 https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
 Have API bindings in all major languages including…
 Java
 Dot NET
 PHP
 JavaScript
 Python
 PHP


JavaScript Puzzler – Say What?!...FIXED!

 For this particular Puzzler, we want to use ESAPI.encoder().encodeForJavaScript()

 Doing this on the server to JavaScript-encode the user-inputted variable, name, we get what we
expect…


Moral

 NEVER . TRUST . THE . USER

 Validate your input.

 Encode your output appropriately.
 i.e. HTML-encode for HTML
URL-encode for URLs
JavaScript-encode for JavaScript
etc.

 Use standard libraries (i.e. don’t reinvent the wheel).


JavaScript Puzzler – Loopty Loop!

var END = 9007199254740992; // Math.pow(2, 53)
a) 0
var START = END - 100;

var count = 0; b) 100
for (var i = START; i <= END; i++) {
count++;
c) 101
}
alert(count);
d) None of the above
 enters infinite loop


But why?

 9007199254740992 is a special number. Particularly, it is 2^53.

 Why is this special?

 First, we need to know something about how JavaScript represents numbers.

*Reference: http://ecma262-5.com/ELS5_HTML.htm#Section_8.5

But why?

 JavaScript numbers abide by the IEEE Standard for Floating-Point Arithmetic (IEEE 754).

 As such, all numbers in JavaScript are represented by double-precision 64-bit floating point
values…
exponent

-4
1.2345 = 12345 x 10

mantissa

 In binary… 63 62 53 52 0

1 11...111 11111111111...111

sign exponent mantissa

But why?

 2^53 is the largest exact integral value that can be represented in JavaScript!

 From the ECMA specification…

Note that all the positive and negative integers whose magnitude
is no greater than 2^53 are representable in the Number type.

 What does this mean?

var numA = Math.pow(2, 53);
var numB = numA + 1;
alert(numA === numB); // true!


JavaScript Puzzler – Loopty Loop…FIXED!

var END = 9007199254740992; // Math.pow(2, 53)
var START = END - 100;

var count = 0;
count++;
}
alert(count);


JavaScript Puzzler – Loopty Loop…FIXED!

var START = 0;
var END = 100;

var count = 0;
count++;
}
alert(count);


Moral

 Be aware of your number representations and number ranges!

 There are REAL limitations imposed by your computer. When
dealing with large (or important) numbers, know them!


JavaScript Puzzler – A Case of Mistaken Identity!

function showCase(value) {
switch(value) {
case "A": What does this print?
alert("Case A was selected.");
break;
case "B": a) Case A was selected.
alert("Case B here!");
break;
case "C": b) This is Case C.
alert("This is Case C.");
break;
default:
c) Error
alert("Don't know what happened.");
break;
}
} d) Don’t know what
happened.
showCase(new String("A"));


But why?

 The switch statement in JavaScript internally uses the strict equality operator (i.e. ===) as opposed
to the non-strict equality operator (i.e. ==).

 The strict equality operator behaves exactly as the non-strict version, except that no type-
conversions are done.

 So, when the switch statement evaluates equality, it checks that the following are true…
 Their types are equal
 Their uncast values are equal

 Notice, we invoked showCase() with a new String object.

alert(typeof "A"); // "string"
alert(typeof new String("A")); // "object"


JavaScript Puzzler – A Case of Mistaken Identity…FIXED!

switch(value) {
case "A":
break;
case "B":
break;
case "C":
break;
default:
break;
}
}

showCase(new String("A"));


JavaScript Puzzler – A Case of Mistaken Identity…FIXED!

switch(value) {
case "A":
break;
case "B":
break;
case "C":
break;
default:
break;
}
}

showCase("A");


Moral

 Get used to using the strict equality operator when possible. It will make you more aware of type
conversions and true equalities.

 From Douglas Crockford’s book “JavaScript: The Good Parts”…

JavaScript has two sets of equality operators: === and !==, and their evil twins == and !=.
The good ones work the way you would expect. The evil twins do the right thing when the
operands are of the same type, but if they are of different types, they attempt to coerce the
values, the rules by which they do that are complicated and unmemorable.


JavaScript Puzzler – Why Are We Bankrupt?!

var costOfCandy = 0.60; // 60 cents a) 0

function calculateChange(cost, paid) {
return paid - cost; b) 0.2
}
c) 0.20
// pay for candy with 80 cents
alert(calculateChange(costOfCandy, 0.80));
d) None of the above

 0.20000000000000007


But why?

 As we learned from a previous Puzzler, all JavaScript numbers use the IEEE 754 floating-point
arithmetic specification.

 Because of this, values are not represented exactly, but rather as a fraction.

 Some non-integer values simply CANNOT be expressed exactly in this way. They must be
approximated.

Example:
123.45 = 12345 * 10^-2 // exact
1 / 3 = 0.333333333333333 * 10^0 // approximation!


JavaScript Puzzler – Why Are We Bankrupt?!...FIXED!

var costOfCandy = 0.60; // 60 cents

return paid - cost;
}

alert(calculateChange(costOfCandy, 0.80));


JavaScript Puzzler – Why Are We Bankrupt?!...FIXED!

// Use only integer math when dealing with money! To do this,
// represent your money in terms of cents to begin with!
//
// e.g. use 1599 instead of 15.99 to represent $15.99

var costOfCandy = 60; // 60 cents

return paid - cost;
}

alert(calculateChange(costOfCandy, 80));


Moral

 Floating-point arithmetic can be inaccurate when representing fractions.

 When dealing with money, deal in terms of cents! This makes all of your calculations integer-
calculations, which are exact!

 Not completely exact, though…

 Remember from our last Puzzler, it is exact only up until the largest representable integer value…
 9007199254740992 (i.e. 2^52)

 So, as long as you are dealing with less than $9 quintillion, you’re fine using integer arithmetic in
JavaScript :)

*Reference: http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html

That’s it!

Questions?


Any favorites?

 Puzzlers!
 Maximus the Confused!

 Block Party!

 That’s Odd!

 Let’s Print Some ZIP-Codes!

 Say What?!

 Loopty Loop!

 A Case of Mistaken Identity

 Why Are We Bankrupt?!


Thanks for coming!

 Charles Bihis
 Computer Scientist
 Adobe Identity Team

 Blog: blogs.adobe.com/charles
 Twitter: @charlesbihis
 GitHub: github.com/charlesbihis


JavaScript Puzzlers!

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a JavaScript Puzzlers!

Semelhante a JavaScript Puzzlers! (20)

Último

Último (20)

JavaScript Puzzlers!