DEV Community: Piotr Zarycki

Infinity - Where Does JavaScript End?

Piotr Zarycki — Sun, 15 Feb 2026 18:49:27 +0000

## Infinity - Where Does JavaScript End?

Where limits end but sequences continue - there begins infinity!

But to know exactly what we're dealing with, let's use the typeof operator to find out what data type we have!

typeof Infinity // "number"

Let's look at the first case of Infinity

1 / 0 //Infinity
1 / -0 //-Infinity

Why does this happen?

It stems from the mathematical concept of limits:

\lim_{x \to 0^+} \frac{1}{x} = +\infty

\lim_{x \to 0^-} \frac{1}{x} = -\infty

When we divide by a number approaching zero from the positive side

0^+

the result grows to

+∞+\infty

When we divide by a number approaching zero from the negative side

0^-

the result decreases to

−∞-\infty

JavaScript distinguishes between +0 and -0, which is why 1/0 gives Infinity, and 1/-0 gives -Infinity.

As you can see - it didn't take much effort to see this case in action.

Let's try to find it then :)

let value = 1;

while (value !== Infinity) {
  let next = value * 2;

  if (next === Infinity) {
    console.log('Last value:', value.toExponential());
    console.log('Next value:', next);
    break;
  }

  value = next;
}

Output:

Last value: 8.98846567431158e+307
Next value: Infinity

As you can see - finding infinity isn't that hard - JavaScript makes it much easier by providing the maximum value before entering Infinity instead of tedious and inefficient iteration:

Number.MAX_VALUE

Output:

1.7976931348623157e+308

What does 1.7976931348623157e+308 before infinity (Infinity) represent?

179,769,313,486,231,570,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000,000,000,000,000,000,000,000,000,000,000,
000,000,000,000,000

This is an unimaginably large number, greater than the number of atoms in the universe

∼1080\sim 10^{80}

or the number of possible chess games

∼10120\sim 10^{120}

Why this particular value? When the standard was defined in 1985, RAM was expensive, and choosing 64 bits for double was a deliberate design decision. This value is sufficient for engineering calculations, most physics simulations, astronomy, and finance.

So it was a good compromise for good precision (15-17 digits), hardware efficiency, and universality (supported by every processor).

IEEE 754 Standard as the Infinity Regulator

The IEEE 754 standard defines both NaN and Infinity, so this is not just a JavaScript feature but also applies to other programming languages!

#include <iostream>
#include <limits>

int main()
{
    double max = std::numeric_limits<double>::max();
    double inf = std::numeric_limits<double>::infinity();

    if (inf > max)
        std::cout << inf << " is greater than " << max << '\n';
}

Output:

inf is greater than 1.79769e+308

Why was inf printed instead of a number?

Infinity is a value that can be represented in bits but doesn't represent any specific numeric value - instead, it represents the concept of mathematical infinity. So if someone wanted to print the raw bits, they would get:

+Infinity = 0x7FF0000000000000
-Infinity = 0xFFF0000000000000

inf is simply more readable and convenient than bit representation, just like Infinity in JavaScript.

Why was this concept introduced in the IEEE 754 standard?

Instead of crashing the program on division by zero or overflow, IEEE 754 gives you a value you can continue working with:

const result = calculate_something();

if (result === Infinity) {
   console.error("Value too large!");
   return Number.MAX_VALUE;
}

Without Infinity - crash or undefined behavior.

Also, thanks to Infinity, we maintain mathematical correctness:

1 / Infinity === 0           // lim(1/x) as x→∞
Infinity + 5 === Infinity    // ∞ + c = ∞
Infinity * Infinity          // ∞ × ∞ = ∞

But beware - some operations with Infinity yield NaN (undefined):

Infinity - Infinity  // NaN (∞ - ∞ is undefined)
Infinity * 0         // NaN (∞ × 0 is undefined)
Infinity / Infinity  // NaN (∞ / ∞ is undefined)

Practical Use Cases

Disabling timeout:

const config = {
    timeout: debugMode ? Infinity : 5000  // no timeout in debug
};

setTimeout(() => {
    console.log('This will never execute');
}, config.timeout);

Note: Some browsers limit timeout to 32-bit int (~24 days max). Infinity may be converted to this value.

Sorting:

const items = [
    { name: 'Alice', priority: 1 },
    { name: 'Bob', priority: 2 },
    { name: 'System', priority: Infinity }  // Always at the end
];

items.sort((a, b) => a.priority - b.priority);

Links:

IEEE 754 - Wikipedia

Why {} !== {}

Piotr Zarycki — Thu, 12 Feb 2026 19:32:45 +0000

An object is not equal to another object

