Actions
Bug #5126
openUnreliable (or ill-designed?) test case Encoding/TestBlock/Construction/FromBlock
Status:
New
Priority:
Normal
Assignee:
-
Category:
Base
Target version:
-
Start date:
Due date:
% Done:
0%
Estimated time:
Tags:
Description
const uint8_t BUFFER[] = {0x80, 0x06, 0x81, 0x01, 0x01, 0x82, 0x01, 0x01};
Block block(BUFFER, sizeof(BUFFER));
[...]
Buffer otherBuffer(BUFFER, sizeof(BUFFER));
BOOST_CHECK_THROW(Block(block, otherBuffer.begin(), block.end()), std::invalid_argument);
BOOST_CHECK_THROW(Block(block, block.begin(), otherBuffer.end()), std::invalid_argument);
BOOST_CHECK_THROW(Block(block, otherBuffer.begin(), otherBuffer.end()), std::invalid_argument);
There are several problems here:
- Depending on the memory allocator behavior,
block
andotherBuffer
may be allocated contiguously one after the other, such thatblock.begin() == otherBuffer.end()
or vice versa. If that's the case, the checks inBlock()
won't trigger aninvalid_argument
exception, but laterreadType()
/readVarNumber()
will throw atlv::Error
which is not caught by theBOOST_CHECK_THROW
, thus causing a test failure. - The invocation of the
Block
constructor seen above is arguably invalid. The iterators being passed belong to different underlying buffers/containers. Given that comparing unrelated iterators is undefined behavior in C++, these invocations should not be considered valid code. - Taking a step back, what is the goal of these checks in the
Block
constructor? As pointed out above, nothing can fully prevent the caller from passing garbage arguments to the constructor, so those checks seem to have limited utility to me, while they introduce some (tiny) overhead. IMHO they should beBOOST_ASSERT
s at most.
Actions