2017-05-05 23:23 GMT+03:00 Bram Moolenaar <[email protected]>:
>
> 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.
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.
>
>> Currently, Vim runs afoul of undefined behavior as can easily be seen
>> with a -fsanitize=undefined build by running
>>
>> if has('num64')
>> echo float2nr(pow(2, 62)) * 2
>> else
>> echo float2nr(pow(2, 30)) * 2
>> endif
>>
>> It would be nice for there to be defined behavior here for the user,
>> instead of exposing them to the whims of the compiler implementation.
>
> Unfortunately, that is quite difficult. I propose the compiler standard
> gets fixed. This means only the few compilers that exist need to take
> care of this, instead of the millions of C programs.
>
> --
> Every person is responsible for the choices he makes.
>
> /// 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
>
> ---
> 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.
--
--
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.
