safeclib VS memset_benchmark

Of course assembler spezializations are an anti-pattern, because the optimizer should be fixed to do it much better. Better C code is often 2x faster than hand optimized assembler.

Eg my C memcpy with inlined and vectorized clang beats glibc or gcc memcpy in assembler easily. https://github.com/rurban/safeclib/blob/master/tests/perf_me...

+1 This along with https://github.com/rurban/safeclib (and its forks/derivatives).

I have yet to look into Annex K. It didn't seem to gain much traction. Some people at Red Hat wrote a field experience report about it. I recently discovered an implementation of Annex K functions that claims to be pretty portable, safeclib.

See my testsuite and remarks at https://github.com/rurban/safeclib/blob/master/doc/libc-overview.md , esp. towards the windows implementation

I do it because nobody else implemented a secure memset. What they call secure is just avoiding that the compiler ignores it. A secure memset also cleans the caches with a memory barrier, so that meltdown cannot read it.

explicit_bzero and it's numerous variants are not only insecure, but also slow. (byte wise!)

Only safelibc has a secure memset_s. https://github.com/rurban/safeclib/blob/master/tests/perf_me...

mem* do not need to be called via ifunc. That is a toolchain decision. See e.g. https://github.com/nadavrot/memset_benchmark for recent data about the cost of PLT indirection for small copies.

Probably poorly. It is a violation to cast an unaligned pointer to an aligned type. And the code looks like it does just that right here: https://github.com/nadavrot/memset_benchmark/blob/main/src/l...

This is undefined behavior under C99 §6.3.2.3 Paragraph 7.

I was impressed by the notion until I saw the code...