Also, signed overflow being undefined rather than defined as wrapping means that more secure implementations where it traps are permitted. Passing -fsanitize=signed-integer-overflow -fsanitize-trap=signed-integer-overflow is standards compliant and used for hardening in AOSP.
Conversation
Similarly, lots of other UB that's easy to catch with simple branches at runtime (not most memory and type safety issues, but lots of other bugs) can be made to trap while remaining standards compliant, including enforcing not dereferencing outside many objects with object-size.
1
Implementations of memory safety for C via fat pointers, etc. also depend on these things being undefined. By making it acceptable to index from one object into another and dereference the pointer, you would be forbidding memory safe implementations of C which are very important.
1
If the fat pointers define new behavior then it’s ok for that definition to contradict “classic C”. C making it defined or not only enables you to “say” that a secure version of C is “compliant”. It’s not a bad thing if you had to say that it was non compliant to classic C.
1
They don't define any new behavior. They catch undefined behavior like out-of-bounds accesses and use-after-free. These things are already broken and non-portable. C is deliberately very portable and permits implementations that are memory safe. It even permits using a GC.
2
You keep saying what C *is* which isn't relevant to me, since I'm proposing what it *should be*. (More specifically, I think that like many folks, I want an -fno-bullshit, which turns off optimizations introduced by people who don't understand C.)
1
1
I think it's you that doesn't understand C. The whole point behind the C standard is that it's extremely portable and permits a broad range of implementation choices and aggressive optimization. You want a new variation of the language, which is fine, but I don't think it helps.
2
Millions of lines of C code uses things that the spec doesn’t allow and it works because compilers can’t really do all the things that the spec allows without breaking real code. That confirms my understanding, not yours.
1
Sure, and most C code is full of memory corruption bugs even including lots of latent memory corruption that occurs in regular usage rather than just edge cases (like an exploit). I'm well aware that real world C code is filled with lots of undefined behavior. It hinders my work.
1
That's not how undefined behavior is defined. That's your own definition, and it's not clear to me how your definition is meant to work. For example, you seem okay with uninitialized memory from malloc changing value, but yet not local variables, which is very arbitrary.
Since you want to permit out-of-bounds accesses, you want to forbid real world partial / full memory safety implementations that are being deployed. You would even forbid _FORTIFY_SOURCE, not just -fsanitize=object-size. Another good example would be function pointer typing.
1
The C standard forbids calling a function pointer that has a mismatched type with the function. So for example, calling a function `void foo(char *)` via `void (*foo)(void *)` is undefined. This is what type-based Control Flow Integrity (CFI) enforces to mitigate exploitation.
1
Show replies