Ken Takata wrote:
> 2016/2/23 Tue 4:19:25 UTC+9 Bram Moolenaar wrote:
> > Dominique Pellé wrote:
> >
> > > "Bram Moolenaar wrote:
> > >
> > > >> getchar.c: In function 'check_map':
> > > >> getchar.c:5221:7: warning: assuming signed overflow does not occur when
> > > >> assuming that (X - c) <= X is always true [-Wstrict-overflow]
> > > >> if (len > mp->m_keylen - 3)
> > > >> ^
> > > >
> > > > That looks like a compiler problem.
> > >
> > >
> > > Line getchar.cpp:5221 is as follows:
> > >
> > > 5221 if (len > mp->m_keylen - 3)
> > >
> > > I don't think that it is spurious warnings, What gcc is saying
> > > here is that when it compiled the code, it made an optimization
> > > which assumed that an addition or subtraction did not overflow
> > > on 32 bits. This is a fair assumption, since overflow with sign
> > > integer is undefined behavior. It is only well defined with unsigned
> > > integers. However, lots of code wrongly assume that signed
> > > integer overflow wrap, which is not correct, and can cause real
> > > bugs when cranking up optimizations. Hence the warning.
> >
> > Unfortunately this is caused by recent C standard where people writing
> > compiler optimizers forced this "undefined behavior" so that they could
> > make programs 0.1% faster. Before this signed integers always
> > predictably overflowed, since practically all CPUs work that way.
> > I never like "undefined behavior".
> >
> > > In this case, if mp->m_keylen was INT_MIN, then
> > > "mp->keylen - 3" would overflow which would be undefined
> > > behavior (bug!). This is probably impossible in this case,
> > > because m_key_len is always a length so positive, so
> > > removing 3 will never overflow.
> > >
> > > That warning does not happen with -O2 but happens with -O3
> > > on my machine.
> > >
> > > Attached patch fixes the warning in getchar.cpp by casting
> > > to unsigned.
> >
> > That makes it:
> > if ((unsigned)len > (unsigned)mp->m_keylen - 3U)
> >
> > That fixes the warning, but isn't that code wrong? if mp->m_keylen is
> > zero the result must be TRUE.
>
> How about including mattn's patch?
> https://groups.google.com/d/msg/vim_dev/-2lLZ5Z2cPM/QQWIf225DwAJ
Because they actually cause an overflow problem (potentionally):
- || top >= bot
+ || top - bot >= 0
The existing line doesn't do any subtraction thus can't overflow, it's a
simple comparison. The second one could have an overflow.
So we are just avoiding a bogus warning, not fixing a problem.
--
ARTHUR: But if he was dying, he wouldn't bother to carve
"Aaaaarrrrrrggghhh". He'd just say it.
BROTHER MAYNARD: It's down there carved in stone.
GALAHAD: Perhaps he was dictating.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// 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.
