Skip to content

node:fs: calling writeFileSync/appendFileSync with negative 0 causes an assertion failure #65886

Description

@xunuwu

Version

v26.8.1

Platform

Linux nixdesk 6.18.48 #1-NixOS SMP PREEMPT_DYNAMIC Fri Aug 28 06:22:54 UTC 2026 x86_64 GNU/Linux

Subsystem

fs

What steps will reproduce the bug?

require("node:fs").writeFileSync(-0, "")

or

require("node:fs").appendFileSync(-0, "")

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

it always happens on my machine. i have not tried on any other computer or os

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

for it to do the same thing as positive zero i assume

What do you see instead?

❯ echo 'require("node:fs").writeFileSync(-0, "")' | node -

  #  node[264400]: void node::fs::WriteFileUtf8(const v8::FunctionCallbackInfo<v8::Value>&) at ../../src/node_file.cc:2764
  #  Assertion failed: (*path) != nullptr

----- Native stack trace -----

 1: 0x629c801c0228  [node]
 2: 0x629c801c0b97 node::Assert(node::AssertionInfo const&) [node]
 3: 0x629c801cda7b  [node]
 4: 0x729babdcfae9 

----- JavaScript stack trace -----

1: writeFileSync (node:fs:2997:20)
2: [stdin]:1:20
3: runScriptInThisContext (node:internal/vm:219:10)
4: node:internal/process/execution:485:12
5: [stdin]-wrapper:6:24
6: runScriptInContext (node:internal/process/execution:483:60)
7: evalFunction (node:internal/process/execution:317:30)
8: evalTypeScript (node:internal/process/execution:329:3)
9: node:internal/main/eval_stdin:51:5
10: node:internal/process/execution:239:5


fish: Job 1, 'echo 'require("node:fs").writeF…' terminated by signal SIGABRT (Abort)

Additional information

No response

Activity

  1. added
    fsIssues and PRs related to file-system APIs and the fs module.
    on Sep 7, 2026
  2. christianaurichzm commented on Sep 7, 2026

    @christianaurichzm
    Contributor

    I was already digging into a similar fs fast-path issue when I saw this, so I took a look.

    It seems to come from the JS isInt32() check accepting -0 while V8's IsInt32() does not. I also noticed that readFileSync(-0, 'utf8') hits the same mismatch in the read fast path.

    I opened #65888 with a small fix for both cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    fsIssues and PRs related to file-system APIs and the fs module.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions