This change fixes MSVC level-3 warning C4334.
See: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-3-c4334
All `DisableSpecificWarnings` dropped from `fuzz.vcxproj` as all
remained are inherited from `common.init.vcxproj`.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--006a51241073e994b41acfe9ec718e94-->
For detailed information about the code coverage, see the test coverage report.
<!--021abf342d371248e50ceaed478a90ca-->
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | maflcko, sipsorcery |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
utACK b50d127a7710d790c2ba4a08f01b832c2a0b1203
cc @sipsorcery
62 | @@ -63,9 +63,9 @@ class PoolResourceFuzzer 63 | { 64 | if (m_total_allocated > 0x1000000) return; 65 | size_t alignment_bits = m_provider.ConsumeIntegralInRange<size_t>(0, 7); 66 | - size_t alignment = 1 << alignment_bits; 67 | + size_t alignment = size_t{1} << alignment_bits; 68 | size_t size_bits = m_provider.ConsumeIntegralInRange<size_t>(0, 16 - alignment_bits); 69 | - size_t size = m_provider.ConsumeIntegralInRange<size_t>(1U << size_bits, (1U << (size_bits + 1)) - 1U) << alignment_bits; 70 | + size_t size = m_provider.ConsumeIntegralInRange<size_t>(size_t{1} << size_bits, (size_t{1} << (size_bits + 1)) - 1U) << alignment_bits;
was the 1U deliberately kept here?
It causes no issues?
I don't have MSVC to test, just seemed suspicious. If it was deliberate, please resolve this comment.
I don't have MSVC to test, just seemed suspicious.
Do you mind elaborating your concerns?
If it was deliberate, please resolve this comment.
The MSVC warning C4334 is caused by the type of the left-hand side operand in the << operator. This PR is focused on resolving only this issue. I can't see reasons to introduce unrelated code modifications.
Do you mind elaborating your concerns?
Looked like it's still on the LHS of a shift ((size_bits + 1)) - 1U) << alignment_bits), but it's not, no concerns, thanks for checking.
utACK b50d127a7710d790c2ba4a08f01b832c2a0b1203