←back to thread

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

(hwisnu.bearblog.dev)
271 points mithcs | 3 comments | 17 Nov 25 10:40 UTC | HN request time: 0.67s | source
Show context
rurban ◴[17 Nov 25 12:46 UTC] No.45953101[source]▶
Just don't mix that up with the real safec.h header from safeclib:

https://github.com/rurban/safeclib/tree/master/include

replies(1): >>45953192 #
debugnik ◴[17 Nov 25 13:00 UTC] No.45953192[source]▶
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

replies(2): >>45953362 #>>45953655 #
1. quotemstr ◴[17 Nov 25 13:26 UTC] No.45953362[source]▶
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.
replies(1): >>45962715 #
2. debugnik ◴[18 Nov 25 08:30 UTC] No.45962715[source]▶
AFAIK Microsoft's API is still a previous iteration not compliant with the standard annex K.
replies(1): >>45963032 #
3. rurban ◴[18 Nov 25 09:18 UTC] No.45963032[source]▶
## 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...