`fs.readSync` does not validate invalid `position` type (accepts object instead of throwing)

[kevgeoleo]

Version

v24.13.1

Platform

Linux KContainer 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 (2022-03-07) x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

Hi,

I would like to report a behavior in Node that can be reproduced by running the below snippet

"use strict"
import fs from 'node:fs';
import os from 'node:os';
import path from 'node:path';

const memPath = fs.mkdtempSync(path.join(os.tmpdir(), 'node-temp-'));
const memFile = path.join(memPath, 'tempfile');
fs.writeFileSync(memFile, '');

// Open the file for reading and writing
const fd = fs.openSync(memFile, 'r+');

const ankor = new TextEncoder().encode('');

// This call is intentionally incorrect: `position` should be a number or null.
try {
 fs.readSync(fd, ankor, 0, ankor.length, { not: 'a number' } /* invalid position */);
 console.log('fs.readSync did not throw as expected');
} catch (err) {
 console.log('fs.readSync threw an error as expected:', err instanceof TypeError ? 'TypeError' : err.name, '-', err.message);
}

fs.closeSync(fd);

How often does it reproduce? Is there a required condition?

No special condition for reproduction

What is the expected behavior? Why is that the expected behavior?

Position argument must be a number and error should be thrown
According to the documentation it should be number: https://nodejs.org/api/fs.html#fsreadsyncfd-buffer-offset-length-position

root@KContainer:~/14128# deno run -A poc.mjs
fs.readSync threw an error as expected: TypeError - The "position" argument must be of type bigint or integer. Received an instance of Object

What do you see instead?

Does not throw even in strict mode

root@KContainer:~/14128# node poc.mjs
fs.readSync did not throw as expected

Additional information

No response

[geeksilva97]

The validation is lazy. It reaches the case where length === 0 and early returns.

To match the behavior with the docs, we should either update the docs or move the validation upwards.

[damianremington274-blip]

I agree that the validation should likely be moved upwards to ensure consistency with the documentation, even when the length is zero. Given that the current behavior is inconsistent with the expected type validation, moving the check seems like the best approach to ensure fs.readSync maintains a predictable API.

…

On Wed, Apr 8, 2026, 9:59 AM Edy Silva ***@***.***> wrote: *geeksilva97* left a comment (nodejs/node#62638) <#62638 (comment)> The validation is lazy. It reaches the case where length === 0 <https://github.com/nodejs/node/blob/main/lib/fs.js#L715-L717> and early returns. To match the behavior with the docs, we should either update the docs or move the validation upwards. — Reply to this email directly, view it on GitHub <#62638 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7YAFGUFRB3T2O4SYWDGQUD4UZSO3AVCNFSM6AAAAACXQ7GPIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMBXGIYTCNJUHA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>