1. 11 Apr, 2017 1 commit
  2. 07 Apr, 2017 1 commit
  3. 31 Mar, 2017 1 commit
  4. 30 Mar, 2017 2 commits
    • Kenton Varda's avatar
      Remame Guarded -> Bounded. · 168cb630
      Kenton Varda authored
      168cb630
    • Kenton Varda's avatar
      WIP use bounded types -- all tests passing. · 093fac4a
      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.
      093fac4a
  5. 24 Mar, 2017 1 commit
  6. 08 Mar, 2017 1 commit
  7. 07 Mar, 2017 1 commit
  8. 29 Dec, 2016 1 commit
  9. 02 Oct, 2016 1 commit
  10. 10 May, 2016 1 commit
  11. 06 Apr, 2016 1 commit
  12. 02 Apr, 2016 2 commits
  13. 01 Apr, 2016 1 commit
  14. 26 Mar, 2016 1 commit
    • Matthew Maurer's avatar
      Fix uninitialized members of ListBuilder · 47b92d31
      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.
      47b92d31
  15. 20 Mar, 2016 1 commit
    • Matthew Maurer's avatar
      Add Canonicalization · 5db2c8f8
      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.
      5db2c8f8
  16. 13 Nov, 2015 1 commit
  17. 24 Jul, 2015 1 commit
  18. 22 Jul, 2015 1 commit
  19. 08 Jul, 2015 1 commit
  20. 03 Jul, 2015 1 commit
    • Kenton Varda's avatar
      Refactor how messages are imbued with a capability table. · 5413038b
      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.
      5413038b
  21. 23 Jun, 2015 1 commit
  22. 03 May, 2015 2 commits
  23. 17 Apr, 2015 1 commit
  24. 03 Apr, 2015 1 commit
  25. 01 Apr, 2015 1 commit
  26. 25 Feb, 2015 1 commit
  27. 12 Dec, 2014 1 commit
  28. 24 Nov, 2014 3 commits
  29. 22 Nov, 2014 1 commit
  30. 09 Nov, 2014 2 commits
  31. 26 Oct, 2014 4 commits
    • Joshua Warner's avatar
      0a7bc6e5
    • Kenton Varda's avatar
    • Kenton Varda's avatar
    • Kenton Varda's avatar
      Implement "lite mode", where reflection is disabled. · c772a700
      Kenton Varda authored
      To use, pass --disable-reflection to the configure script.
      
      This produces a smaller runtime library. However, using it for this purpose is not recommended. The main purpose of lite mode is to define a subset of Cap'n Proto which might plausibly compile under MSVC. MSVC still lacks full support for constexpr and expression SFINAE; luckily, most of our use of these things relates to reflection, and not all users need reflection.
      
      Cap'n Proto lite mode inherits its name from Protocol Buffers' lite mode. However, there are some key differences:
      
      - Protobuf generated code included global constructors related to registering descriptors and extensions. For many people, this was the main reason to use lite mode: to get rid of these global constructors and achieve faster startup times. Cap'n Proto, on the other hand, never had global constructors in the first place.
      
      - Schemas are actually still available in lite mode, though only in their raw (Cap'n Proto structure) form. Only the schema API (which wraps the raw schemas in a more convenient interface) and reflection API (which offers a convenient way to use the schemas) are unavailable.
      
      - Lite mode is enabled in an application by defining CAPNP_LITE rather than by specifying an annotation in the schema file. This better-reflects real-world usage patterns, where you typically want to enable lite mode application-wide anyway.
      
      - We do not build the lite mode library by default. You must request it by passing --disable-reflection to the configure script. Before you can do that, you must have a prebuilt Cap'n Proto compiler binary available, since the compiler can't be built without reflection.
      
      - Relatedly, the lite mode library is built with the same name as the full library. This library is not intended to be installed. If anything it should be statically linked. But, mostly the option only exists on non-MSVC platform to give us a way to test that we haven't broken lite mode.
      c772a700