In this post, we'll explore something commonly encountered in programming languages - comparison operators.

In JavaScript, like in other programming languages, we have different data types that we can compare:

"test" === "test"  // true
true === true      // true
1 === 1            // true

But not everything is as obvious as logic would suggest:

{} === {}  // false 🤔
[] === []  // false 🤔

Why does this happen?

Types in JavaScript

JavaScript is a dynamically typed language, so types are "tagged" in memory - after all, there needs to be some way to know what is what. This somewhat relieves the JavaScript programmer from thinking about what type is currently allocated.

There are two main types:

Primitive - immutable, compared by value
Reference - mutable, compared by reference

| Type               | Immutable? | Storage           | Comparison        | Example                     |
|--------------------|------------|-------------------|-------------------|-----------------------------|
| Number (Int32)     | ✅ YES     | Stack (inline)    | By value          | 42 === 42 → true            |
| Number (Float)     | ✅ YES     | Heap (HeapNumber) | By value          | 3.14 → mutation impossible  |
| String             | ✅ YES     | Heap (JSString)   | By value*         | "hello" === "hello" → true  |
| Boolean            | ✅ YES     | Stack (inline)    | By value          | true === true → true        |
| undefined          | ✅ YES     | Stack (inline)    | By value          | undefined === undefined     |
| null               | ✅ YES     | Stack (inline)    | By value          | null === null → true        |
| Symbol             | ✅ YES     | Heap (Symbol)     | By reference      | Symbol() !== Symbol()       |
| BigInt             | ✅ YES     | Heap              | By value*         | 10n === 10n → true          |
|--------------------|------------|-------------------|-------------------|-----------------------------|
| Object             | ❌ NO      | Heap (JSObject)   | By reference      | {} !== {}                   |
| Array              | ❌ NO      | Heap (JSObject)   | By reference      | [] !== []                   |
| Function           | ❌ NO      | Heap (JSFunction) | By reference      | (() => {}) !== (() => {})   |
| Date               | ❌ NO      | Heap (JSObject)   | By reference      | new Date() !== new Date()   |
| RegExp             | ❌ NO      | Heap (JSObject)   | By reference      | /a/ !== /a/                 |
| Map/Set            | ❌ NO      | Heap (JSObject)   | By reference      | new Map() !== new Map()     |

Conclusion: Primitive types are types that cannot be changed (immutable).

But wait... what about `toUpperCase()`?

An inquisitive person might ask - if primitive types are immutable, then how does this relate to:

"test".toUpperCase()  // "TEST"

We can easily investigate this using the %DebugPrint macro available in Node.js with the --allow-natives-syntax flag:

const str = "test";

%DebugPrint(str);
// DebugPrint: 0x36c70031c8c5: [String] in ReadOnlySpace: #test
// type: INTERNALIZED_ONE_BYTE_STRING_TYPE

%DebugPrint(str.toUpperCase());
// DebugPrint: 0x36c70084d251: [String]: "TEST"
// type: SEQ_ONE_BYTE_STRING_TYPE

Notice the difference in addresses:

"test" → 0x36c70031c8c5
"TEST" → 0x36c70084d251

Conclusion: The value was copied to a new location in memory - the immutability principle was preserved!

Semantics vs Implementation

Since string "test" === "test" returns true, how does it work under the hood?

Let's look at the string comparison implementation in the SpiderMonkey engine (Firefox):

bool js::EqualStrings(JSContext* cx, JSString* str1, JSString* str2,
                      bool* result) {
  if (str1 == str2) {
    *result = true;
    return true;
  }
  // ... the rest of the function compares content when pointers differ
  return EqualStringsPure(str1, str2, result);
}

The code above shows an optimization (fast path):

// Case 1: Pointer comparison - O(1)
if (str1 == str2) {  // single CPU instruction!
    return true;
}

// Case 2: Content comparison - O(n)
for (size_t i = 0; i < length; i++) {
    if (str1->chars[i] != str2->chars[i]) {
        return false;
    }
}

This shows the difference between language semantics and implementation:

Level	String	Object
Semantics	Comparison by value	Comparison by reference
Implementation	Optimization: pointers first, then content	Pointers only

String Interning (Atom Table)

Why does "test" === "test" work fast?

JS engines use interning - string literals are stored in a special table (Atom Table in SpiderMonkey). This way, identical literals point to the same object in memory:

Stack:                          Heap (Atom Table):
┌──────────────────────┐        ┌──────────────────────┐
│ s1 → 0x26a432b2c140  │ ──────→│ 0x26a432b2c140:      │
│ s2 → 0x26a432b2c140  │ ──────→│ JSString "test"      │
└──────────────────────┘        │   length: 4          │
                                │   chars: "test"      │
                                └──────────────────────┘

