Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[P2] Interpreter: global isNaN treats null and empty string as NaN

Open Beginner friendly
  • Is something wrong?
#2,695 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, typescript
Domain
backend

Research direction

Start in Runtime/BuiltIns/GlobalFunctionHandlers.cs at HandleIsNaN, then inspect the interpreter’s numeric coercion helpers and the separate Number.isNaN handler. Reproduce the reported null and empty string cases with the checked interpreter and compare them with Node. Done when global isNaN returns false for both inputs and the strict Number.isNaN behavior remains unchanged.

Written by the indexing model from the issue text.

Description

Bare global isNaN treats null and the empty string as NaN in checked interpretation.

console.log("null", isNaN(null as any), globalThis.isNaN(null as any));
console.log("empty", isNaN("" as any), globalThis.isNaN("" as any));

Node v22.23.2 (node --experimental-strip-types <source>) prints:

null false false
empty false false

The immutable checked interpreter (dotnet artifacts/p2-interpreter/baseline/SharpTS.dll --no-tsconfig <source>) exits 0 but prints:

null true false
empty true false

The global function applies Number conversion: null and an empty string become zero, so neither is NaN. The qualified calls in this small source are controls; this report does not claim their general coercion behavior is correct.

Source lead: Runtime/BuiltIns/GlobalFunctionHandlers.cs::HandleIsNaN explicitly returns true for null and uses double.TryParse for strings, which rejects empty strings. The global predicate needs JavaScript numeric coercion; preserve the separate strict Number.isNaN contract.

Verified against immutable baseline commit fec8235223bed34a9b49bdce384bb88dd6cf8b55, CLI SHA-256 B5FA2CADDEA116B83166442205B825130A663B682EDAABAA1312A26FB7909E85 before and after execution. Source SHA-256 EB0530041D4D4DFD29214B7597508D566CBD6A2AA818801AC9C8B92AFA255729. Both Node and interpreter completed within the preserved 20-second deadline, with empty stderr. No introducing-commit or compiler-behavior claim.

Discovered during the bounded #2541 global binding audit, before using canonical global function aliases more broadly. #2541 concerns stale bare bindings after a global-object write; this reproduction performs no mutation. Closed #1770 owns compiled global isNaN function-value coercion, not this checked interpreter direct-call failure. Fresh all-state GitHub isNaN and interpreter/global searches found no focused interpreter owner.

Ignored evidence: artifacts/p2-interpreter/2541-isnan-coercion.ts, .node.*, .baseline.*, .results.json, plus 2541-isnan-dedup.json and 2541-isnan-dedup-interpreter.json.

Dominant language
C#
Stars
156
Forks
4
Avg merge
5h 24m
Merged PRs (30d)
68

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nickna/SharpTS

All issues in nickna/SharpTS

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.