1. 15 Jun, 2016 1 commit
  2. 05 Jun, 2016 1 commit
  3. 31 May, 2016 1 commit
    • antirez's avatar
      Avoid undefined behavior in BITFIELD implementation. · 2503acfc
      antirez authored
      Probably there is no compiler that will actaully break the code or raise
      a signal for unsigned -> signed overflowing conversion, still it was
      apparently possible to write it in a more correct way.
      
      All tests passing.
      2503acfc
  4. 30 May, 2016 1 commit
  5. 18 May, 2016 1 commit
  6. 10 May, 2016 1 commit
  7. 02 Mar, 2016 3 commits
  8. 29 Feb, 2016 1 commit
  9. 26 Feb, 2016 3 commits
    • antirez's avatar
      BITFIELD: Fix #<index> form parsing. · 11745e09
      antirez authored
      11745e09
    • antirez's avatar
      BITFIELD: Support #<index> offsets form. · 2800d090
      antirez authored
      2800d090
    • antirez's avatar
      BITFIELD command initial implementation. · 70af626d
      antirez authored
      The new bitfield command is an extension to the Redis bit operations,
      where not just single bit operations are performed, but the array of
      bits composing a string, can be addressed at random, not aligned
      offsets, with any width unsigned and signed integers like u8, s5, u10
      (up to 64 bit signed integers and 63 bit unsigned integers).
      
      The BITFIELD command supports subcommands that can SET, GET, or INCRBY
      those arbitrary bit counters, with multiple overflow semantics.
      
      Trivial and credits:
      
      A similar command was imagined a few times in the past, but for
      some reason looked a bit far fetched or not well specified.
      Finally the command was proposed again in a clear form by
      Yoav Steinberg from Redis Labs, that proposed a set of commands on
      arbitrary sized integers stored at bit offsets.
      
      Starting from this proposal I wrote an initial specification of a single
      command with sub-commands similar to what Yoav envisioned, using short
      names for types definitions, and adding control on the overflow.
      
      This commit is the resulting implementation.
      
      Examples:
      
          BITFIELD mykey OVERFLOW wrap INCRBY i2 10 -1 GET i2 10
      70af626d
  10. 27 Jul, 2015 1 commit
  11. 26 Jul, 2015 4 commits
  12. 11 Dec, 2014 1 commit
    • Matt Stancliff's avatar
      Bitops: Stop overallocating storage space on set · badf0f00
      Matt Stancliff authored
      Previously the string was created empty then re-sized
      to fit the offset, but sds resize causes the sds to
      over-allocate by at least 1 MB (which is a lot when
      you are operating at bit-level access).
      
      This also improves the speed of initial sets by 2% to 6%
      based on quick testing.
      
      Patch logic provided by @oranagra
      
      Fixes #1918
      badf0f00
  13. 03 Dec, 2014 1 commit
  14. 02 Dec, 2014 1 commit
  15. 13 Aug, 2014 1 commit
  16. 30 Mar, 2014 1 commit
    • antirez's avatar
      String value unsharing refactored into proper function. · 543ede03
      antirez authored
      All the Redis functions that need to modify the string value of a key in
      a destructive way (APPEND, SETBIT, SETRANGE, ...) require to make the
      object unshared (if refcount > 1) and encoded in raw format (if encoding
      is not already REDIS_ENCODING_RAW).
      
      This was cut & pasted many times in multiple places of the code. This
      commit puts the small logic needed into a function called
      dbUnshareStringValue().
      543ede03
  17. 27 Feb, 2014 4 commits
    • antirez's avatar
      warnigns -> warnings in redisBitpos(). · 76a6e82d
      antirez authored
      76a6e82d
    • antirez's avatar
      More consistent BITPOS behavior with bit=0 and ranges. · 0e31eaa2
      antirez authored
      With the new behavior it is possible to specify just the start in the
      range (the end will be assumed to be the first byte), or it is possible
      to specify both start and end.
      
      This is useful to change the behavior of the command when looking for
      zeros inside a string.
      
      1) If the user specifies both start and end, and no 0 is found inside
         the range, the command returns -1.
      
      2) If instead no range is specified, or just the start is given, even
         if in the actual string no 0 bit is found, the command returns the
         first bit on the right after the end of the string.
      
      So for example if the string stored at key foo is "\xff\xff":
      
          BITPOS foo (returns 16)
          BITPOS foo 0 -1 (returns -1)
          BITPOS foo 0 (returns 16)
      
      The idea is that when no end is given the user is just looking for the
      first bit that is zero and can be set to 1 with SETBIT, as it is
      "available". Instead when a specific range is given, we just look for a
      zero within the boundaries of the range.
      0e31eaa2
    • antirez's avatar
      Initial implementation of BITPOS. · 38c620b3
      antirez authored
      It appears to work but more stress testing, and both unit tests and
      fuzzy testing, is needed in order to ensure the implementation is sane.
      38c620b3
    • antirez's avatar
      Fix misaligned word access in redisPopcount(). · 746ce35f
      antirez authored
      746ce35f
  18. 22 Jul, 2013 1 commit
    • antirez's avatar
      Introduction of a new string encoding: EMBSTR · 894eba07
      antirez authored
      Previously two string encodings were used for string objects:
      
      1) REDIS_ENCODING_RAW: a string object with obj->ptr pointing to an sds
      stirng.
      
      2) REDIS_ENCODING_INT: a string object where the obj->ptr void pointer
      is casted to a long.
      
      This commit introduces a experimental new encoding called
      REDIS_ENCODING_EMBSTR that implements an object represented by an sds
      string that is not modifiable but allocated in the same memory chunk as
      the robj structure itself.
      
      The chunk looks like the following:
      
      +--------------+-----------+------------+--------+----+
      | robj data... | robj->ptr | sds header | string | \0 |
      +--------------+-----+-----+------------+--------+----+
                           |                       ^
                           +-----------------------+
      
      The robj->ptr points to the contiguous sds string data, so the object
      can be manipulated with the same functions used to manipulate plan
      string objects, however we need just on malloc and one free in order to
      allocate or release this kind of objects. Moreover it has better cache
      locality.
      
      This new allocation strategy should benefit both the memory usage and
      the performances. A performance gain between 60 and 70% was observed
      during micro-benchmarks, however there is more work to do to evaluate
      the performance impact and the memory usage behavior.
      894eba07
  19. 26 Jun, 2013 1 commit
  20. 17 May, 2013 1 commit
  21. 08 May, 2013 1 commit
    • antirez's avatar
      Revert "use long long instead of size_t make it more safe" · 0ae1b5b0
      antirez authored
      This reverts commit 2c75f2cf.
      
      After further analysis, it is very unlikely that we'll raise the
      string size limit to > 512MB, and at the same time such big strings
      will be used in 32 bit systems.
      
      Better to revert to size_t so that 32 bit processors will not be
      forced to use a 64 bit counter in normal operations, that is currently
      completely useless.
      0ae1b5b0
  22. 07 May, 2013 2 commits
  23. 28 Jan, 2013 2 commits
  24. 19 Jan, 2013 1 commit
  25. 08 Nov, 2012 1 commit
  26. 05 Sep, 2012 1 commit
    • Haruto Otake's avatar
      BITCOUNT: fix segmentation fault. · 749aac72
      Haruto Otake authored
      remove unsafe and unnecessary cast.
      until now, this cast may lead segmentation fault when end > UINT_MAX
      
      setbit foo 0 1
      bitcount  0 4294967295
      => ok
      bitcount  0 4294967296
      => cause segmentation fault.
      
      Note by @antirez: the commit was modified a bit to also change the
      string length type to long, since it's guaranteed to be at max 512 MB in
      size, so we can work with the same type across all the code path.
      
      A regression test was also added.
      749aac72
  27. 18 Jul, 2012 1 commit
    • antirez's avatar
      Don't assume that "char" is signed. · b62bdf1c
      antirez authored
      For the C standard char can be either signed or unsigned, it's up to the
      compiler, but Redis assumed that it was signed in a few places.
      
      The practical effect of this patch is that now Redis 2.6 will run
      correctly in every system where char is unsigned, notably the RaspBerry
      PI and other ARM systems with GCC.
      
      Thanks to Georgi Marinov (@eesn on twitter) that reported the problem
      and allowed me to use his RaspBerry via SSH to trace and fix the issue!
      b62bdf1c
  28. 31 May, 2012 1 commit
    • antirez's avatar
      BITOP bug when called against non existing keys fixed. · 1419406e
      antirez authored
      In the issue #529 an user reported a bug that can be triggered with the
      following code:
      
      flushdb
      set a
      "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
      bitop or x a b
      
      The bug was introduced with the speed optimization in commit 8bbc0768
      that specializes every BITOP operation loop up to the minimum length of
      the input strings.
      
      However the computation of the minimum length contained an error when a
      non existing key was present in the input, after a key that was non zero
      length.
      
      This commit fixes the bug and adds a regression test for it.
      1419406e