Soul Lee 7147a3e8e7 ffi: throw on missing memory helper arguments
ffi.getInt8() through ffi.getFloat64(), ffi.setInt8() through
ffi.setFloat64(), ffi.toBuffer() and ffi.toArrayBuffer() return
undefined instead of throwing when a required argument is omitted, so a
call that read or wrote nothing cannot be told apart from one that read
a zero byte. All 22 helpers behave this way.

GetValidatedPointerAddress() and GetValidatedSize() already reject the
same argument when it is passed explicitly as undefined. The
args.Length() test in front of them short-circuits the call and returns
Nothing without scheduling an exception. These six are the only tests in
src/ where args.Length() can skip a call that throws; the only other
Length() tests that guard a call at all guard Buffer::HasInstance(),
which cannot throw. The remaining tests in this file guard an inline
predicate and throw in the branch, which is why setUint8(ptr) reports
"Expected an offset argument" while setUint8() reports nothing at all.

Drop those tests. FunctionCallbackInfo::operator[] returns Undefined for
an out-of-range index, which is exactly the value these validators
reject, so each missing argument now produces the error its explicit
undefined counterpart produces. The documentation already describes this
behavior: the signatures are ffi.getInt8(pointer[, offset]),
ffi.setInt8(pointer, offset, value) and
ffi.toBuffer(pointer, length[, copy]), and the getters are documented to
return a number or a bigint.

ExportBytes() carried the same two tests. They are unreachable through
the public API because exportBytes is not exported and its three callers
all validate len in JavaScript first, but they are the same shape.

Signed-off-by: Soul Lee <alus20x@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/65500
Fixes: https://github.com/nodejs/node/issues/65499
Refs: https://github.com/nodejs/node/pull/62072
Refs: https://github.com/nodejs/node/pull/62858
Refs: https://github.com/nodejs/node/pull/65842
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
Reviewed-By: Daeyeon Jeong <daeyeon.dev@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
2026-09-06 15:20:42 +00:00
2026-09-05 20:54:14 +00:00
…
…
…
…
…
…
…
…
2026-09-04 22:21:58 +00:00
…
…
…
…
…
2026-09-04 22:21:58 +00:00

Node.js

Node.js is an open-source, cross-platform JavaScript runtime environment.

For information on using Node.js, see the Node.js website.

The Node.js project uses an open governance model. The OpenJS Foundation provides support for the project.

Contributors are expected to act in a collaborative manner to move the project forward. We encourage the constructive exchange of contrary opinions and compromise. The TSC reserves the right to limit or block contributors who repeatedly act in ways that discourage, exhaust, or otherwise negatively affect other participants.

This project has a Code of Conduct.

Table of contents

Support

Looking for help? Check out the instructions for getting support.

Release types

  • Current: Under active development. Code for the Current release is in the branch for its major version number (for example, v22.x). Node.js releases a new major version every 6 months, allowing for breaking changes. This happens in April and October every year. Releases appearing each October have a support life of 8 months. Releases appearing each April convert to LTS (see below) each October.
  • LTS: Releases that receive Long Term Support, with a focus on stability and security. Every even-numbered major version will become an LTS release. LTS releases receive 12 months of Active LTS support and a further 18 months of Maintenance. LTS release lines have alphabetically-ordered code names, beginning with v4 Argon. There are no breaking changes or feature additions, except in some special circumstances.
  • Nightly: Code from the Current branch built every 24-hours when there are changes. Use with caution.

Current and LTS releases follow semantic versioning. A member of the Release Team signs each Current and LTS release. For more information, see the Release README.

Download

Binaries, installers, and source tarballs are available at https://nodejs.org/en/download/.

Current and LTS releases

https://nodejs.org/download/release/

The latest directory is an alias for the latest Current release. The latest-codename directory is an alias for the latest release from an LTS line. For example, the latest-hydrogen directory contains the latest Hydrogen (Node.js 18) release.

Nightly releases

https://nodejs.org/download/nightly/

Each directory and filename includes the version (e.g., v22.0.0), followed by the UTC date (e.g., 20240424 for April 24, 2024), and the short commit SHA of the HEAD of the release (e.g., ddd0a9e494). For instance, a full directory name might look like v22.0.0-nightly20240424ddd0a9e494.

API documentation

