3 ms·

First of all, there is no way the compiler is going to optimize a call to memset(&foo, 0, sizeof(foo)) when &foo is being interpreted as a void pointer. That d

by shawxe 6y ago

First of all, there is no way the compiler is going to optimize a call to memset(&foo, 0, sizeof(foo)) when &foo is being interpreted as a void pointer. That doesn't even make sense. Second of all, in a generic C interface keys are likely to be treated as void pointer and almost certainly are going to be moved around with memcpy etc. rather than returned/passed by value since doing so would make the interface non-generic.

dependenttypes 6y ago
The HN markdown ate your stars.
- shawxe 6y ago
  Thanks for letting me know, should be better now! :-)
  - kazinator 6y ago
    Basically, put a space after the star that you want to render verbatim, and don't try to do that in a region of text that is already italicized with stars. E.g. "... being interpreted as a void * type."
scatters 6y ago
The compiler knows what memset does. One of the earliest steps of optimization is replacing calls to well-known functions with intrinsics. Try it! https://godbolt.org/z/QUREQi https://godbolt.org/z/QUREQi Yes, it's true that generic C code will type-erase the key type. However it just takes a little refactoring in specific code to move the struct initialization across a call boundary from where it is passed to the generic code.
- kazinator 6y ago
  The compiler knows that memset clobbers an object, and can classify that as a dead store. I'm skeptical about compilers optimizing memset not to cover padding between structure members. Firstly, that would introduce security holes into a heck of a lot more existing code compared to code that uses a dead-store memset to wipe sensitive crypto. Secondly, it wouldn't run any faster. Gaps in a structure and at the end exist in order to eliminate misalignment. Before most padding, there is a member that ends on a misaligned address. It's slower to update just that member, and leave the padding alone, than to clobber the padding. For instance if we have a { char a; int b; char c; } structure, we gain nothing by zeroing just one byte of a, b and c. In some compiler for an 8 bit system, this reasoning is likely false; I will worry about it when porting to that. Very little existing code will fit; you're coding from scratch for such things.
jcelerier 6y ago
> First of all, there is no way the compiler is going to optimize a call to memset(&foo, 0, sizeof(foo)) when &foo is being interpreted as a void pointer. That doesn't even make sense. that is really dangerous to assume. memset is a compiler built-in in every relevant C++ compiler and the compiler definitely knows the type of the object that is behind your void* and knows if you're being nasty. e.g. look at this code : https://gcc.godbolt.org/z/xh9BXs https://gcc.godbolt.org/z/xh9BXs it's UB, and the compiler knows it and inserts an "invalid opcode" instruction even if you try to hide a memset behind a void*-taking function
- saagarjha 6y ago
  -Ofast makes non-compliant programs anyways, so it's not the best example.
  - jcelerier 6y ago
    I had -Ofast in there but you can check that it's the same with -O2

by shawxe 6y ago

dependenttypes 6y ago

The HN markdown ate your stars.

shawxe 6y ago
Thanks for letting me know, should be better now! :-)
- kazinator 6y ago
  Basically, put a space after the star that you want to render verbatim, and don't try to do that in a region of text that is already italicized with stars. E.g. "... being interpreted as a void * type."

scatters 6y ago

The compiler knows what memset does. One of the earliest steps of optimization is replacing calls to well-known functions with intrinsics. Try it! https://godbolt.org/z/QUREQi https://godbolt.org/z/QUREQi Yes, it's true that generic C code will type-erase the key type. However it just takes a little refactoring in specific code to move the struct initialization across a call boundary from where it is passed to the generic code.

kazinator 6y ago
The compiler knows that memset clobbers an object, and can classify that as a dead store. I'm skeptical about compilers optimizing memset not to cover padding between structure members. Firstly, that would introduce security holes into a heck of a lot more existing code compared to code that uses a dead-store memset to wipe sensitive crypto. Secondly, it wouldn't run any faster. Gaps in a structure and at the end exist in order to eliminate misalignment. Before most padding, there is a member that ends on a misaligned address. It's slower to update just that member, and leave the padding alone, than to clobber the padding. For instance if we have a { char a; int b; char c; } structure, we gain nothing by zeroing just one byte of a, b and c. In some compiler for an 8 bit system, this reasoning is likely false; I will worry about it when porting to that. Very little existing code will fit; you're coding from scratch for such things.

jcelerier 6y ago

> First of all, there is no way the compiler is going to optimize a call to memset(&foo, 0, sizeof(foo)) when &foo is being interpreted as a void pointer. That doesn't even make sense. that is really dangerous to assume. memset is a compiler built-in in every relevant C++ compiler and the compiler definitely knows the type of the object that is behind your void* and knows if you're being nasty. e.g. look at this code : https://gcc.godbolt.org/z/xh9BXs https://gcc.godbolt.org/z/xh9BXs it's UB, and the compiler knows it and inserts an "invalid opcode" instruction even if you try to hide a memset behind a void*-taking function

saagarjha 6y ago
-Ofast makes non-compliant programs anyways, so it's not the best example.
- jcelerier 6y ago
  I had -Ofast in there but you can check that it's the same with -O2