Giving C a superpower: custom header file (safe_c.h)

How can anyone be this interested in maintaining an annex k implementation when it's widely regarded as a design failure, specially the global constraint handler. There's a reason why most C toolchains don't support it.

https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

FWIW, it's heavily used inside Microsoft and is actually pretty nice when combined with all the static analysis tools that are mandatory parts of the dev cycle.

It's only regarded as design failure by the linux folks. Maybe because it came from Microsoft, NIH syndrome.

A global constraint handler is still by far better than dynamic env handlers, and most of the existing libc/POSIX design failures.

You can disable this global constraint handler btw.

> Maybe because it came from Microsoft, NIH syndrome.

No it is because you still need to get the size calculation correct, so it doesn't actually have any benefit over the strn... family other than being different.

Also a memcpy that can fail at runtime, seems to be only complicating things. If anything it should fail at compile time.

Microsoft doesn't implement Annex K, either. They ship an non-conforming implementation. Literally no one cares about the "standardized" Annex K version.

AFAIK Microsoft's API is still a previous iteration not compliant with the standard annex K.

If the optimizer cannot see the sizes, it has to defer the error to run-time. If it sees it (as with _FORTIFY_SOURCE=3) it fails at compile0-time already. The difference to _FORTIFY_SOURCE is that it guarantees to fail, whereas with _FORTIFY_SOURCE you never know.

## Microsoft Windows/MINGW_HAS_SECURE_API

* `fopen_s`, `freopen_s` deviate in the API: restrict is missing.

* `strtok_s`, `wcstok_s`,`vsnprintf_s` miss the dmax argument.

* `vsnprintf_s` adds a maxarg argument.

* `vswprintf` adds a maxarg argument on w32. (with `__STRICT_ANSI__` undefined)

* no `strnlen` on mingw32.

* no `errno_t` return type for `qsort_s`, only `void`.

* reversed argument order for `localtime_s` and `gmtime_s`.

* older mingw versions have `wchar.h` with only 2 functions: `wcscmp`, `wcslen`

* no `RSIZE_MAX`

* `memmove_s` does not clear dest with ERANGE when `count > dmax` and EINVAL when src is a NULL pointer.

* `vsprintf_s`, `sprintf_s` return `-1` on all errors, not just encoding errors. (Wrong standard)

* With `wcsrtombs` (used by `wcsrtomb_s`) the `retval` result includes the terminating zero, i.e. the result is `+1` from the spec.

`getenv_s` returns in len the size of the env buffer, not the len, as described in the standard (https://en.cppreference.com/w/c/program/getenv). The Microsoft size is len + 1. Their usage example is also wrong: https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...

In C I am responsible to tell the compiler where my arrays end. How is it supposed to know how many arrays there are in an allocation? Why should the compiler trust one expression about the size, but not the other? If I would want to limit memcpy by the size of the destination, I could write memcpy(dest, src, MAX(dest_size, ...)) instead, but I don't want that most of the time.

The compiler knows about the sizes by either statically allocated sizes (_FORTIFY_SOURCE=2, __builtin_object_size) or malloc'ed sizes (_FORTIFY_SOURCE=3, __builtin_dynamic_object_size). See e.g. https://developers.redhat.com/articles/2022/09/17/gccs-new-f...

Since the user is mostly wrong with memory bounds, the compiler checks it also. And with clang even allows user-defined warnings.

We all known that C programmers know it better, and hate bounds-checks, that's why there are so many out-of-bounds errors still.