2 ms·
> Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed. This irked me, because along w
by zrm 7y ago
> Therefore, we propose that Annex K be either removed from the next revision of the C standard, or deprecated and then removed.
This irked me, because along with useless junk like memcpy_s, Annex K had memset_s, which in particular (and unlike memset(3)) was guaranteed not to be optimized out by the compiler.
Meanwhile Spectre has made it more important than ever for programs to clear any sensitive data out of memory as soon as it's no longer needed, so we actually need that. And it's troublesome to either have half a dozen ifdefs for all the different platform-specific functions that do the same thing, with as many possibilities to call one of them wrong, or have to pick up a dependency on a crypto library just to get e.g. sodium_memzero().
- rurban 7y agoNot arguing with your useless junk attitude. Useless junk is the glibc and its FORTIFY_SOURCE "maybe we catch it or maybe not" attempt. But sodium_memzero() is not safer than memset_s. If only provides a compiler barrier, but no memory barrier. AFAIK only my safeclib memset_s is "safe", but I don't provide a clflush there. Maybe I should.
- zrm 7y agoAll the more reason there should be a function in the C standard that does it properly and uniformly across platforms.