Do you think Annex K of C11 will be widely adopted by programmers or unused? Why aren't people adopting it?
Do you see the use of any analysis tools that are particularly effective for finding memory safety issues?
C++ added in smart pointers to its specification. Are there any plans to do something similar in future C specifications?
Thanks!
So far, it's not been widely adopted. Part of the issue is that there are specification issues relating to threads and the constraint handlers, and part of the issue is that popular libc implementations have actively resisted implementing the annex.
That said, I field questions about Annex K on a regular basis and there are a few implementations in the wild, so there is user interest in the functionality.
> Do you see the use of any analysis tools that are particularly effective for finding memory safety issues?
<biased opinion>I think CodeSonar does a great job at finding memory safety issues, but I work for the company that makes this tool.</biased opinion>
I've also had good luck with the memory and address sanitizers (https://github.com/google/sanitizers) and tools like valgrind.
> C++ added in smart pointers to its specification. Are there any plans to do something similar in future C specifications?
We currently don't have any proposals for adding smart pointers to C. Given that C does not have constructors or destructors, we would have to devise some new mechanism to implement or replace RAII in C, which would be one major hurdle to overcome for smart pointers.
This can be done in C, but the calling code has to spell malloc and free differently.
In debug mode, configuring malloc to poison (and add fences) on allocation and free finds most of the remaining things.
These techniques tend to have much lower runtime overhead than valgrind (2-digit percentages vs 5-10x), so they can be left on throughout testing and partially enabled in production.
They find >90% of the memory bugs that I write (assuming valgrind finds 100%). YMMV.
why would you have to devise a new mechanism and not borrow one from one of the thousand other mechanisms already existing in PL litterature for this ?
By the time the ISO/IEC TR 24731-1:2007 was released, and then later Annex K added to the C Standard, Microsoft had to decide if they wanted to change the interfaces to conform to the changed standard and re-implement their code bases. They presumably decided that they did not, which I think is a defensible decision.
As to unergonomic, examples please?
As to unergonomic, that's somewhat subjective. But I'm a long-time C practitioner and that's my feel of the API. Constraint handlers are a mistake. Ambient state that is not part of the function interface, as well as asynchronous interaction, make for poor APIs. Constraint handlers are a mismatch for library use of safe functions, as well as kernel environments.
Most functions seem pointless; e.g., snprintf_s. Re-adding gets() in the form of gets_s() seems unhelpful. Why bsearch_s, qsort_s, memcpy_s/memmove_s?? Do you really think strerror_s() is useful? Or strnlen_s()?
Microsoft just changed one bit of the proposal, but no one followed them there. Currently it's the most widely used and worst implemented. I tested all of them.
It solves the bounds checking problem better than _FORTIFY_SOURCE, ASAN and valgrind, because it does the checks always, if compile-time or run-time, independent on the optimizer, the used intrinsics, where valgrind fails, and is much faster than ASAN. Also faster than glibc btw.