This also matches what the linux kernel does for it’s memzero_explicit.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/string.h#n260
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/compiler.h#n88
However, Jens Gustedt suggests in his blog post that
- All caches for the byte array should have been invalidated on return.
Wait a second, 7.26.6.2 of n3220 says nothing about invalidating caches. Let’s see what the spec says:
The memset_explicit function copies the value of c (converted to an unsigned char) into each of the first n characters of the object pointed to by s. The purpose of this function is to make sensitive information stored in the object inaccessible.367)
367)The intention is that the memory store is always performed (i.e. never elided), regardless of optimizations. This is in contrast to calls to the memset function (7.26.6.1)
You have a whole lot of architectural specific complexity in [libc][c23] add memset_explicit by SchrodingerZhu · Pull Request #83577 · llvm/llvm-project · GitHub for flushing cache lines, that I’m not even sure is correct (at least, it will take some time to verify). Why should we add such semantics that aren’t part of the spec? Perhaps users of memset_explict use arch specific methods of cache invalidation if they require that.