Note: Not all strings are interned! Dynamically created strings (e.g., "te" + "st") may have different addresses - then the engine must compare content O(n).

Back to objects...

Objects and arrays are complex structures that are mutable - they can be modified at any time.

With each definition of a (seemingly empty) object:

{} === {}  // false - ALWAYS!

the engine always allocates a new place in memory for it:

{}  // allocated at address 0x7ffff66f7090
{}  // allocated at address 0x7ffff66f7098 (different address!)

Key takeaway: When comparing objects/arrays, we don't compare their values - only the address in memory, which will be different even for identical-looking objects!

What does the ECMA-262 standard say?

The ECMA-262 standard defines this behavior in the IsStrictlyEqual operation (used by the === operator):

7.2.16 IsStrictlyEqual ( x, y )

1. If Type(x) is not Type(y), return false.
2. If x is a Number, then
       a. Return Number::equal(x, y).
3. Return SameValueNonNumber(x, y).

Where SameValueNonNumber for objects boils down to:

7.2.11 SameValueNonNumber ( x, y )

...
6. NOTE: All other ECMAScript language values are compared by identity.
7. If x is y, return true; otherwise return false.

So for objects, it checks whether x and y are the same object (the same reference in memory), not whether they have the same content.

Summary

Type	Comparison `===`	Why?
Primitives	By value	They are immutable, can be interned
Objects	By reference	They are mutable, each definition = new allocation

That's why {} !== {} - these are two different objects in memory, even if they look identical! :)

Originally published at https://pzarycki.com on February 12, 2026.

Why NaN !== NaN in JavaScript (and the IEEE 754 story behind it)

Piotr Zarycki — Mon, 27 Oct 2025 07:42:27 +0000

A Number That Always Returns the Same Thing

Today we'll look at the NaN type, which in JavaScript is identified as type number.

> typeof NaN
'number'

We get the type number in response.

Since something is a number, logic suggests we can perform mathematical operations on it.

So let's try adding something to it or checking its maximum or minimum value.

> NaN + 1 
NaN
> NaN - 1
NaN
> Math.max(NaN)
NaN
> Math.min(NaN)
NaN

As you can see, after adding, subtracting, checking the maximum and minimum values - we always get the same result.

If that's the case, why do we need such a value?

To try to explain this, let's look into Firefox or V8 to find the usage and implementation of NaN.

// Firefox
bool isNaN() const { return isDouble() && std::isnan(toDouble()); }

// V8 
if (IsMinusZero(value)) return has_minus_zero();
if (std::isnan(value)) return has_nan();

Looking at the code of example browsers, the std::isnan method from the standard library is used to check for NaN, which may already suggest to us that this is something that appeared independently of JavaScript.

And indeed, looking historically, the first standardization of NaN appeared in 1985 and was given the number IEEE 754.

From JavaScript to Hardware Level

Armed with this knowledge, let's write a simple program in C, where based on what we found in the browser code, we'll check how NaN behaves.

> NaN !== NaN
true
> 0 / 0 
NaN

#include <math.h>
#include <stdint.h>
#include <stdio.h>

int main() {
    double x = 0.0 / 0.0;

    if (x != x) {
        printf("NaN is not the same\n");
    }
    if (isnan(x)) {
        printf("x is NaN\n");
    }

    uint64_t bits = *(uint64_t*)&x;

    printf("NaN hex: 0x%016lx\n", bits);

    return 0;
}

The result is the same as in JavaScript!

NaN is not the same
x is NaN
NaN hex: 0xfff8000000000000

We already know that we encounter NaN in other programming languages as well

#Python

import math

nan = float('nan')
print(nan != nan)  # True
print(nan == nan)  # False
print(math.isnan(nan))  # True

//C++

#include <iostream>
#include <cmath>

int main() {
    double nan = NAN;
    std::cout << (nan != nan) << std::endl;  // 1 (true)
    std::cout << (nan == nan) << std::endl;  // 0 (false)
    std::cout << std::isnan(nan) << std::endl;  // 1 (true, proper way)
    return 0;
}

//Rust

fn main() {
    let nan = f64::NAN;
    println!("{}", nan != nan);  // true
    println!("{}", nan == nan);  // false
    println!("{}", nan.is_nan());  // true (proper way)
}

but we still don't know what it's for.

