- 07 Apr, 2017 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
This includes making builders a little more tolerant of corrupt data. Note that our threat model generally does not expect this tolerance -- we expect that builders always contain either structures created locally or copied in from a reader, which does a certain amount of validation in itself.
-
- 30 Mar, 2017 4 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
-
Kenton Varda authored
TODO: - Rename Guarded to Bounded? - Consider bounded array (where size and indexes are bounded quantities). - Implement non-CAPNP_DEBUG_TYPES fallback. - Don't allow casting kj::maxValue to bounded type, this won't work right when not using debug types! - Verify that this change doesn't hurt performance.
-
- 27 Mar, 2017 1 commit
-
-
Kenton Varda authored
-
- 24 Mar, 2017 1 commit
-
-
Kenton Varda authored
See: https://capnproto.org/news/2015-03-02-security-advisory-and-integer-overflow-protection.html This commit as-is is the result of wading through two years of merge conflicts. It does not build as-is because new code added in that time hasn't been converted over.
-
- 19 Mar, 2017 1 commit
-
-
Kenton Varda authored
-
- 11 Mar, 2017 1 commit
-
-
David Renshaw authored
-
- 10 Mar, 2017 1 commit
-
-
David Renshaw authored
-
- 09 Mar, 2017 2 commits
-
-
David Renshaw authored
-
David Renshaw authored
-
- 08 Mar, 2017 2 commits
-
-
David Renshaw authored
-
David Renshaw authored
-
- 07 Mar, 2017 2 commits
-
-
David Renshaw authored
-
David Renshaw authored
-
- 27 Feb, 2017 2 commits
-
-
David Renshaw authored
-
David Renshaw authored
-
- 26 Feb, 2017 1 commit
-
-
David Renshaw authored
The existing error message suggests this case can only arise if there is a a bug in the library. However, malformed input can trigger the error too. In particular, the error gets thrown when a non-double far pointer resolves to another far pointer.
-
- 25 Feb, 2017 1 commit
-
-
David Renshaw authored
-
- 24 Jan, 2017 1 commit
-
-
Harris Hancock authored
Reads and writes of volatile aligned words are automatically blessed with atomic acquire and release semantics at compile-time by MSVC, leaving only CPU operation reordering to worry about. x86 and x64 CPUs will not reorder the operations, but MSVC targets Xbox, which notably will reorder them, thus I added fences out of an abundance of caution. While Cap'n Proto likely will not compile for Xbox as-is, I would hate for someone to port it only to have to debug obscure atomic-operation-related crashes later. I implemented the fences using std::atomic_thread_fence rather than MemoryBarrier(), because including windows.h in raw-schema.h is a non-starter, and it would be silly to reimplement it with in-line assembly and intrinsics for every targeted CPU when <atomic> is available. Another possible implementation could have been to use the InterlockedXxx functions, however they present a few issues: 1. They're defined in windows.h. We could define them in terms of their underlying _InterlockedXxx intrinsics, but we'd need more #if blocks to handle both 32-bit and 64-bit pointers. If we go this route, it'd probably be better to go all-in and define some kj::atomic{Load,Store} functions. 2. We cannot implement atomic load-acquire semantics with them for const variables without const_casting.
-
- 12 Dec, 2016 1 commit
-
-
David Renshaw authored
-
- 17 Sep, 2016 1 commit
-
-
Mark Grimes authored
-
- 10 May, 2016 1 commit
-
-
Matthew Maurer authored
You can now spawn a canonical message from: * StructReader * AnyStruct::Reader * capnpc-c++ generated Foo::Reader
-
- 02 Apr, 2016 1 commit
-
-
Matthew Maurer authored
-
- 01 Apr, 2016 3 commits
-
-
Matthew Maurer authored
-
Matthew Maurer authored
-
Matthew Maurer authored
-
- 26 Mar, 2016 1 commit
-
-
Matthew Maurer authored
Adding a `KJ_DASSERT` in the `setListPointer` logic flagged non-word-multiple data sections in `INLINE_COMPOSITE` lists, which should be impossible. This traced back to uninitialized member variables in `ListBuilder` in the case that it was created from a null pointer.
-
- 25 Mar, 2016 4 commits
-
-
Matthew Maurer authored
-
Matthew Maurer authored
Initially I meant to ensure the allocator gave back sequential memory in segment0, but ended up using a hope+validate approach. Given this approach, modification of this function adds useless complexity.
-
Matthew Maurer authored
Previously I assumed that data sections in the input StructReader must have data sections which were multiples of words. However, struct upgrade rules allow a StructReader to exist which does not follow that rule. This commit removes that assumption by working in bytes normally, and special casing the 1-bit-struct case.
-
Matthew Maurer authored
-
- 20 Mar, 2016 1 commit
-
-
Matthew Maurer authored
The user facing API is in MessageReader and MessageBuilder {MessageBuilder,MessageReader}::isCanonical verifies the canonicity of a message. This is both useful for debugging and for knowing if a received message can be used for hashes, bytewise equality, etc. MessageBuilder::canonicalRoot(Reader) can be used to write a canonical message on a best effort basis, and checks itself using isCanonical. It should succeed as long as the MessageBuilder in question: * Has a first segment which is long enough to contain the message * Has not been used before Tests have been added in canonicalize-test.c++ which verify that for crafted examples of canonicalization errors, isCanonical will reject, and for a canonicalized version of the standard test message, it will accept.
-
- 13 Jan, 2016 1 commit
-
-
Kenton Varda authored
As of that change, adopting an empty struct into a pointer that already had some other value fails to overwrite the upper 32 bits of the pointer, thus resulting in a struct pointer with totally bogus bounds. Normally this will either cause a bounds check exception to be thrown when that pointer is later accessed, or lead to a struct containing bogus data (but if teh struct was expected to be empty, probably that data is never accessed).
-
- 16 Dec, 2015 1 commit
-
-
David Renshaw authored
-
- 24 Jul, 2015 1 commit
-
-
Kenton Varda authored
Add a way to concatenate lists without losing data when one or more of the lists was written using a newer version of the protocol.
-
- 23 Jul, 2015 2 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
Fix bug causing exception: "'Disembargo' of type 'senderLoopback' sent to an object that does not point back to the sender." The problem happened when pipelined calls were made on a promised capability, but then that capability turned out to be null. The promise resolving code incorrectly interpreted this as the remote promise having resolved to a local capability (because the "null" stub capability looks local), and so it would send a Disembargo message to flush the pipeline as required. However, the remote end would receive this Disembargo message and find it is addressed to a null capability, not a capability pointing back to the sender. This was treated as a protocol error, causing the receiver to close the connection. The solution is to explicitly identity "null" capabilities so that we can distinguish this case. This change also has the benefit that now when you copy a null capability between messages with foo.setCap(bar.getCap()), the pointer will be set null in the destination, rather than becoming a reference to a local broken capability. Thanks to David Renshaw for narrowing this down.
-