[RFC]: replace inline NaN generation with stdlib NaN constants in C source files (tracking issue)

[manit2004]

Instructions

1. Read the issue description below.
2. Review the example pull requests linked below.
3. Search the codebase for a package containing inline NaN generation in a C source file and update it according to this issue.
4. Follow all additional guidance in this issue.

---

Description

This RFC proposes replacing inline NaN generation (e.g., 0.0/0.0 or 0.0f/0.0f) in C source files, examples, benchmarks, and README C usage snippets with the stdlib NaN constant from @stdlib/constants/float64/nan or @stdlib/constants/float32/nan.

In short, this RFC seeks to refactor code from this pattern:

return 0.0/0.0; // NaN

to this pattern:

#include "stdlib/constants/float64/nan.h"
// ...
return STDLIB_CONSTANT_FLOAT64_NAN;

This refactoring is demonstrated in PR #11768 (float64) and PR #11769 (float32). Study both PRs before starting, as they demonstrate the exact changes being sought.

In particular, notice three things:

1. We add the C header include for the NaN constant: #include "stdlib/constants/float64/nan.h".
2. We replace inline NaN generation with the macro STDLIB_CONSTANT_FLOAT64_NAN.
3. We add the dependency @stdlib/constants/float64/nan to all manifest configuration entries (build, benchmark, examples) which compile the updated C source file.

By performing this refactoring, we facilitate:

1. Consistent NaN handling across packages and targets.
2. Better readability and maintainability in C implementations.

Float32

There are also inline float32 NaN occurrences written as 0.0f/0.0f which must be replaced with STDLIB_CONSTANT_FLOAT32_NAN from @stdlib/constants/float32/nan. The equivalent include is #include "stdlib/constants/float32/nan.h" and the manifest dependency is @stdlib/constants/float32/nan. The float32 migration is demonstrated in PR #11769.

---

Steps

1. Study the changes in PR #11768 (float64) and PR #11769 (float32), as these demonstrate the exact changes being sought.

2. Ensure your local development environment is set up by following the contributing guide, including running make install-node-modules and make init.

3. Find a package containing inline NaN generation in a C source file. A possible global project search can use the following regular expression:

   0\.0f?\s*/\s*0\.0f?
   

   From the search results, locate a package not already addressed by an open or merged PR referencing this issue.

4. Update that package, and only that package, to use STDLIB_CONSTANT_FLOAT64_NAN (or STDLIB_CONSTANT_FLOAT32_NAN for float32). Updated files may include src/main.c, examples/c/example.c, benchmark/c/benchmark.c, and any C code snippets in README.md.

5. When adding the #include statement, place it with the existing stdlib includes in the file, following the include ordering already present. Do not reorder existing includes.

6. Update manifest.json to add the NaN constant package as a dependency in every confs entry that compiles the updated C source file. This typically includes the build, benchmark, and examples task entries. For example (float64 shown; use @stdlib/constants/float32/nan for float32 packages):

     {
       "task": "build",
       "src": [
         "./src/main.c"
       ],
       "include": [
         "./include"
       ],
       "libraries": [],
       "libpath": [],
       "dependencies": [
   -     "@stdlib/some/existing/dep"
   +     "@stdlib/some/existing/dep",
   +     "@stdlib/constants/float64/nan"
       ]
     }

7. Also check the package README.md for any C usage examples containing 0.0/0.0 or 0.0f/0.0f and update those to use the macro as well.

8. Build the Node add-on and run the C examples, benchmarks, and native tests using the commands below. Replace <package-path> with the path of the package you updated (e.g., stats/strided/dnanmeanpn):

   cd /path/to/stdlib
   
   # Build the Node add-on for the specific package
   make install-node-addons NODE_ADDONS_PATTERN="<package-path>"
   
   # Run C examples, benchmarks, and native tests
   make EXAMPLES_FILTER=".*/<package-path>/.*" examples-c
   make BENCHMARKS_FILTER=".*/<package-path>/.*" benchmark-c
   make test TESTS_FILTER=".*/<package-path>/.*"

   Verify that the test and example output after refactoring is identical to what it was before (i.e., NaN is returned wherever expected). No behavioral changes should result from this refactor.

9. Before opening a PR, search existing open pull requests that reference this issue to confirm no one has already submitted the same package.

10. Commit your changes and submit a PR updating only that package.

11. Use the appropriate PR title template based on which constant you replaced:

    For float64 packages:

    refactor: use `constants/float64/nan` in <package-name>
    

    For float32 packages:

    refactor: use `constants/float32/nan` in <package-name>
    