And since we don't know, let's generate assembly code for our modest program (let's skip the prologue and stack frame initialization).

# =====================================
#     double x = 0.0 / 0.0;
# =====================================
    pxor    xmm0, xmm0                 # xmm0 = 0.0
    divsd   xmm0, xmm0                 # xmm0 = 0.0 / 0.0 = NaN
    movsd   QWORD PTR -8[rbp], xmm0    # x = NaN

# =====================================
#     if (x != x) {
# =====================================
    movsd   xmm0, QWORD PTR -8[rbp]    # xmm0 = x
    ucomisd xmm0, QWORD PTR -8[rbp]    # compare x with x (sets PF=1 for NaN)
    jnp .L2                            # skip if NOT NaN (PF=0)
    # NaN detected - code here
.L2:

# =====================================
#     if (isnan(x)) {
# =====================================
    movsd   xmm0, QWORD PTR -8[rbp]    # xmm0 = x
    ucomisd xmm0, QWORD PTR -8[rbp]    # compare x with x (sets PF=1 for NaN)
    jnp .L3                            # skip if NOT NaN (PF=0)
    # NaN detected - code here
.L3:

For those who haven't had contact with assembly - what's worth noting for us is the xmm0 register, which performs operations on floating-point numbers.
Which is logical: we want to perform an operation on numbers, the CPU operates on numbers, so it will be fastest to do this in registers specifically designed for this purpose!

We can also see the ucomisd instruction, which is responsible for setting a flag when it detects NaN.

What conclusion can we draw from this? NaN is implemented at the hardware level, not at the JavaScript abstraction level.

So - rewriting the program in assembly to avoid unnecessary abstractions, let's examine its execution result:

#include <stdio.h>
#include <stdint.h>

int main() {
    double x;
    uint64_t bits;

    __asm__ (
        // double x = 0.0 / 0.0;
        "pxor   xmm0, xmm0\n\t"         // xmm0 = 0.0
        "divsd  xmm0, xmm0\n\t"         // xmm0 = 0.0 / 0.0 = NaN

        // Save results
        "movsd  %0, xmm0\n\t"           // x = NaN
        "movq   %1, xmm0\n\t"           // bits = *(uint64_t*)&x

        : "=m" (x), "=r" (bits)
        :
        : "xmm0"
    );

    int is_not_equal;
    __asm__ (
        // if (x != x)
        "movsd  xmm0, %1\n\t"           // xmm0 = x
        "ucomisd xmm0, %1\n\t"          // compare x with x → PF=1 for NaN
        "setp   al\n\t"                 // al = (x != x)
        "movzx  %0, al\n\t"             // is_not_equal = al

        : "=r" (is_not_equal)
        : "m" (x)
        : "xmm0", "al"
    );

    if (is_not_equal) {                 // if (x != x)
        printf("NaN is not the same\n");
    }

    int is_nan_result;
    __asm__ (
        // if (isnan(x))
        "movsd  xmm0, %1\n\t"           // xmm0 = x
        "ucomisd xmm0, %1\n\t"          // compare x with x → PF=1 for NaN
        "setp   al\n\t"                 // al = isnan(x)
        "movzx  %0, al\n\t"             // is_nan_result = al

        : "=r" (is_nan_result)
        : "m" (x)
        : "xmm0", "al"
    );

    if (is_nan_result) {                // if (isnan(x))
        printf("x is NaN\n");
    }

    printf("NaN hex: 0x%016lx\n", bits);

    return 0;
}

The result?

NaN is not the same
x is NaN
NaN hex: 0xfff8000000000000

The program's output is the same as with high-level C.

We already know that NaN is natively implemented, so let's look at the ucomisd instruction.

"ucomisd xmm0, %1\n\t"          // compare x with x → PF=1 for NaN

ucomisd - or Unordered Compare Scalar Double-precision floating-point. This wonderful instruction saved time and nerves for programmers on the x86 architecture, because at the CPU level it already checks whether the result of operations on numbers is correct or not.

NaN !== NaN

The main reason was to provide programmers with a way to detect NaN using the x != x test in times when the isnan() function didn't yet exist in programming languages.

From a logical point of view, this makes a lot of sense, because a non-value cannot equal a non-value.

This is intentional design, not a bug.

typeof NaN === "number"

NaN is part of the numeric system (IEEE 754), not a separate type. It's a special numeric value signaling a mathematical operation error.

IEEE 754-1985: Standard for Binary Floating-Point Arithmetic

Published: 1985
Author: William Kahan (UC Berkeley) + IEEE committee
Defines: NaN, Infinity, denormalized numbers, rounding modes

Key decisions:

NaN !== NaN (always false when comparing for equality)
Exponent = 0x7FF, mantissa ≠ 0
Quiet NaN (qNaN) - propagates through operations without signaling an exception
Signaling NaN (sNaN) - generates an exception on first use in an operation
NaN propagation (any operation with NaN → NaN)

NaN is a Number, But What Kind?

You might be surprised why floating-point number registers are used for dividing 0/0.

Operations on number type values in JavaScript are represented as double-precision floating-point numbers (double) to perform operations on them according to the IEEE 754 standard.

In integer operations, division by zero is an unambiguous error. However, in floating-point numbers, we have many cases that can lead to undefined results:

0.0 / 0.0 → NaN
∞ - ∞ → NaN
0 * ∞ → NaN
sqrt(-1) → NaN

Without the IEEE 754 standard, each hardware manufacturer dealt with these situations differently, resulting in enormous code portability problems.

1994: Pentium FDIV Bug

A bug in Pentium's floating-point division - some divisions gave incorrect results. It wasn't a problem with NaN, but it showed the importance of precise IEEE 754 implementation.

Intel replaced millions of processors, which cost the company $475 million.

NaN as the Savior of Programmers

We learned that NaN is set at the hardware level, but what was there before NaN?

Before the IEEE 754 standard (1985), each hardware manufacturer did it their own way, which usually meant that operations like 0/0 ended in a crash and program termination.

This required very defensive programming from developers. Imagine you're flying in an airplane, and in the control system, a programmer didn't anticipate 0/0 - the instruction executes on the CPU and crashes the entire program due to a Division Error!

Intel and other manufacturers were fed up with the chaos resulting from programs behaving differently on different architectures.

NaN (Not a Number)

We can ask ourselves why a special value instead of another solution.

Let's consider different options:

Option A: Division Error → CRASH (existing before IEEE 754)

Unexpected program termination (see airplane example)
Requires defensive programming before every operation

Option B: Return, for example, 0

Mathematically incorrect
Masks the error
Further calculations give false results

Option C: Return null or a special error code

Requires checking after every operation
Interrupts the chain of mathematical calculations
The result type becomes inconsistent

Option D: Special value NaN (chosen by IEEE 754)

Value propagates through calculations
Program continues running
Can check the result at the end
Maintains type consistency (number)

What Would It Be Like Without `NaN`?

function divide(a, b) {
    // Check types
    if (typeof a !== 'number' || typeof b !== 'number') {
        throw new Error('Arguments must be numbers');
    }

    // Check if numbers are valid
    if (!isFinite(a) || !isFinite(b)) {
        throw new Error('Arguments must be finite');
    }

    // Check divisor
    if (b === 0) {
        throw new Error('Division by zero');
    }

    return a / b;
}

function calculate(expression) {
    try {
        const result = divide(10, 0);
        return result;
    } catch (e) {
        console.error(e.message);
        return null;  // What to return? null? undefined? 0?
    }
}

What Do We Have Thanks to `NaN`?

function divide(a, b) {
    return a / b;  // Hardware does the rest!
}

function calculate(expression) {
    return divide(10, 0);
}

const result = calculate("10 / 0");
console.log("Result:", result);  // Infinity

const badResult = 0 / 0;
if (Number.isNaN(badResult)) {
    console.log("Invalid calculation");
}

Summary

`NaN` is an elegant solution to the problem of error handling in floating-point calculations:

Implemented at the hardware level (ucomisd instruction)
Part of the IEEE 754 standard since 1985
Propagates through operations, allowing error detection at the end of calculations
NaN !== NaN is intentional design enabling detection
typeof NaN === "number" because it's part of the numeric system, not a separate type

References

Why typeof null === object

Piotr Zarycki — Sun, 12 Oct 2025 19:10:04 +0000

An object that is not an object

JavaScript has its charming quirks, and one of them is the typeof operator, which determines the type of a value.

Expected behavior:

typeof 100 //number

typeof "string" //string

typeof {} //object

typeof Symbol //function

typeof undefinedVariable // undefined

And here's our favorite, which is today's star of this article:

typeof null // object

JavaScript, like other programming languages, has types that can be divided into "primitive" - those that return a single value (null, undefined, boolean, symbol, bigint, string) and "object" types, which have a complex structure.
Simply put - for example, boolean in JavaScript is something that isn't a very complicated structure, as it returns only one value: true or false.

For instance, in the modern Firefox implementation, a technique called "pointer tagging" is used, where a 64-bit value encodes the type and value or address on the heap.
Let's look at how booleans are handled in this implementation:

const flagTrue = true;

Keyword	Tag	Payload
`false`	`JSVAL_TAG_BOOLEAN` (0xFFFE*)	`0x000000000000`
`true`	`JSVAL_TAG_BOOLEAN` (0xFFFE*)	`0x000000000001`

You can notice that the high bits are responsible for defining the data type, and the low bits for the payload or the address of the allocated object on the heap.
So in this case, our true/false is represented in binary as 1/0.

You're probably wondering what this has to do with typeof null returning object instead of null.

To understand this, we need to go back 30 years to the original JavaScript implementation in Netscape, which used a 32-bit tagging scheme - completely different from modern engines.

Brendan Eich, who was hired by Netscape, which at the time was the majority participant in the browser market, due to significant market demands and fierce competition from companies like Microsoft and Sun Microsystems, was tasked with creating a prototype programming language that had to meet key criteria:

be easy for a wide range of people (without static typing, compiler installation)
allow users to manipulate the DOM at a basic level

So after 10 days, a programming language was created that bore the names: "Mocha", "LiveScript", and finally JavaScript due to marketing pressure to leverage Java's popularity at the time.

After 10 days, a prototype programming language was born that, despite the later fall of the Netscape browser due to competition from Microsoft and the default installation of Internet Explorer on Windows - survived to this day and evolved.

The Netscape browser was written in C, as was the JavaScript implementation itself.
So let's move on to the typeof implementation in Netscape Navigator 1.3, which greeted programmers of that time with the help command with this message:

js> help()
JavaScript-C 1.3 1998 06 30

And the code implementing typeof looked like this:

JS_TypeOfValue(JSContext *cx, jsval v)
{
    JSType type;
    JSObject *obj;
    JSObjectOps *ops;
    JSClass *clasp;

    CHECK_REQUEST(cx);
    if (JSVAL_IS_VOID(v)) {
    type = JSTYPE_VOID;
    } else if (JSVAL_IS_OBJECT(v)) {
    obj = JSVAL_TO_OBJECT(v);
        if (obj &&
            (ops = obj->map->ops,
         ops == &js_ObjectOps
             ? (clasp = OBJ_GET_CLASS(cx, obj),
        clasp->call || clasp == &js_FunctionClass)
             : ops->call != 0)) {
            type = JSTYPE_FUNCTION;
        } else {
            type = JSTYPE_OBJECT;
        }
    } else if (JSVAL_IS_NUMBER(v)) {
        type = JSTYPE_NUMBER;
    } else if (JSVAL_IS_STRING(v)) {
        type = JSTYPE_STRING;
    } else if (JSVAL_IS_BOOLEAN(v)) {
        type = JSTYPE_BOOLEAN;
    }
    return type;
}

The macros defining data types in Netscape 1.3 looked like this:

#define JSVAL_OBJECT            0x0     /* untagged reference to object */
#define JSVAL_INT               0x1     /* tagged 31-bit integer value */
#define JSVAL_DOUBLE            0x2     /* tagged reference to double */
#define JSVAL_STRING            0x4     /* tagged reference to string */
#define JSVAL_BOOLEAN           0x6     /* tagged boolean value */

Which translated to this memory representation (32-bit system):

Type	Tag (Low 3 bits)	Memory (32 bits)	Value
Object	000 (0x0)	`[29-bit pointer][000]`	`0x12345000`
Integer	001 (0x1)	`[29-bit int value][001]`	`0x00006401` (42)
Double	010 (0x2)	`[29-bit pointer][010]`	`0xABCDE002` → heap
String	100 (0x4)	`[29-bit pointer][100]`	`0x78901004` → "hello"
Boolean	110 (0x6)	`[29-bit value][110]`	`0x00000006` (true)

Based on this information, we can create a simplified program by porting a few macros from Netscape to investigate this problem (the code is simplified for educational purposes):

#include <stdlib.h>
#include <stdio.h>

typedef unsigned long   pruword;
typedef long            prword;
typedef prword    jsval;
#define PR_BIT(n)       ((pruword)1 << (n))
#define PR_BITMASK(n)   (PR_BIT(n) - 1)


#define JSVAL_OBJECT            0x0     /* untagged reference to object */
#define OBJECT_TO_JSVAL(obj)    ((jsval)(obj))
#define JSVAL_NULL              OBJECT_TO_JSVAL(0)
#define JSVAL_TAGMASK           PR_BITMASK(JSVAL_TAGBITS)
#define JSVAL_TAG(v)            ((v) & JSVAL_TAGMASK)
#define JSVAL_IS_OBJECT(v)      (JSVAL_TAG(v) == JSVAL_OBJECT)
#define JSVAL_TAGBITS           3


struct JSObject {
    struct JSObjectMap *map;
};

struct JSObjectMap {

};

// Helper function to display binary representation
void print_binary(unsigned long n) {
    for (int i = 31; i >= 0; i--) {
        printf("%d", (n >> i) & 1);
    }
    printf("\n");
}

int main() {
 struct JSObject* obj = malloc(sizeof(struct JSObject));
 jsval objectValue = OBJECT_TO_JSVAL(obj);
 jsval null = JSVAL_NULL;

 printf("Is object %d\n", JSVAL_IS_OBJECT(objectValue));
 printf("Is null an object %d\n", JSVAL_IS_OBJECT(null));

 printf("Binary representation of object: ");
 print_binary(objectValue);
 printf("Binary representation of null: ");
 print_binary(null);
}

The output of this program is:

Is object 1
Is null an object 1
Binary representation of object: 01011000000010100011000111100000
Binary representation of null: 00000000000000000000000000000000

As you can see, null and object return the same value in the JSVAL_IS_OBJECT macro.
You're probably wondering why null and object are indistinguishable in this check.

The explanation for this is the above tagging model and basing on memory as an identifier of object types in JavaScript.
Since JavaScript is a dynamically typed language, type declarations had to reside somewhere, so in this case the creator decided to allocate 3 low bits for type identification.

Setting 000 as the object identifier comes from the mechanism of 32-bit architecture operation and hardware requirements related to memory alignment. Objects and arrays are structures that are more complex than primitive types, therefore they are allocated on the heap.

In 32-bit architecture, the CPU loads data in 32-bit portions (4 bytes), and the memory management system enforces the alignment of object addresses to 4-byte boundaries. This means that every pointer address to an object is divisible by 4, which in binary representation results in object addresses always ending with two zeros in binary notation (because 4 = 100 in binary). However, in practice, three lowest bits were used as tags, so addresses had 8-byte alignment, which guaranteed three trailing zeros.

In the case of null representation, we can see that it's the value 0 (all zeros), which refers to a null pointer in C, which in most architectures is defined as ((void*)0), meaning a non-existent location in memory. Because null is represented as 0x00000000, and the three lowest bits are 000, the JSVAL_IS_OBJECT macro considers null to be an object!

Was it possible to fix this? - of course!

As we can notice, the null representation is simply 0, a non-existent location in memory, and an object is something that exists, and horror of horrors, the macro that correctly checked for null was in the code, but was not used in the typeof function!

#define JSVAL_IS_NULL(v)        ((v) == JSVAL_NULL)

So the typeof function should look like this:

JS_TypeOfValue(JSContext *cx, jsval v)
{
    JSType type;
    JSObject *obj;
    JSObjectOps *ops;
    JSClass *clasp;

    CHECK_REQUEST(cx);
    if (JSVAL_IS_NULL(v)) { //check if value is null!
        type = JSTYPE_NULL;
    } else if (JSVAL_IS_VOID(v)) {
        type = JSTYPE_VOID;
    } else if (JSVAL_IS_OBJECT(v)) {
    obj = JSVAL_TO_OBJECT(v);
        if (obj &&
            (ops = obj->map->ops,
         ops == &js_ObjectOps
             ? (clasp = OBJ_GET_CLASS(cx, obj),
        clasp->call || clasp == &js_FunctionClass)
             : ops->call != 0)) {
            type = JSTYPE_FUNCTION;
        } else {
            type = JSTYPE_OBJECT;
        }
    } else if (JSVAL_IS_NUMBER(v)) {
        type = JSTYPE_NUMBER;
    } else if (JSVAL_IS_STRING(v)) {
        type = JSTYPE_STRING;
    } else if (JSVAL_IS_BOOLEAN(v)) {
        type = JSTYPE_BOOLEAN;
    }
    return type;
}

You can find an example implementation with extracted code that you can compile here:

https://gist.github.com/piotrzarycki/a3713de4e63fd275216900a74c8521e2

If the bug was so trivial to fix, why wasn't it fixed?

Well, millions of pages had already started using JavaScript with this bug, were aware of it, and handled it this way.

Moreover, in 2013 there was an official proposal to fix this behavior in the ECMAScript standard, but it was rejected precisely due to backward compatibility - too much existing code could have stopped working.

Therefore, despite 30 years having passed, this behavior reminds us of the context of JavaScript's creation and historical design decisions. To actually check whether a value is an object and not null, we need to handle it like this:

if (value !== null && typeof value === 'object') { 
 //this is a real object!
}

Originally published at pzarycki.com

How to make http request without curl or wget in bash

Piotr Zarycki — Mon, 26 Aug 2024 16:36:08 +0000

Bash has a hidden capability to make HTTP requests without needing tools like curl or wget. Let’s explore how this works.

First, let’s check the bash man page:

man bash

In the REDIRECTION section, you’ll find an interesting detail:

Bash handles several filenames specially when they are used in redirections. If the operating system on which Bash is running provides these special files, Bash will use them; otherwise, it will emulate them internally with the behavior described below.

  Bash handles several filenames specially when they are used in redirections, as described in the following table.  If the operating system on which bash is  running  provides  these
       special files, bash will use them; otherwise it will emulate them internally with the behavior described below.

              /dev/fd/fd
                     If fd is a valid integer, file descriptor fd is duplicated.
              /dev/stdin
                     File descriptor 0 is duplicated.
              /dev/stdout
                     File descriptor 1 is duplicated.
              /dev/stderr
                     File descriptor 2 is duplicated.
              /dev/tcp/host/port
                     If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open the corresponding TCP socket.
              /dev/udp/host/port
                     If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open the corresponding UDP socket.

If you try to list the /dev/tcp directory, you’ll get the following error:

ls -lat /dev/tcp
/dev/tcp: No such file or directory (os error 2).

This is because /dev/tcp is not an actual path on the filesystem; it’s a feature of Bash itself, not the underlying Linux system.

To use this feature, you need to call it as part of the Bash execution environment using the exec command:

exec 3<>/dev/tcp/example.org/80

We’ll discuss the 3<> syntax later. After running this command, it may seem like nothing happens, but there’s more going on behind the scenes.

Let’s use strace to investigate further. Among the output, the most interesting part is:

.......
close(3)                                = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("93.184.215.14")}, 16) = 0

