Skip to content
  1. Dec 13, 2022
  2. May 08, 2022
  3. Apr 24, 2022
  4. Apr 09, 2022
  5. Jan 06, 2019
    • Eugene Kim's avatar
      (Re)define ssize_t as make_signed<size_t> · 4cd343c4
      Eugene Kim authored
      On macOS, the previous code chose int64_t as ssize_t, and int64_t is
      defined as long long, but ssize_t had been defined as long (despite also
      being 8 bytes).  This caused the typedef to be non-idempotent.
      
      make_signed<size_t> chooses the right counterpart, depending on the base
      type of size_t, e.g. unsigned long -> long, unsigned long long -> long
      long, which is more robust when there are distinct base integer types
      with the same size.
      4cd343c4
  6. Dec 07, 2018
    • Eugene Kim's avatar
      Fix ubsan linking · a5d42977
      Eugene Kim authored
      That is, do not manually pass -lubsan to the linker, but specify the
      same -fsanitize=XXX flags to the linker.  This is the correct way for
      both GCC and Clang.
      a5d42977
  7. Nov 12, 2018
  8. Aug 04, 2018
  9. Apr 17, 2018
  10. Apr 14, 2018
  11. Apr 13, 2018
  12. Apr 10, 2018
  13. Apr 07, 2018
  14. Apr 06, 2018
  15. Apr 05, 2018
  16. Mar 30, 2018
  17. Mar 29, 2018
  18. Mar 17, 2018
    • Luker's avatar
      Phase1 bugfixing · 257fdf5a
      Luker authored
      
      
      2 bugs found in phase1
      
      * wrong row tracking
      * did not account for non_zero == 1
      
      After looking at that code again, I think it needs a
      small rewrite, some things could be a bit more efficient...
      
      Signed-off-by: default avatarLuca Fulchir <luker@fenrirproject.org>
      257fdf5a
  19. Mar 16, 2018
  20. Mar 13, 2018
  21. Mar 11, 2018
    • Luker's avatar
      RFC6330 conformity · 714185d6
      Luker authored
      We were doing really bad stuff.
      * we were not using the correct block size, but instead
        creating something completely out-of standard
        This surely means that we were not compatible with
        OpenRQ (Ticket #20), and possibly a reason for which
        decoding fails too ofter (Ticket #21).
      * We used the wrong ESI number, which should skip
        the padding numbers (#23, #20
      
      )
      * we did not expose the real block size to the user
        of the RFC namespace (RFC iterators)
      
      Signed-off-by: default avatarLuca Fulchir <luker@fenrirproject.org>
      714185d6
  22. Mar 10, 2018
  23. Mar 06, 2018
  24. Mar 03, 2018
    • Luker's avatar
      RFC6330 Documentation · e1b41f22
      Luker authored
      
      
      update docs: a variable was renamed to keep the
      C and C++ versions in sync
      
      Signed-off-by: default avatarLuca Fulchir <luker@fenrirproject.org>
      e1b41f22
    • Luker's avatar
      C API cleanup · 74aa4e1c
      Luker authored
      
      
      ...which brings some API breakage :(
      
      notable things:
      
      * C and C++ names for structs and variables are now in sync
      * common.hpp is much easier to read
      * added "trcked by" "tracks ..." to know that some things
        are to be kept in synch between C and C++
      * "RaptorQ_Dec_Result" name was too similar to
        "RaptorQ_Decoder_Result". The C++ version calls it
        "Decoder_wait_res", let's go with that, at least it
        is more different and actually more to the point.
      
      Signed-off-by: default avatarLuca Fulchir <luker@fenrirproject.org>
      74aa4e1c
    • Luker's avatar
      C RAW API: reintroduce decode_once · be450e2d
      Luker authored
      
      
      Just using wait() on the future does not give the
      same semantic meaning as decode_once, which can sometimes
      be needed.
      
      Also, the C++ API exposes that, so the C API should really
      track it.
      
      Signed-off-by: default avatarLuca Fulchir <luker@fenrirproject.org>
      be450e2d