12. In the PR body, use the phrase "Resolves a part of" followed by a link to this issue. Do not use "Resolves" or "Closes", as this is a tracking issue and your PR only addresses one package of many.

---

Related Issues

None.

Questions

None.

---

Other

• For each pull request, please update only one package.
• Do not make unrelated or stylistic changes. Only replace inline NaN generation with the shared NaN constant and make the required dependency and include updates. Failure to respect this guidance will result in your PR being closed without review.
• Before opening a PR, verify that no existing open PR already addresses the same package by searching pull requests that reference this issue.
• As this is a Good First Issue, you are strongly encouraged to avoid using AI when authoring your contribution. One of the primary intents of Good First Issues is to help introduce you to stdlib, its development environment, and the contribution process, as documented in the contributing guide. Most new contributors are unfamiliar with stdlib and its conventions, and thus fail to appropriately use AI assistance, most often generating low-quality output that leads to wasted time for everyone involved. Take the time to manually author your first several PRs, and once you are intimately familiar with project conventions, you can consider leveraging AI to augment your development tasks.

---

Checklist

• I have read and understood the Code of Conduct.
• I have searched for existing issues and pull requests.
• The issue title begins with RFC:.

[stdlib-bot]

👋 Important: PLEASE READ 👋

This issue has been labeled as a good first issue and is available for anyone to work on.

If this is your first time contributing to an open source project, some aspects of the development process may seem unusual, arcane, or some combination of both.

1. You cannot "claim" issues. People new to open source often want to "claim" or be assigned an issue before beginning work. The typical rationale is that people want to avoid wasted work in the event that someone else ends up working the issue. However, this practice is not effective in open source, as it often leads to "issue squatting", in which an individual asks to be assigned, is granted their request, and then never ends up working on the issue. Accordingly, you are encouraged to communicate your intent to address this issue, ideally by providing a rough outline as to how you plan to address the issue or asking clarifying questions, but, at the end of the day, we will take running code and rough consensus in order to move forward quickly.
2. We have a very high bar for contributions. We have very high standards for contributions and expect all contributions—whether new features, tests, or documentation—to be rigorous, thorough, and complete. Once a pull request is merged into stdlib, that contribution immediately becomes the collective responsibility of all maintainers of stdlib. When we merge code into stdlib, we are saying that we, the maintainers, commit to reviewing subsequent changes and making bugfixes to the code. Hence, in order to ensure future maintainability, this naturally leads to a higher standard of contribution.

Before working on this issue and opening a pull request, please read the project's contributing guidelines. These guidelines and the associated development guide provide important information, including links to stdlib's Code of Conduct, license policy, and steps for setting up your local development environment.

To reiterate, we strongly encourage you to refer to our contributing guides before beginning work on this issue. Failure to follow our guidelines significantly decreases the likelihood that you'll successfully contribute to stdlib and may result in automatic closure of a pull request without review.

Setting up your local development environment is a critical first step, as doing so ensures that automated development processes for linting, license verification, and unit testing can run prior to authoring commits and pushing changes. If you would prefer to avoid manual setup, we provide pre-configured development containers for use locally or in GitHub Codespaces.

We place a high value on consistency throughout the stdlib codebase. We encourage you to closely examine other packages in stdlib and attempt to emulate the practices and conventions found therein.

• If you are attempting to contribute a new package, sometimes the best approach is to simply copy the contents of an existing package and then modify the minimum amount necessary to implement the feature (e.g., changing descriptions, parameter names, and implementation).
• If you are contributing tests, find a package implementing a similar feature and emulate the tests of that package.
• If you are updating documentation, examine several similar packages and emulate the content, style, and prose of those packages.

In short, the more effort you put in to ensure that your contribution looks and feels like stdlib—including variables names, bracket spacing, line breaks, etc—the more likely that your contribution will be reviewed and ultimately accepted. We encourage you to closely study the codebase before beginning work on this issue.

✨ Thank you again for your interest in stdlib, and we look forward to reviewing your future contributions. ✨

[puneetdixit200]

Hi maintainers, I’d like to work on this tracking issue. I can replace inline NaN generation with stdlib NaN constants in scoped C-source batches and follow your existing lint/test conventions. Please assign this to me if available.

[manit2004]

@puneetdixit200 In stdlib we don't assign issues to people. You are free to make a PR on an issue that you like. Please read the previous message made by stdlib-bot.