This confirms that the exec command created a TCP/IP socket bound to example.org.

In Linux, everything is treated as a file, including network connections, which are represented as “files” called file descriptors. You can list all file descriptors for the current process by checking the /proc/self/fd/ directory:

ls -lat /proc/self/fd/

lrwx------ 1 piotr piotr 64 Aug 25 15:01 0 -> /dev/pts/0
lrwx------ 1 piotr piotr 64 Aug 25 15:01 1 -> /dev/pts/1
lrwx------ 1 piotr piotr 64 Aug 25 15:01 2 -> /dev/pts/2
lrwx------ 1 piotr piotr 64 Aug 25 15:01 3 -> 'socket:[2910856]'
lr-x------ 1 piotr piotr 64 Aug 25 15:01 4 -> /proc/1579316/fd

Here, 3 is the file descriptor for the socket connected to example.org. The exec 3<> /dev/tcp/... syntax essentially means:

"create a socket for input and output operations with file descriptor with process identifier equals 3."

Next, let’s send a GET request:

echo -ne "GET / HTTP/1.1\r\nHost: example.org\r\n\r\n" >&3

Although it may appear that nothing happens, you’ve just sent data through the socket.

To read the response, use:

cat <&3  

HTTP/1.1 200 OK
Age: 243157
Cache-Control: max-age=604800
Content-Type: text/html; charset=UTF-8
Date: Sun, 25 Aug 2024 14:15:54 GMT
Etag: "3147526947+ident"
Expires: Sun, 01 Sep 2024 14:15:54 GMT
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Server: ECAcc (dcd/7D77)
Vary: Accept-Encoding
X-Cache: HIT
Content-Length: 1256

