Re: Gcc and undefined behavior
previously on this list Vincent Lefevre contributed: Plus, crashing in a screensaver is bad :D The sanitizers should be used only for testing / debugging, or possibly for critical applications where it may be better to crash (in a controlled way) than behave erratically with possible system compromission as a consequence. I am not sure exactly what checks you are talking about but isn't this debatable in that if it is more likely to crash early or immediately then the bugs are more likely to be fixed and it could have crashed later anyway at a more critical and less analysed time or led to greater consequences or bugs present in more critical deployments. OpenBSD catches many bugs but they are not the size of Debian which could catch more. Perhaps there is an argument just for testing as oppose to stable? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) In Other Words - Don't design like polkit or systemd ___ I have no idea why RTFM is used so aggressively on LINUX mailing lists because whilst 'apropos' is traditionally the most powerful command on Unix-like systems it's 'modern' replacement 'apropos' on Linux is a tool to help psychopaths learn to control their anger. (Kevin Chadwick) ___ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/113866.98512...@smtp113.mail.ir2.yahoo.com
Re: Gcc and undefined behavior
On Mon, Apr 28, 2014 at 16:45:56 +, Thorsten Glaser wrote: Shachar Shemesh shachar at debian.org writes: the changes there is a runtime check for undefined behavior. Just compile with -fsanitize=undefined, and your program will crash with log if it performs an operation that C/C++ considers to be undefined. This does not help. At all. Consider: • all possible codepaths × • all possible combinations of input/state data Even “just” checking mksh would not work, for example. Let alone OpenSSL. Plus, crashing in a screensaver is bad :D [...] So are we really at a point where we need all the en-vogue techniques applied to each and every package in our distribution? Shouldn't we maybe first sort out some basic problems that the compiler tells us about at no run-time cost? I was slightly in shock when I realised the length of the list at http://qa.debian.org/bls/bytag/W-implicit-declaration.html knowing that bugs such as #702889 would have been caught by the compiler. (And anyway missing function declarations imply a chance of undefined behaviour as per 6.5.2.2, paragraph 10 of ISO C11.) I'm not saying that there aren't any packages benefiting from hardening/sanitisation flags, but type checking and data-flow analyses built into current compilers could do a very decent job already *if only people paid attention to warnings*. And doing static analysis (which, by the way, is a key approach to combat the combinatorial explosion outlined by mirabilos) beyond what compilers do as part of their job will require that the most basic inconsistencies be ironed out first. Best, Michael pgpIHz4zify2L.pgp Description: PGP signature
Re: Gcc and undefined behavior
Shachar Shemesh shachar at debian.org writes: the changes there is a runtime check for undefined behavior. Just compile with -fsanitize=undefined, and your program will crash with log if it performs an operation that C/C++ considers to be undefined. This does not help. At all. Consider: • all possible codepaths × • all possible combinations of input/state data Even “just” checking mksh would not work, for example. Let alone OpenSSL. Plus, crashing in a screensaver is bad :D bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/loom.20140428t184438-...@post.gmane.org
Re: Gcc and undefined behavior
On 2014-04-28 16:45:56 +, Thorsten Glaser wrote: Shachar Shemesh shachar at debian.org writes: the changes there is a runtime check for undefined behavior. Just compile with -fsanitize=undefined, and your program will crash with log if it performs an operation that C/C++ considers to be undefined. This does not help. At all. For you. Clang's sanitizer (which was there before GCC's) helped us to find bugs in MPFR. Consider: • all possible codepaths × • all possible combinations of input/state data There's the same problem with test suites. They can't test every possibility, but they are still useful (for both the developers to test their software and check for regressions, and for the user due to possible compiler bugs). Plus, crashing in a screensaver is bad :D The sanitizers should be used only for testing / debugging, or possibly for critical applications where it may be better to crash (in a controlled way) than behave erratically with possible system compromission as a consequence. In the case of a screensaver, this should only be done for testing / debugging. If the screensaver crashes, this is probably due to a bug one may want to fix. So, this is useful. Perhaps some testers might want to build a full Debian system with -fsanitize=undefined and see what happens... -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140428231502.ga23...@xvii.vinc17.org
Re: Gcc and undefined behavior
On Tue, Apr 29, 2014 at 12:45 AM, Thorsten Glaser wrote: Plus, crashing in a screensaver is bad :D Only if the screensaver or the thing that runs it is written without the possibility of crashes in mind. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6ezvfg5de-imsllsk6msjz0+nu86gioldzhhauji1q...@mail.gmail.com
Re: Gcc and undefined behavior
On 2014-04-24 22:04:40 +0300, Shachar Shemesh wrote: Following the discussion from a few days ago about Cava (C like language with no undefined behavior), gcc 4.9 is now out[1]. One of the changes there is a runtime check for undefined behavior. Just compile with -fsanitize=undefined, and your program will crash with log if it performs an operation that C/C++ considers to be undefined. Not exactly. It will just output a diagnostic. You need gcc-snapshot to use the no-recover option (like clang). Note also that it doesn't check all UB's, e.g. not uninitialized variables... like clang. I tried it on GNU MPFR a few days ago and everything was fine. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140427163120.ga8...@ioooi.vinc17.net
Gcc and undefined behavior
Just a quick FYI for anyone who missed it. Following the discussion from a few days ago about Cava (C like language with no undefined behavior), gcc 4.9 is now out[1]. One of the changes there is a runtime check for undefined behavior. Just compile with -fsanitize=undefined, and your program will crash with log if it performs an operation that C/C++ considers to be undefined. Have not tried it myself, but feedback would be great. Shachar [1] http://gcc.gnu.org/gcc-4.9/changes.html
