Does JavaScript have undefined behaviour?
Does JavaScript have undefined behaviour (similar to C) or is it completely well-defined by the spec, and deterministic?
Note that I am discarding implementation bugs and spec divergences. I am also discarding stuff like Math.random() and Date.now().
Is there a piece of JavaScript code for which the behaviour is not completely determined by the JavaScript specifications, and, as such, has "undefined behaviour"?
Solution 1:
There's a lot of things in the spec that are explicitly left to the implementation. Especially when it comes to Host Objects, there can be many quirks. Examples that have nothing to do with host objects:
15.1 The Global Object
The values of the [[Prototype]] and [[Class]] internal properties of the global object are implementation-dependent.
15.1.2.2 parseInt (string , radix)
[If there are too many significant digits] mathInt may be an implementation-dependent approximation to the mathematical integer value that is represented by Z in radix-R notation.
15.3.4.2 Function.prototype.toString
An implementation-dependent representation of the function is returned.
Nearly all Date parse / stringifiy algorithms are implementation-dependent, this includes toLocaleString, toString, parse and the Date constructor.
15.4.4.11 Array.prototype.sort (comparefn) - likely the best example:
If comparefn is not undefined and is not a consistent comparison function for the elements of this array, the behaviour of sort is implementation-defined.
[…] If proto is not null and there exists an integer j such that all of the conditions below are satisfied then the behaviour of sort is implementation-defined:
- obj is sparse (15.4)
- 0 ≤ j < len
The behaviour of sort is also implementation defined if obj is sparse and any of the following conditions are true:
- The [[Extensible]] internal property of obj is false.
- Any array index property of obj whose name is a nonnegative integer less than len is a data property whose [[Configurable]] attribute is false.
The behaviour of sort is also implementation defined if any array index property of obj whose name is a nonnegative integer less than len is an accessor property or is a data property whose [[Writable]] attribute is false.
And most promiently:
Perform an implementation-dependent sequence of calls […]
15.5.4.9 String.prototype.localeCompare (that)
The two Strings are compared in an implementation-defined fashion
15.5.4.11 String.prototype.replace [In replacement symbols, if the number is greater than the number of groups], the result is implementation-defined.
I'll just stop listing here, you can search on through the spec. Other notable places may be the toLocaleString methods, or the implementation-dependent approximations returned by the Math methods.
Solution 2:
I found few example, quoting of ECMAScript Language Specification (emphasis mine):
8.5 The Number Type
In some implementations, external code might be able to detect a difference between various Not-a-Number values, but such behaviour is implementation-dependent; to ECMAScript code, all NaN values are indistinguishable from each other.
15.7.4.5 Number.prototype.toFixed (fractionDigits)
If the toFixed method is called with more than one argument, then the behaviour is undefined (see clause 15).
15.7.4.6 Number.prototype.toExponential (fractionDigits)
If the toExponential method is called with more than one argument, then the behaviour is undefined (see clause 15).
15.7.4.7 Number.prototype.toPrecision (precision)
If the toPrecision method is called with more than one argument, then the behaviour is undefined (see clause 15).
15.9.4.3 Date.UTC (year, month [, date [, hours [, minutes [, seconds [, ms ] ] ] ] ] )
When the UTC function is called with fewer than two arguments, the behaviour is implementation-dependent.