Does not compile on MSVC — <unistd.h>, global min/max, and _STRING_ macro

[binaryduke]

Nodepp does not compile under MSVC (Visual Studio 2022, C++20, Windows x64). Three separate issues, each independent of the others. Happy to send a PR for all three if you'd like them.

1. include/nodepp/import.h includes <unistd.h> unconditionally.

<unistd.h> is POSIX-only and does not exist on MSVC, so the very first include fails. Guarding it is enough:

#ifndef _WIN32
#include <unistd.h>
#endif

2. include/nodepp/macros.h defines min, max and clamp as templates at global scope.

On Windows these collide with the min/max macros from <windows.h> (pulled in transitively by the Winsock headers the library itself needs), and they also conflict with std::min/std::max under ADL. Wrapping them in the nodepp namespace resolves it without changing behaviour for existing users:

namespace nodepp {
    template< class T > T   min( const T& a, const T& b ){ return a < b ? a : b; }
    template< class T > T   max( const T& a, const T& b ){ return a > b ? a : b; }
    template< class T > T clamp( const T& v, const T& lo, const T& hi ){ return max( lo, min( hi, v ) ); }
}

3. _STRING_ is too generic a macro name and collides on Windows.

Renaming it avoids the collision:

#define NODEPP_STRINGIFY(...) #__VA_ARGS__
#define _JSON_(...) json::parse(NODEPP_STRINGIFY(__VA_ARGS__))

Also worth flagging: _FUNC_ is defined as __PRETTY_FUNCTION__, which MSVC does not provide (__FUNCSIG__ is the equivalent).

Tested against V1.4.0 and the current main (V1.5.0) — both fail identically.

[EDBCREPO]

Thanks for the detailed feedback. Let's go point by point:

---

1. unistd.h — Already removed. I was using it to detect thread support on embedded systems ( if supports posix ), but I've simplified it:

// from
#if defined(_POSIX_THREADS) && _POSIX_THREADS>0 && NODEPP_ALLOW_THREADS==1
// to
#if NODEPP_ALLOW_THREADS==1

Now the user must explicitly enables threads on embedded devices ( if support posix - but enabled by default on desktop ). This allows disabling atomics, thread_local, and mutexes on devices that don't support them.

---

2. min, max, clamp — I like your proposal to wrap them in namespace nodepp. This avoids collisions with other libraries and Windows macros. This is something I overlooked.

---

3. _STRING_ and wierd macros — Love the name NODEPP_STRINGIFY. Since _STRING_ isn't used internally in Nodepp (except in WASM: webrtc.h, ws.h, and http.h), I can rename it without issues. Since _FUNC_, _LINE_, and _JSON_ aren't used internally, so I'm removing them from the codebase, it is not necesary.

---

Bonus: io_uring bugfix — This version (V1.5.0_1) also includes an important fix for io_uring. Turns out that when shutting down the program, the ring memory was getting corrupted causing an infinite loop of seg_fault errors. so it's now resolved.

---

With this, Nodepp must compiles on MSVC without any issues. The changes are already available in V1.5.0_1.
Thanks for your time. 🤝

[binaryduke]

That's a fast turnaround — thank you.

All three land exactly where we needed them, and the NODEPP_ALLOW_THREADS simplification is a cleaner solution than the #ifndef _WIN32 guard we were carrying locally.

We'll drop our three local MSVC patches and pick up V1.5.0_1. Happy to report back once we've built against it on MSVC 2022 / C++20 / x64, in case anything else surfaces.

The io_uring shutdown fix is interesting to us too — we independently hit two other teardown-time segfaults on the Windows/IOCP side while building a WebSocket server on nodepp. Different mechanism to the io_uring one, but the same "shutdown corrupts a live registration" family. I've filed them separately with minimal repros and the full elimination logs, since they're unrelated to this issue.

[binaryduke]

Reporting back from a real MSVC build, as promised.

Confirmed fixed — MSVC 2022, x64, /std:c++20, Release

1.5.0 builds our entire project (6 targets, 4 test suites) with zero nodepp patches. Both workarounds we were carrying are gone. Verified against the tag itself, not taken on trust:

• unistd.h is out of import.h — the remaining hits are all under posix/, which never compiles on MSVC. Correct.
• min / max / clamp are inside namespace nodepp (macros.h:68-76), so they no longer collide with the <windows.h> macros.
• _STRING_ → NODEPP_STRINGIFY (macros.h:132) removes the Windows SDK collision.
• NODEPP_THREAD_SUPPORTED is now driven by NODEPP_ALLOW_THREADS (default 1) instead of the _POSIX_THREADS probe. This is strictly better than what we asked for — it retired the #ifndef _WIN32 special-case we'd been carrying, rather than just working around it.

Thank you — that was a fast turnaround and all four landed exactly where we needed them.

Three source-breaking changes worth a release note

None of these are obvious to a consumer upgrading from 1.4.0, and all three bit us:

1. ulong went from a global #define ulong unsigned long int to a using declaration inside namespace nodepp. The right change — but any consumer using bare ulong outside the namespace now fails to compile.
2. Bare CHUNK_SIZE no longer exists — only NODEPP_CHUNK_SIZE.
3. onSocket gained a leading ptr_t<...> self-parameter (tcp.h:44, tls.h:45). onConnect kept its old shape, so the two now differ.

All three were straightforward to fix on our side. Flagging them only so they can go in the 1.5.0 notes for the next person.

One caveat

We can't actually run on 1.5.0 yet — it segfaults on MSVC as soon as a WebSocket client connects (#36, filed with a repro against your own examples on a pristine checkout of the tag). The build is clean; the runtime isn't. We're staying on 1.4.0 until that's sorted, and happy to test any candidate fix on real MSVC — from #35 it sounds like you don't have a Windows box, and we do.

[binaryduke]

Verified fixed in 1.5.0 on MSVC 2022 x64 /std:c++20. Closing. Thanks. (One remaining Windows build blocker on dev specifically is the generator min() cast — separate PR #37.)