1. 30 Jun, 2018 1 commit
  2. 28 Dec, 2017 1 commit
  3. 23 Oct, 2017 1 commit
  4. 12 Oct, 2017 1 commit
    • Edward Catmur's avatar
      Avoid passing null to memcpy/memcmp/memset · dbc088d1
      Edward Catmur authored
      It is invalid to pass null as a pointer argument to memcpy/memcmp/memset, even if the count argument is zero:
      
      > Where an argument declared as size_t n specifies the length of the array for a
      function, n can have the value zero on a call to that function. Unless explicitly stated
      otherwise in the description of a particular function in this subclause, pointer arguments
      on such a call shall still have valid values [...]
      
      Detected by -fsanitize=nonnull-attribute.
      dbc088d1
  5. 03 Sep, 2017 1 commit
  6. 18 Jul, 2017 1 commit
  7. 07 Jul, 2017 1 commit
    • Edward Catmur's avatar
      Fix link errors with -fsanitize=vptr · 3713c573
      Edward Catmur authored
      [ 66%] Linking CXX executable capnpc-c++
      cd /home/edward.catmur/build/capnproto@master/c++/src/capnp && /usr/local/bin/cmake -E cmake_link_script CMakeFiles/capnpc_cpp.dir/link.txt --verbose=1
      /usr/lib64/icecc/bin/c++   -fsanitize=vptr   CMakeFiles/capnpc_cpp.dir/compiler/capnpc-c++.c++.o  -o capnpc-c++ -rdynamic libcapnp.a ../kj/libkj.a -lpthread
      libcapnp.a(layout.c++.o):(.data+0x38): undefined reference to `typeinfo for capnp::ClientHook'
      libcapnp.a(layout.c++.o):(.data+0x3b8): undefined reference to `typeinfo for capnp::ClientHook'
      collect2: error: ld returned 1 exit status
      
      $ g++ --version
      g++ (GCC) 5.4.0
      Copyright (C) 2015 Free Software Foundation, Inc.
      This is free software; see the source for copying conditions.  There is NO
      warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
      3713c573
  8. 26 Apr, 2017 1 commit
  9. 24 Apr, 2017 1 commit
  10. 21 Apr, 2017 1 commit
  11. 20 Apr, 2017 2 commits
  12. 19 Apr, 2017 2 commits
  13. 16 Apr, 2017 1 commit
  14. 11 Apr, 2017 1 commit
  15. 07 Apr, 2017 2 commits
  16. 30 Mar, 2017 4 commits
  17. 27 Mar, 2017 1 commit
  18. 24 Mar, 2017 1 commit
  19. 19 Mar, 2017 1 commit
  20. 11 Mar, 2017 1 commit
  21. 10 Mar, 2017 1 commit
  22. 09 Mar, 2017 2 commits
  23. 08 Mar, 2017 2 commits
  24. 07 Mar, 2017 2 commits
  25. 27 Feb, 2017 2 commits
  26. 26 Feb, 2017 1 commit
  27. 25 Feb, 2017 1 commit
  28. 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
  29. 12 Dec, 2016 1 commit
  30. 17 Sep, 2016 1 commit