Matthew Winn wrote: > On Wed, 07 Nov 2012 16:04:41 +0100, Bram Moolenaar > <[email protected]> wrote: > > > Dominique Pelle wrote: > > > > > I ran "make test" with vim-7.3.712 compiled with IOC > > > (http://embed.cs.utah.edu/ioc/), a tool that detects integer > > > overflows, which behave in undefined way according to > > > the C standard. Only unsigned integer is guaranteed to > > > behave in a predictable way. IOC found a few bugs: > > > > The actual problem is in the standard. Having integer operations behave > > in an undefined way is not very useful. They should have defined > > uniform behavior. It's the compiler writers who like these things to be > > undefined, not the users. > > It's useful because the alternative would require the compiler to > check for overflow after every operation if the underlying hardware > behaved differently from the standard. Almost from the beginning it > was C's policy to prefer efficiency and put the burden of avoiding > non-portable behaviour on the programmer rather than slow everything > down by checking things that rarely matter.
I don't know any hardware that behaves different with overflow. All CPUs just discard the upper bits. it's the software that has a problem. And then instead of solving this in the compiler, it's left to every progammer to figure out. AFAIK the C99 standard was written mostly by compiler writers. They have their own view on the world and made choices that are not always what a programmer would do. This standardization work is often very boring and time consuming, which results in people who just want to get things done not get involved. I'm sure I will never be part of it, just because it takes too much time. I believe in specs that are written by a small team of dedicated people. And I don't believe in design by comittee. > > > There is one more undefined behavior operation (float divide by 0 > > > which is also undefined in C). Fixing it would require to use the > > > INFINITY macro I think but it's C99 macro and Vim needs to compile on > > > older compilers so I did not fix it: > > > > Undefined? I thought divide by zero always results in INF. What > > compiler does otherwise? > > I think it depends on the floating-point hardware, if there is any. > I remember hearing of systems that didn't have Inf or NaN but I don't > remember using one myself. If the hardware doesn't support it then should the compiler take care of it or should every programmer know exactly what is going on and write bulky code to handle it? I think it's best when the compiler does it. Anyway, C99 does define INF and NaN, thus it must be supported, either with hardware or otherwise. -- Q: What is the difference betwee open-source and commercial software? A: If you have a problem with commercial software you can call a phone number and they will tell you it might be solved in a future version. For open-source software there isn't a phone number to call, but you get the solution within a day. /// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php
