https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116457
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > but it is already in reliable real-world use. Then that real world use is broken. >It's a pretty isolated change and doesn't impact any later stages of >compilation. It is not exactly isolated, that is if there is an option, someone will try it and then get broken code. Did you run the full GCC testsuite with it turned on to see what breaks? Do you have a formal definition of what works with it and what does NOT? Why have a seperate option for the seed? Rather than reuse -frandomize-layout-seed ? Is it because you want to force folks to always use a different seed from the seed which is going to be there for reproducibility or just because it is another obscure option? This could introduce new security issues just by having it, rather than security by obscurity. For an example someone's code is not ready for this layout change but then it messes up. Also why only C and not C++? At least in C++ you have local linkage structs (e.g. structs defined inside an anonymous namespaces) so you don't have a push to force things to be consistent between TUs. Does clang (or the plugin) warn if a struct with randomize_layout is used with an exported symbol? what about taking the address and then passing it around? Do es it have some kind of flow sensitive warning because without that it is 100% a security issue waiting to happen.
