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.
> 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.
--
It is illegal for a driver to be blindfolded while operating a vehicle.
[real standing law in Alabama, United States of America]
/// 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.
