3 ms·

That's the thing: we live in the real world. Yes the C abstract machine blah blah blah. Ok, but, I called memset for a reason, and the compiler writer, being al

That's the thing: we live in the real world. Yes the C abstract machine blah blah blah. Ok, but, I called memset for a reason, and the compiler writer, being also of the real world, should realize maybe I'm deleting sensitive data? And yes I know there's memset_s but it strikes me as bad prioritization if I have to seek out a secondary function to do what I mean.

gpderetta 5y ago
how can the compiler realize you are deleting sensitive data? The compiler is dumb and just applying a bunch of rules, it has no way to infer intent from your code unless you explicitly tell it so. And no, despite the name, memset does not mean set the memory to 0 anymore than int i = 0 means set the memory to 0. BTW, I think memset_s is also problematic: there is nothing preventing a compiler from storing a copy of your data anywhere else. At the very least is likely to be in registers, possibly partially spilled on the stack.
- overgard 5y ago
  > how can the compiler realize you are deleting sensitive data? It can't, so don't remove my memset. Why is this hard. Compilers are dumb, yes, so don't delete the thing I wrote on purpose. You are right about the definition of memset. It's unreliable. My point is why is that ok with anyone sane. If I clear 128 bytes on a stack frame that's returning, sure, it's not optimal, but the compiler doesn't know why I did it and I surely did it for a reason. The definition of memset is bad.
  - gpderetta 5y ago
    why do you even expect those 128 bytes to be on a stack frame at all? I would expect the compiler to keep stuff in registers as much as it can and reuse stack slots as soon as they are no longer needed. And I would certainly expect to remove dead stores aggressively. I don't use memset much, but I use memcpy and certainly do want (and expect) the compiler convert memcpys to register moves when possible and even to eliminate them when the result is not actually used.

gpderetta 5y ago

how can the compiler realize you are deleting sensitive data? The compiler is dumb and just applying a bunch of rules, it has no way to infer intent from your code unless you explicitly tell it so. And no, despite the name, memset does not mean set the memory to 0 anymore than int i = 0 means set the memory to 0. BTW, I think memset_s is also problematic: there is nothing preventing a compiler from storing a copy of your data anywhere else. At the very least is likely to be in registers, possibly partially spilled on the stack.

overgard 5y ago
> how can the compiler realize you are deleting sensitive data? It can't, so don't remove my memset. Why is this hard. Compilers are dumb, yes, so don't delete the thing I wrote on purpose. You are right about the definition of memset. It's unreliable. My point is why is that ok with anyone sane. If I clear 128 bytes on a stack frame that's returning, sure, it's not optimal, but the compiler doesn't know why I did it and I surely did it for a reason. The definition of memset is bad.
- gpderetta 5y ago
  why do you even expect those 128 bytes to be on a stack frame at all? I would expect the compiler to keep stuff in registers as much as it can and reuse stack slots as soon as they are no longer needed. And I would certainly expect to remove dead stores aggressively. I don't use memset much, but I use memcpy and certainly do want (and expect) the compiler convert memcpys to register moves when possible and even to eliminate them when the result is not actually used.