5 ms·

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 handle

by debugnik 11mo ago

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 https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm

quotemstr 11mo ago
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.
- debugnik 11mo ago
  AFAIK Microsoft's API is still a previous iteration not compliant with the standard annex K.
  - rurban 11mo ago
    ## 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 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/reference/getenv-s-wgetenv-s?view=msvc-170 https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...
rurban 11mo ago
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.
- 1718627440 11mo ago
  > 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.
  - rurban 11mo ago
    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.
    - 1718627440 11mo ago
      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.
      - rurban 11mo ago
        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-fortification-level 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.

quotemstr 11mo ago

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.

debugnik 11mo ago
AFAIK Microsoft's API is still a previous iteration not compliant with the standard annex K.
- rurban 11mo ago
  ## 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 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/reference/getenv-s-wgetenv-s?view=msvc-170 https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...

rurban 11mo ago

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.

1718627440 11mo ago
> 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.
- rurban 11mo ago
  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.
  - 1718627440 11mo ago
    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.
    - rurban 11mo ago
      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-fortification-level 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.