4 ms·

The problem with programming is almost never the lack of smartness. It's almost always the opposite: People being too clever. The sane thing in a realistic sce

by 1ris 5y ago

The problem with programming is almost never the lack of smartness. It's almost always the opposite: People being too clever. The sane thing in a realistic scenario is to ban all usage of memset and add a diagnostic to use memset_s, like any responsible programmer should do with strcpy. Then however, was it really wise to make this machinery, that the people who need it the most are most likely to not have, necessary? I really, really don't think so. \Edit: Here is some code written by a very smart person, Niels Fugerson. I think (not sure) it tries to wipe sensive material from memory and gets it wrong. Really not sure, tho. https://github.com/MacPass/KeePassKit/blob/master/TwoFish/twofish.c https://github.com/MacPass/KeePassKit/blob/master/TwoFish/tw...

ncmncm 5y ago
Yes, this code gets it wrong. It demonstrates that there are many different meanings for "smart", and even for "smart programmer". Nobody qualifies for all of them.
- 1ris 5y ago
  If Niels Furgerson does not qualify as "smart" for programming I don't and I don't think i have ever met anyone who does.
  - halayli 5y ago
    being smart doesn't eliminate the possibility of making mistakes. Are you expecting that a smart human being isn't going to make mistakes? Go through the revision history and see how many bugs got fixed.
halayli 5y ago
There's absolutely nothing wrong with using memset. I don't understand why you would suggest such a ban. If your goal is to scrub a memory region after you're completely done using it then you shouldn't use memset. Compilers won't optimize out memset if it changes the program's behavior within the boundaries of abstract machine's specification. A call to memset to clear a memory region after you're done with it because a password was stored there can be optimized out because it doesn't change the behavior of the program. The code you shared is incorrect if your definition of correctness here includes K being wiped out.
- overgard 5y ago
  > A call to memset to clear a memory region after you're done with it because a password was stored there can be optimized out because it doesn't change the behavior of the program. Well, that does change the behavior of the program. After all, the behavior of the program was to wipe the memory. The programmer specified it. The compiler is clearly wrong by any reasonable measure. It's removing an intentional, clearly specified instruction. It's just wrong. It's making an "interpretation" of something the programmer intended as a fact, and breaking things in the process. Why does anyone think this is desirable? Any good programmer knows that correctness comes before speed. I've been programming C++ since 1998 and I didn't even know this till reading this thread. Blaming the user here is counterproductive. Compilers should not make this optimization, plain and simple. memset should set the memory. If you think otherwise, I invite you to take responsibility for all the users data you have placed in harms way.
  - overgard 5y ago
    Btw to the downvoters, explain to me why a function that is clearly intended to create a side effect that is visible outside the process, IE something you cant reason about, is safe to remove? Memory debuggers are not new or exotic tech. Why do you think that is reasonable to remove if a programmer clearly thought it should be done?
    - dagenix 5y ago
      > explain to me why a function that is clearly intended to create a side effect that is visible outside the process This is simply not accurate. memset_s provides that guarantee. memset does not. It would appear that you have been under the impression that it did. However, it did not.
      - rurban 5y ago
        It does not. Almost all memset_s implementations are broken, just mine not. memset_s just ensures that the unsane compiler will not optimize it away, whilst it should also ensure that is fenced. Otherwise you can still read the memory from the cache. Calling the ordinary memset_s secure is a bug, it's a mere convenience function.

by 1ris 5y ago

ncmncm 5y ago

Yes, this code gets it wrong. It demonstrates that there are many different meanings for "smart", and even for "smart programmer". Nobody qualifies for all of them.

1ris 5y ago
If Niels Furgerson does not qualify as "smart" for programming I don't and I don't think i have ever met anyone who does.
- halayli 5y ago
  being smart doesn't eliminate the possibility of making mistakes. Are you expecting that a smart human being isn't going to make mistakes? Go through the revision history and see how many bugs got fixed.

halayli 5y ago

There's absolutely nothing wrong with using memset. I don't understand why you would suggest such a ban. If your goal is to scrub a memory region after you're completely done using it then you shouldn't use memset. Compilers won't optimize out memset if it changes the program's behavior within the boundaries of abstract machine's specification. A call to memset to clear a memory region after you're done with it because a password was stored there can be optimized out because it doesn't change the behavior of the program. The code you shared is incorrect if your definition of correctness here includes K being wiped out.

overgard 5y ago
> A call to memset to clear a memory region after you're done with it because a password was stored there can be optimized out because it doesn't change the behavior of the program. Well, that does change the behavior of the program. After all, the behavior of the program was to wipe the memory. The programmer specified it. The compiler is clearly wrong by any reasonable measure. It's removing an intentional, clearly specified instruction. It's just wrong. It's making an "interpretation" of something the programmer intended as a fact, and breaking things in the process. Why does anyone think this is desirable? Any good programmer knows that correctness comes before speed. I've been programming C++ since 1998 and I didn't even know this till reading this thread. Blaming the user here is counterproductive. Compilers should not make this optimization, plain and simple. memset should set the memory. If you think otherwise, I invite you to take responsibility for all the users data you have placed in harms way.
- overgard 5y ago
  Btw to the downvoters, explain to me why a function that is clearly intended to create a side effect that is visible outside the process, IE something you cant reason about, is safe to remove? Memory debuggers are not new or exotic tech. Why do you think that is reasonable to remove if a programmer clearly thought it should be done?
  - dagenix 5y ago
    > explain to me why a function that is clearly intended to create a side effect that is visible outside the process This is simply not accurate. memset_s provides that guarantee. memset does not. It would appear that you have been under the impression that it did. However, it did not.
    - rurban 5y ago
      It does not. Almost all memset_s implementations are broken, just mine not. memset_s just ensures that the unsane compiler will not optimize it away, whilst it should also ensure that is fenced. Otherwise you can still read the memory from the cache. Calling the ordinary memset_s secure is a bug, it's a mere convenience function.