fortify-headers/include, branch 3.0.2

Don't leak PATH_MAX' #define

2026-04-30T22:48:04Z

Apparently, some horrible systems are leaving PATH_MAX *intentionally* undefined, as paths can be unbounded there. We don't want to silently introduced a limit in the trnaslation unit, so let's undefine it at the end of the function.

Add a guarded extension before #include_next in strings.h

2026-04-30T22:46:20Z

Fix strncat/wcsncat

2026-04-30T22:44:53Z

Previously, no checks were done when __n <= __b, but strncat _appends_ after existing content, making this a overly broad check check. For example, with an 8-byte buffer containing "12345\0", strncat(buf, "ABCD", 4) would have the check skipped, but the result "12345ABCD\0" is 10 bytes, resulting in an overflow. This commit fixes this oversight, and adds a bunch of tests.

Fix mbsnrtowcs

2026-04-30T16:06:56Z

mbsnrtowcs writes up to __wn wide characters into wchar_t *__d. The destination capacity is __b / sizeof(wchar_t) wide characters, but the else branch clamps __n (source byte limit) to __b (destination byte size). __wn (the actual output count) is passed through unclamped. Example: __b=8 (dest holds 2 wchar_t), __n=100, __wn=25. The else branch applies (25 <= 100/4), clamps source to 8 bytes, but passes __wn=25 — the function can write 25 wchar_t (100 bytes) into an 8-byte buffer. The first branch is also wrong: it divides __b (bytes) by sizeof(wchar_t) to get wchar_t capacity, which is correct for the destination — but the condition __wn > __n / sizeof(wchar_t) uses integer division that can produce incorrect routing between branches. The fix mirrors the already-correct mbsrtowcs pattern: clamp __wn (the output wide-char count) to the destination's wchar_t capacity, and pass __n (source byte limit) through unchanged.

Fix a POSIX violation for swab

2026-04-30T15:57:51Z

Improve coverage for wmemcpy and wmemmove

2026-04-30T15:50:27Z

Like it's already done for memcpy and memmove. Add tests as well, to prove that nothing broke.

Fix a bug in wcsnrtombs

2026-04-30T15:42:29Z

__d is a char * destination buffer, so __b is already the byte capacity. Dividing by sizeof(wchar_t) makes no sense here, it was likely copy-pasted from mbsnrtowcs (where the destination is wchar_t *). The first branch also fails to limit __n (the byte write cap) to __b, so overflows are possible when a wide character produces multi-byte output. The second branch (else) correctly limits __n to __b. This commit replaces the broken two-branch logic with the simple correct pattern matching wcsrtombs, and adds two tests two prove that nothing broke.

Fix a bug in stpncpy

2026-04-30T15:37:02Z

The manpage says that stpncpy will "copy non-null bytes from the string pointed to by src into the array pointed to by dst.", it doesn't add a terminal NULL byte, so we shouldn't check for it.

Change access of first fgets argument to write_only

2026-04-30T10:57:02Z

Fixes bf242b15e1f7

Avoid overflow warnings in {v,}sprintf

2026-04-20T21:15:31Z

gcc does not seem to reliably notice that the if condition makes overflows impossible in the code. To please the compiler we can use the __bos flag to return 0 (instead of -1) when the size is unknown. Fixes https://github.com/jvoisin/fortify-headers/issues/62 Fixes https://github.com/jvoisin/fortify-headers/issues/68 Fixes https://github.com/jvoisin/fortify-headers/issues/80