1. 07 Apr, 2017 2 commits
  2. 30 Mar, 2017 4 commits
  3. 27 Mar, 2017 1 commit
  4. 24 Mar, 2017 1 commit
  5. 19 Mar, 2017 1 commit
  6. 11 Mar, 2017 1 commit
  7. 10 Mar, 2017 1 commit
  8. 09 Mar, 2017 2 commits
  9. 08 Mar, 2017 2 commits
  10. 07 Mar, 2017 2 commits
  11. 27 Feb, 2017 2 commits
  12. 26 Feb, 2017 1 commit
  13. 25 Feb, 2017 1 commit
  14. 24 Jan, 2017 1 commit
    • Harris Hancock's avatar
      Implement atomic operations for MSVC · d6d06e54
      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.
      d6d06e54
  15. 12 Dec, 2016 1 commit
  16. 17 Sep, 2016 1 commit
  17. 10 May, 2016 1 commit
  18. 02 Apr, 2016 1 commit
  19. 01 Apr, 2016 3 commits
  20. 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
  21. 25 Mar, 2016 4 commits
  22. 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
  23. 13 Jan, 2016 1 commit
    • Kenton Varda's avatar
      Fix message corruption bug introduced in 2c9c5c83. · 4d4f831a
      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).
      4d4f831a
  24. 16 Dec, 2015 1 commit
  25. 24 Jul, 2015 1 commit
  26. 23 Jul, 2015 2 commits
    • Kenton Varda's avatar
      Fix link errors. · 96e9663a
      Kenton Varda authored
      96e9663a
    • Kenton Varda's avatar
      Fix bug causing exception: "'Disembargo' of type 'senderLoopback' sent to an… · d4cd01e9
      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.
      d4cd01e9