3 ms·
The standards body move very slowly. More practical approach is to push compilers to add more options to define undefined behavior so that we have safety with t
by netheril96 10y ago
The standards body move very slowly. More practical approach is to push compilers to add more options to define undefined behavior so that we have safety with the minor cost of performance. We already have -fwrapv, -ftrapv and -fno-strict-aliasing. We could ask for more and a general -fsafe flag.
- mastax 10y agoUBSan is not quite the same thing, but it's quite good. http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html http://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html
- pjmlp 10y ago> We already have -fwrapv, -ftrapv and -fno-strict-aliasing. You have it in specific compilers, not in the standard. Not everyone is able to go installing clang and gcc on their work platform, when there are so many compilers to choose from. https://en.wikipedia.org/wiki/List_of_compilers#C.2B.2B_compilers https://en.wikipedia.org/wiki/List_of_compilers#C.2B.2B_comp...
- byuu 10y agoI definitely use -fwrapv already. Unfortunately, there is no -fhonor-precedence-associativity switch in GCC or Clang. And I would need it in both to support all the systems I target. But even moreso, yes!! I would love if we had a -fsafe directive that turned undefined behavior from "do whatever is fastest" into "do whatever is most expected." I would seriously start paying $100 a year to use such a compiler -- not even joking a little. Unfortunately, as I've said, the compiler devs seem to have lost touch completely with the developers using the language and love playing these nasty games with UB. So I'm not sure how we can go about getting them to implement such a flag. And I just don't have the bandwidth to fork and maintain GCC or Clang to do it myself =(