Hi Krzysztof, In the usual tradition of C++, we don't do runtime array bounds checking in release builds, since such checks bloat the code and waste CPU cycles. Primitive list accessors would probably not be inlineable if they contained bounds checks, which would be a big deal. We do generally do runtime checks in debug builds (but it's possible some locations aren't covered -- happy to accept a patch). Like any other array overflow, if you set() out-of-range, you'll overwrite some arbitrary memory (probably part of the message, since capnp messages are allocated contiguously).
(Note, of course, that we *do* do thorough bounds checking on the message content itself, to protect against malicious messages. But the index you pass to set() isn't expected to be tainted input.) -Kenton On Sun, Oct 22, 2017 at 6:44 AM, <[email protected]> wrote: > Hi, > > I'm hoping for some clarification about why things work the way they (seem > to) do. I wrote some test code > to better understand how using capnp messages works. In one of the tests > I have a list > of int values and I assumed that if I assigned a value out of range for > the builder that > the `set` call would throw, but it doesn't (accessing the element does). > Here's the test from > gtest: > > TEST(intChunkTests, OffByOneVectorIntChunk) { > std::vector<u_int> vec = {3, 5, 7, 8}; > > ::capnp::MallocMessageBuilder message; > capnStan::IntChunk::Builder chunk = message.initRoot<capnStan::Int > Chunk>(); > chunk.setId(33); > chunk.setOffset(101); > chunk.setLength(4); > ::capnp::List<uint64_t>::Builder values = chunk.initValues(4); > values.set(4, 100); // I thought this would throw... what _does_ > happen? <------- > > EXPECT_EQ(chunk.getId(), 33); > EXPECT_EQ(chunk.getOffset(), 101); > EXPECT_EQ(chunk.getLength(), 4); > EXPECT_EQ(chunk.getValues()[0], 0); > EXPECT_EQ(chunk.getValues()[1], 0); > EXPECT_EQ(chunk.getValues()[2], 0); > EXPECT_EQ(chunk.getValues()[3], 0); // This all works as expected, > test passes > EXPECT_THROW(chunk.getValues()[4], std::exception); // This throws (so > the test passes). > } > > If I had something in my schema after the values list if it would get > clobbered by writing out-of-range? > Why not check 'set' at runtime? (efficiency?) > > Thanks for any insight, > > Krzysztof > > > -- > You received this message because you are subscribed to the Google Groups > "Cap'n Proto" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https://groups.google.com/group/capnproto. > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
