4 ms·

Also don't expect memset() to actually be a library call at all.

• rurban 8y ago
  And most importantly dont expect memset to be executed at all. Most -O2 compilers happily optimize the memset away if if doesn't care about the sideeffects. Therefore there exists the "secure" memset variants, which are the insecure variants adding a simple compiler barrier, so it isn't optimized away. And there exists the very few really secure memset_s variants with a real memory barrier which guarantees memset to be executed in load and store order, flushing the cache, so that Spectre attacks are mitigated. security-relevant crypto libraries, like openssl and variants don't care about that, because memory barriers are "too slow". only the Linux kernel does it properly. It's still a mess.
  • FrozenVoid 8y ago
    you can write your own memset that bypasses all of that. Its just 2 lines of code.
    • gmueckl 8y ago
      And that will be slower than calling memset() unless you have a really smart compiler.
    • rurban 8y ago
      I don't trust any memset at all. Literally every single memset I looked at was either broken, too slow or insecure. Mostly the wellknown glibc, freebsd, msvcrt and compiler implementations.
      • rmtgk 8y ago
        That's quite a bold claim. Care to explain further?
        • rurban 8y ago
          I already explained it. Noone implements memory barriers in its safe variants, only compiler barriers. And the trivial variants work byte-wise, not word-wise, which is usually 8x slower.