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. > > 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. -- Matthew Winn -- 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