<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">
......................REST............

You’ve successfully downloaded a webpage! Afterward, remember to close the socket:

exec 3<&-

You might wonder why this feature exists.

Originally, it was copied from the KornShell (ksh) to open network connections and assign them to file descriptors

It was intended to send data across networks, such as for generating reports.

https://github.com/ksh93/ksh/blob/fa0ee84029e0cd203d698151a0459413678ab095/src/cmd/ksh93/README-AUDIT.md?plain=1#L158

This feature can also be exploited to create reverse shells by hackers or penetration testers.

DEV Community: Piotr Zarycki

Infinity - Where Does JavaScript End?

Where limits end but sequences continue - there begins infinity!

IEEE 754 Standard as the Infinity Regulator

Why was this concept introduced in the IEEE 754 standard?

Practical Use Cases

Why {} !== {}

An object is not equal to another object

Types in JavaScript

But wait... what about toUpperCase()?

Semantics vs Implementation

String Interning (Atom Table)

Back to objects...

What does the ECMA-262 standard say?

Summary

Why NaN !== NaN in JavaScript (and the IEEE 754 story behind it)

A Number That Always Returns the Same Thing

From JavaScript to Hardware Level

NaN !== NaN

typeof NaN === "number"

IEEE 754-1985: Standard for Binary Floating-Point Arithmetic

NaN is a Number, But What Kind?

1994: Pentium FDIV Bug

NaN as the Savior of Programmers

NaN (Not a Number)

What Would It Be Like Without NaN?

What Do We Have Thanks to NaN?

Summary

References

Why typeof null === object

An object that is not an object

How to make http request without curl or wget in bash

But wait... what about `toUpperCase()`?

What Would It Be Like Without `NaN`?

What Do We Have Thanks to `NaN`?