> My question is, how can we craft a test case to tickle that finding?
>
> I've looked at the issue and my conclusion is that the system is making a
> mistake (may be wrong though).
>
> It assumes that t1 may get up to 63 in step 27, it then goes through a
> standard-for-loop, noticing that j=0 < 1 = 64 - 63 in step 28 and 29,
> meaning we get back to the start of the loop (step 30) but now we increment
> to j=1 (step 31) and check if j = 1 < 1 = 64 - 63 (step 32), which is
> obviously false, so t1 + j couldn't get 63 + 1 (which results undefined
> behavior) but only 63 + 0 (which is allowed).
>
OK, thanks. I'm still not clear on it. Its not your analysis, my analysis
or Coverity's analysis... Its simply error'ing on the side of caution.
Here's what we are interested int:
for (unsigned int j=0; j<WORD_BITS-t1; j++)
temp ^= ((temp >> j) & 1) << (t1 + j);
temp ^= ((temp >> j) & 1) << (t1 + j) reduces to:
x << (t1 + j);
Here's the equality we are interested in:
(t1 + j) < WORD_BITS-t1
And it must be less than WORD_BITS. So we should be able to assert on:
2 * t1 + j < WORD_BITS
Does that sound about right?
Jeff
--
--
You received this message because you are subscribed to the "Crypto++ Users"
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
More information about Crypto++ and this group is available at
http://www.cryptopp.com.
---
You received this message because you are subscribed to the Google Groups
"Crypto++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
