I didn't know about this but I really, really like it
lists.llvm.org/pipermail/cfe-
10
46
207
Conversation
Replying to
feel like vulns “solved” by this aren’t actually solved, as nice as it is to have automatic “fix” for it
2
7
Replying to
it's like -ftrapv or whatever. as long as you use the flag, there is no UB.
1
1
4
wiki.sei.cmu.edu/confluence/dis is also a serious issue and the portable ways of working around it are impractical / unrealistic.
Linux kernel relies on the incorrect assumption that padding bytes will always be copied by the compiler. It depends on a non-existent language extension...
1
1
2
Automatic initialization with a pattern is not necessarily enough. An assignment like `struct foo bar = baz` will not necessarily fully initialize `bar` and may leave padding bytes. Later on, copying the struct across a trust boundary will likely copy padding bytes, leaking data.
1
3
Proposal to declare padding via fields is very error prone and not portable. Structs would need to be correctly declared for each architecture. Struct packing isn't portable either and changes the ABI, along with impacting performance. Only valid option there is serialization.
And sure, in theory, every copy of a struct across trust boundaries could do explicit serialization. It seriously increases the code complexity since it can't be automated away in C, leading to more flaws. It also likely hurts performance and it's simply not practical/realistic.