Reject negative file descriptors in gzdopen()

[minnnjuuu]

Reject negative file descriptors in gzdopen()

Summary

• Reject every negative file descriptor at the public gzdopen() boundary.

Problem

gzdopen() currently rejects only fd == -1. On Windows, the private gz_open() helper also uses fd == -2 as an internal marker indicating that path is a wchar_t * supplied by gzopen_w().

A public call to gzdopen(-2, "rb") therefore creates a narrow char * diagnostic string and forwards it with the private marker. The Windows branch interprets that narrow allocation as a wide path. In an MSVC AddressSanitizer build, this produced a heap-buffer-overflow read in wcslen() through _wopen() and aborted the process.

This issue occurs at a boundary where public gzdopen() input overlaps with a special value used by the Windows implementation. The effect on an application depends on where its fd value comes from and how it is validated. This change consistently rejects negative values at the API boundary, preventing them from colliding with the internal dispatch.

Fix

File descriptors returned by the supported APIs are non-negative. Rejecting all negative values before constructing the diagnostic path prevents public callers from colliding with private path-opening markers.

The internal wide-character API remains unchanged: gzopen_w() calls gz_open(path, -2, mode) directly and does not pass through gzdopen().

Testing

• All 15 CMake tests passed with ASan/UBSan on Linux.
• Existing tests passed with MSVC ASan on Windows, with valid descriptor behavior preserved and negative values returning NULL.