Project: modernc.org/libc (windows) ## Environment - modernc.org/libc v1.75.7, windows/amd64 and windows/arm64 (GitHub Actions windows-latest and windows-11-arm), as pinned by the originating project. Generated with llvm-mingw (UCRT). ## Origin This report records findings made by the third-party project github.com/Tryanks/cpython-go, a ccgo transpilation of CPython 3.14 (commit ab9a153, 2026-09-05). The project is not mine; I am filing the findings so they are not lost. Unless stated otherwise, the items below are taken from comments in that repository and were not independently verified. The Windows notes are in libpython/libc_windows.go, docs/windows.md and internal/builders/windows/RUNTIME.md of that repository; RUNTIME.md is a function-by-function list of what the project reimplemented and why. ## Wrong results (quotes from libpython/libc_windows.go unless noted) - __builtin_clzl: "Windows C long is 32-bit even on amd64 and arm64. modernc's generic non-Linux implementation uses LeadingZeros64 for its uint32 ulong alias, making every nonzero result 32 too large." - CloseHandle: "modernc returns EINVAL (a nonzero BOOL) when CloseHandle fails. Preserve the Win32 BOOL contract so callers can detect failure and read LastError." - GetLastError / errno: "modernc.org/libc stores failures from most Win32 wrappers in errno, while its GetLastError reads that same errno slot. CPython deliberately clears errno in several paths before consulting LastError." (RUNTIME.md: "This avoids the `WinError 0` failures caused by modernc storing errors only [in errno]".) - getenv: "CPython's os.environ mutates the process through the wide CRT API, while Py_GETENV still performs narrow lookups. modernc's getenv reads a startup cache and misses those updates (notably PYTHONBREAKPOINT in test_builtin)." - _wgetenv: "modernc's cached wide environment drops its final entry and does not track Go-side Setenv calls." - __p__wenviron: "modernc's bootWinEnviron omits the required trailing null pointer. Reading its _wenviron can therefore walk beyond the Go slice, which is especially visible on arm64 when the next backing-array slot is nonzero." - _wopen: "modernc's _wopen passes UTF-16 storage to a narrow GoString helper, losing both ordinary wide paths and unpaired surrogate code units." - wcschr (RUNTIME.md): "modernc incorrectly returned null when searching for `L'\0'`". - setlocale: "modernc.org/libc's Windows setlocale always returns NULL." - feof: "modernc's Windows FILE wrapper does not distinguish EOF from I/O error." (RUNTIME.md: "_feof - stub: returns zero because modernc's Windows `FILE` representation does not retain an EOF indicator".) - sscanf: "modernc's scanner panics on the final %c." (the only sscanf call in CPython, parsing a Bluetooth address with format "%X:%X:%X:%X:%X:%X%c") - in6addr_any: generator.go, shimmedVars["windows"]: "libc variables whose generated type does not match the declaration used by CPython." ## Unconditional TODO panics replaced by the project - ungetc: "modernc's Windows ungetc is an unconditional TODO; its FILE implementation is unbuffered". (#28, closed as abandoned, discussed implementing ungetc in general.) - dup2: "modernc's Windows dup2 is an unconditional TODO." - SetHandleInformation: "modernc's Windows SetHandleInformation is an unconditional TODO panic." - GetOverlappedResult: "modernc's Windows GetOverlappedResult is an unconditional TODO panic." - OutputDebugStringW: "Avoid modernc's TODO panic while keeping fatal-error reporting on the process' real stderr intact." - RUNTIME.md line for a Winsock/handle wait routine: "modernc's implementation is an unconditional TODO panic." ## Not exported on Windows - strncat (RUNTIME.md): "generated Windows calls are routed to `_ccgo_strncat` because modernc does not export this symbol on Windows." - strtoll: provided by MinGW as a static inline wrapper around _strtoi64, whose body ccgo does not emit (see cznic/ccgo#50); the project defines _strtoll in Go. ## Complete list of routed libc calls on Windows The shimmedLibc["windows"] list from generator.go (kept sorted by the project). Entries such as the socket functions, CreateFileW, the Reg* family and the process functions carry the project's own Win32 behaviour (independent LastError slot, UTF-16 path handling, overlapped I/O) rather than a single identified libc defect: CloseHandle CreateDirectoryW CreateFileMappingA CreateFileMappingW CreateFileW CreateMutexW DeleteFileW ExitProcess FindClose FindFirstFileW FindNextFileW FreeLibrary GetFileAttributesExW GetFileAttributesW GetFileInformationByHandle GetFileType GetLastError GetOverlappedResult GetProcAddress GetShortPathNameW GetUserNameW LoadLibraryW MessageBeep MultiByteToWideChar OutputDebugStringW RaiseException RegCloseKey RegConnectRegistryW RegCreateKeyExW RegDeleteKeyW RegDeleteValueW RegEnumKeyExW RegEnumValueW RegOpenKeyExW RegQueryValueExW RegSetValueExW RemoveDirectoryW SetErrorMode SetFileAttributesW SetHandleInformation WSAGetLastError WSASetLastError WideCharToMultiByte __builtin_clzl __builtin_snprintf __mingw_vsnprintf __p__wenviron _commit _lseeki64 _setmode _wgetenv _wopen _wputenv _wstat64i32 abort accept bind close closesocket connect dup2 fdopen fprintf getenv getpeername getservbyname getsockname getsockopt inet_ntoa isalnum ioctlsocket listen lseek mbstowcs mktime open printf raise read recv recvfrom select send sendto setlocale setsockopt shutdown snprintf socket sprintf sscanf strftime strncat time tolower toupper tzset umask ungetc vfprintf vsnprintf vsprintf wcschr wcsncmp wcstombs write ## Notes - RUNTIME.md also records that "Type-check success does not imply that every already-declared modernc Windows [wrapper works]" and describes how the project audited the remaining generated libc.X* calls against modernc's Windows implementations. - GetProcAddress is deliberately made to fail in the project ("A FARPROC is a native machine-code address, whereas ccgo-translated C calls require a Go function value registered through __ccgo_fp.") and the Winsock extension functions AcceptEx, ConnectEx, DisconnectEx and TransmitFile are reached through explicit Go wrappers instead of pointers obtained from WSAIoctl. That is a property of the ccgo function-pointer model, not a libc defect, but it is why native callback and function-pointer APIs need fixed trampolines.