On Sat, May 6, 2017 at 9:05 AM, Bram Moolenaar <[email protected]> wrote: > > James McCoy wrote: > >> >> Recently, there was some work done on defining how to handle converting >> >> numeric literals in vim script to C integers -- basically, clamp to the >> >> extremes of the datatype. If it would exceed the max/min value, then >> >> just treat it as the max/min value. >> >> >> >> However, there's nothing defining how arithmetic behaves when it would >> >> exceed the range of the datatype. The only information in the help is: >> >> >> >> Number A 32 or 64 bit signed number. |expr-number| >> >> *Number* >> >> 64-bit Numbers are available only when compiled with the >> >> |+num64| feature. >> >> >> >> Now, in C signed over/underflow is undefined behavior. If you're "lucky", >> >> the implementation will wrap but it could just as well optimize the code >> >> under the assumption that the code can't over/underflow. >> > >> > Yeah, I consider this a bug in the C standard. Undefined behavior is >> > useless, the only reason I suspect this is done is so that compiler >> > writers can makey the code < 1% faster. And at the same time require >> > programmers to handle all the edge cases, which gets really complicated >> > and everybody forgets about. >> >> “Undefined behaviour” allows using one and the same standard on a >> bunch of incompatible systems. E.g. you cannot define the result of a >> signed integer overflow if one system you target for is using one’s >> complement and another is using two’s complement: either in one case >> or another you will end up with much more then 1% slowdown of integer >> operations. > > Nearly all CPUs use two's compliment and overflow is very well defined. > If there are some (embedded CPUs) that behave differently they should > use another standard. Of course companies don't like that, because they > have to admit they don't implement the "normal" C standard. This is > a political choice, not a technical one. >
I'd like to suggest that people make choices for reasons. If you're unable to spend what is likely to be an amount of time equal to what they spent originally understanding their problem understanding their problem, you don't really have any room to criticize their solution. Do I know of any processors that actually implement one's arithmetic? No. Do I know any that implement strange arithmetic that the C standard body could easily make incompatible with C by tightening the standards? Yes, I gave some. And note per my other reply before this that wrapping arithmetic generally isn't what is wanted anyway, and needs constant workarounds to help secure code. >> Though it would be probably better to make the standard modular, >> splitting away implementation-specific details and making them defined >> on per-architecture basis, additionally allowing programmers to state >> “I want *that* behaviour, ready to deal with the slowdown myself”. >> >> You may want to thank C authors that they have not chosen to support >> ternary system as well, with the same standard. Though I do not think >> C would be popular in this case. > > The C language was originally made for a wide range of CPU, even weird > ones. Now that 99.9% of computers are fairly standard it would be a bad > idea to suffer from supporting those conrder cases. > > Compilers could also support a flag to "define" that "undefined" > behavior, garanteeing the outcome, and perhaps suffering a tiny bit in > optimization. > 99.9% of computers aren't fairly standard at all, because that number still includes microcontrollers. If you look at any given vendor there are bound to be a slew of products that have extremely novel (well, sometimes) pieces of hardware attached to the processor on die. While most of them are accessed by memory mapped registers some are so integrated into the flow control of the main core that the C standard makes exceptions (see the floating point part of the standard, though I admit most of it is now a historical curiosity). -- -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
