- 14 Oct, 2019 1 commit
-
-
Vitali Lovich authored
For Visual Studio we have to wrap the headers with push/pop pragmas at the top and bottom of the file. Define common macros for suppress/unsuppress KJ & the appropriate macros for CAPNP begin/end header wrappers. Because there's a chicken egg problem the KJ_BEGIN_HEADER/CAPNP_BEGIN_HEADER macros are placed below all includes to ensure that the appropriate common.h file has been sourced.
-
- 12 Aug, 2018 1 commit
-
-
Kenton Varda authored
-
- 30 Jun, 2018 1 commit
-
-
Nils Fenner authored
-
- 11 Jan, 2018 1 commit
-
-
Kenton Varda authored
@kloepper pointed out a while back that every compiler you've ever heard of supports this. Plus, it's more concise, it's not prone to copy-paste errors, and it looks nicer. At the time I wanted to remain consistent and I didn't feel like spending the time to update all my existing code. But, every time I've added a new header since I've cursed the include guard, so I finally broke down and changed it.
-
- 28 Dec, 2017 1 commit
-
-
Kenton Varda authored
-
- 11 Apr, 2017 1 commit
-
-
Kenton Varda authored
This eliminates a TODO(soon).
-
- 07 Apr, 2017 1 commit
-
-
Kenton Varda authored
-
- 31 Mar, 2017 1 commit
-
-
Kenton Varda authored
-
- 30 Mar, 2017 2 commits
-
-
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.
-
- 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.
-
- 08 Mar, 2017 1 commit
-
-
David Renshaw authored
-
- 07 Mar, 2017 1 commit
-
-
David Renshaw authored
-
- 29 Dec, 2016 1 commit
-
-
Eric Fiselier authored
-
- 02 Oct, 2016 1 commit
-
-
David Renshaw 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
-
- 06 Apr, 2016 1 commit
-
-
Harris Hancock authored
This seems to work now in VS2015, and its presence causes assumption failures (static assertions) in dynamic.c++.
-
- 02 Apr, 2016 2 commits
-
-
Matthew Maurer authored
-
Liam Staskawicz authored
fixes #304
-
- 01 Apr, 2016 1 commit
-
-
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.
-
- 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 Nov, 2015 1 commit
-
-
Kenton Varda authored
Requested by jo_liss on Twitter: https://twitter.com/jo_liss/status/664884038252027905 (Also implement defaultValue<>() helper which was defined but apparently never implemented.)
-
- 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.
-
- 22 Jul, 2015 1 commit
-
-
Kenton Varda authored
Also introduce a way to copy a struct or list which applies membranes to all embedded capabilities, since this seems like it will be needed in conjuction with the above.
-
- 08 Jul, 2015 1 commit
-
-
Kenton Varda authored
-
- 03 Jul, 2015 1 commit
-
-
Kenton Varda authored
**The problem** The methods MessageReader::initCapTable() and MessageBuilder::getCapTable() always felt rather hacky. initCapTable() in particular feels like something that should be handled by the constructor. However, in practice, the cap table is often initialized based on a table encoded within the message itself. That is, an RPC message contains a "payload" which includes both the application-level message structure and a table of capabilities. The cap table has to be processed first, then initCapTable() is called on the overall message, before the application structure can safely be read. The really weird part about this is that even though the cap table only applies to one branch of the message (the payload), it is set on the *whole* MessageReader. This implies, for example, that it would be impossible to have a message that contains multiple payloads. We haven't had any need for such a thing, but an implemnetation that has such artificial limitations feels very wrong. MessageBuilder has similar issues going in the opposite direction. All of this ugliness potentially gets worse when we introduce "membranes". We want a way to intercept capabilities as they are being read from or written to an RPC payload. Currently, the only plausible way to do that is, again, to apply a transformation to all capabilities in the message. In practice it seems like this would work out OK, but it again feels wrong -- we really want to take a single Reader or Builder and "wrap" it so that transformations are applied on capabilities read/written through it. **The solution** This change fixes the problem by adding a new pointer to each struct/list Reader/Builder that tracks the current cap table. So, now a Reader or Builder for a particular sub-object can be "imbued" with a cap table without affecting any other existing Readers/Builders pointing into the same message. The cap table is inherited by child Readers/Builders obtained through the original one. This approach matches up nicely with membranes, which should make their implementation nice and clean. This change unfortunately means that Readers and Builders are now bigger, possibly with some performance impact.
-
- 23 Jun, 2015 1 commit
-
-
Kenton Varda authored
Fix bug where calling a list setter using a list obtained from a similarly-typed getter, but where the underlying pointer was null, would write an incorrectly-typed pointer in the destination (specifically, an empty List(Void)). Now it sets an empty list of the correct type.
-
- 03 May, 2015 2 commits
-
-
Kenton Varda authored
-
Tom Lee authored
-
- 17 Apr, 2015 1 commit
-
-
Kenton Varda authored
-
- 03 Apr, 2015 1 commit
-
-
joshuawarner32@gmail.com authored
-
- 01 Apr, 2015 1 commit
-
-
joshuawarner32@gmail.com authored
-
- 25 Feb, 2015 1 commit
-
-
Kenton Varda authored
-
- 12 Dec, 2014 1 commit
-
-
Kenton Varda authored
-
- 24 Nov, 2014 3 commits
-
-
Kenton Varda authored
-
Kenton Varda authored
The project file still only compiles a test binary, but it should be easy to separate out a library project from here. Thanks again to Bryan Boreham <bjboreham@gmail.com> for much help getting this working.
-
Kenton Varda authored
-
- 22 Nov, 2014 1 commit
-
-
Kenton Varda authored
This prevents the compiler from reporting warnings in these headers while compiling application code. Hopefully this will stem the never-ending stream of complaints from people who enable pedantic warnings.
-
- 09 Nov, 2014 1 commit
-
-
Kenton Varda authored
-