Hi Kenton, Thanks for the quick response, that's very helpful. Krzysztof On Sunday, October 22, 2017 at 7:11:14 PM UTC-4, Kenton Varda wrote: > > 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] <javascript:>> > 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::IntChunk>(); >> 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] <javascript:>. >> 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.