Documentation for the latest Current release is at https://nodejs.org/api/. Version-specific documentation is available in each release directory in the docs subdirectory. Version-specific documentation is also at https://nodejs.org/download/docs/.

Verifying binaries

Download directories contain a SHASUMS256.txt.asc file with SHA checksums for the files and the releaser PGP signature.

You can get a trusted keyring from nodejs/release-keys, e.g. using curl:

curl -fsLo "/path/to/nodejs-keyring.kbx" "https://github.com/nodejs/release-keys/raw/HEAD/gpg/pubring.kbx"

Alternatively, you can import the releaser keys in your default keyring, see Release keys for commands on how to do that.

Then, you can verify the files you've downloaded locally (if you're using your default keyring, pass --keyring="${GNUPGHOME:-~/.gnupg}/pubring.kbx"):

curl -fsO "https://nodejs.org/dist/${VERSION}/SHASUMS256.txt.asc" \
&& gpgv --keyring="/path/to/nodejs-keyring.kbx" --output SHASUMS256.txt < SHASUMS256.txt.asc \
&& shasum --check SHASUMS256.txt --ignore-missing

Building Node.js

See BUILDING.md for instructions on how to build Node.js from source and a list of supported platforms.

Security

For information on reporting security vulnerabilities in Node.js, see SECURITY.md.

Contributing to Node.js

Current project team members

For information about the governance of the Node.js project, see GOVERNANCE.md.

TSC (Technical Steering Committee)

TSC voting members

TSC regular members

TSC emeriti members

TSC emeriti members

Collaborators

Emeriti

Collaborator emeriti

Collaborators follow the Collaborator Guide in maintaining the Node.js project.

Triagers

Triagers follow the Triage Guide when responding to new issues.

Release keys

Primary GPG keys for Node.js Releasers (some Releasers sign with subkeys):

You can use the keyring the project maintains at https://github.com/nodejs/release-keys/raw/refs/heads/main/gpg-only-active-keys/pubring.kbx. Alternatively, you can import them from a public key server. Have in mind that the project cannot guarantee the availability of the server nor the keys on that server.

gpg --keyserver hkps://keys.openpgp.org --recv-keys 5BE8A3F6C8A5C01D106C0AD820B1A390B168D356 # Antoine du Hamel
gpg --keyserver hkps://keys.openpgp.org --recv-keys DD792F5973C6DE52C432CBDAC77ABFA00DDBF2B7 # Juan José Arboleda
gpg --keyserver hkps://keys.openpgp.org --recv-keys CC68F5A3106FF448322E48ED27F5E38D5B0A215F # Marco Ippolito
gpg --keyserver hkps://keys.openpgp.org --recv-keys 890C08DB8579162FEE0DF9DB8BEAB4DFCF555EF4 # Rafael Gonzaga
gpg --keyserver hkps://keys.openpgp.org --recv-keys C82FA3AE1CBEDC6BE46B9360C43CEC45C17AB93C # Richard Lau
gpg --keyserver hkps://keys.openpgp.org --recv-keys 108F52B48DB57BB0CC439B2997B01419BD92F80A # Ruy Adorno
gpg --keyserver hkps://keys.openpgp.org --recv-keys 655F3B5C1FB3FA8D1A0CA6BDE4A7D232B936D2FD # Stewart X Addison
gpg --keyserver hkps://keys.openpgp.org --recv-keys A363A499291CBBC940DD62E41F10027AF002F8B0 # Ulises Gascón

See Verifying binaries for how to use these keys to verify a downloaded file.

Other keys used to sign some previous releases

The project maintains a keyring able to verify all past releases of Node.js at https://github.com/nodejs/release-keys/raw/refs/heads/main/gpg/pubring.kbx.

Security release stewards

When possible, the commitment to take slots in the security release steward rotation is made by companies in order to ensure individuals who act as security stewards have the support and recognition from their employer to be able to prioritize security releases. Security release stewards manage security releases on a rotation basis as outlined in the security release process.

License

Node.js is licensed under the MIT License.

This project also depends on external libraries that may use different open-source licenses. For a complete list of included licenses, please see the LICENSE file.

If you are contributing documentation or source changes, please ensure your additions comply with the project’s license guidelines.

Languages
JavaScript 65.4%
C++ 22.6%
Python 8.4%
C 2.1%
HTML 0.5%
Other 0.8%