summaryrefslogtreecommitdiff
path: root/src/ziplist.c
Commit message (Collapse)AuthorAgeFilesLines
* fix comments forgotten in #285 (zipmap -> ziplist)Pierre Chapuis2013-02-111-2/+2
|
* BSD license added to every C source and header file.antirez2012-11-081-0/+30
|
* Set p to its new offset before modifying itPieter Noordhuis2012-08-221-7/+8
|
* Add ziplist test for deleting next to last entriesPieter Noordhuis2012-08-221-0/+53
|
* Don't assume that "char" is signed.antirez2012-07-181-4/+4
| | | | | | | | | | | | 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!
* ziplistFind(): don't assume that entries are comparable by encoding.antirez2012-06-151-5/+10
| | | | | | | | | | | | | | | | | | | | Because Redis 2.6 introduced new integer encodings it is no longer true that if two entries have a different encoding they are not equal. An old ziplist can be loaded from an RDB file generated with Redis 2.4, in this case for instance a small unsigned integers is encoded with a 16 bit encoding, while in Redis 2.6 a more specific 8 bit encoding format is used. Because of this bug hashes ended with duplicated values or fields lookup failed, causing many bad behaviors. This in turn caused a crash while converting the ziplist encoded hash into a real hash table because an assertion was raised on duplicated elements. This commit fixes issue #547. Many thanks to Pinterest's Marty Weiner and colleagues for discovering the problem and helping us in the debugging process.
* Compare integers in ziplist regardless of encodingPieter Noordhuis2012-05-041-5/+4
| | | | | | | Because of the introduction of new integer encoding types for ziplists in the 2.6 tree, the same integer value may have a different encoding in different versions of the ziplist implementation. This means that the encoding can NOT be used as a fast path in comparing integers.
* Spurious debugging printf removed.antirez2012-04-241-1/+0
|
* Added two new encodings to ziplist.cantirez2012-04-241-19/+46
| | | | | | | | | | 1) One integer "immediate" encoding that can encode from 0 to 12 in the encoding byte itself. 2) One 8 bit signed integer encoding that can encode 8 bit signed small integers in a single byte. The idea is to exploit all the not used bits we have around in a backward compatible way.
* ziplist.c: added comments about the new 24 bit encoding.antirez2012-04-241-0/+4
|
* Add a 24bit integer to ziplists to save one byte for ints that canGrisha Trubetskoy2012-04-241-0/+16
| | | | | | | fit in 24 bits (thanks to antirez for catching and solving the two's compliment bug). Increment REDIS_RDB_VERSION to 6
* Big endian fix. The bug was introduced because of a typo.antirez2012-03-231-1/+1
|
* Merge conflicts resolved.antirez2012-03-091-75/+140
|\
| * Implements ziplistFindPieter Noordhuis2012-01-031-75/+140
| | | | | | | | | | | | To improve the performance of the ziplist implementation, some functions have been converted to macros to avoid unnecessary stack movement and duplicate variable assignments.
* | endian.c/h -> endianconv.c/h to avoid issues with broken libraries search paths.antirez2012-02-141-1/+1
| |
* | ziplist.c endianess fixes, chapter 5.antirez2012-02-091-1/+1
| |
* | ziplist.c endianess fixes, chapter 4.antirez2012-02-091-1/+1
| |
* | ziplist.c endianess fixes, chapter 3.antirez2012-02-091-10/+18
| |
* | more ziplist.c endianess fixesantirez2012-02-081-2/+2
| |
* | ziplist.c fixes for bigendianantirez2012-02-081-24/+28
|/
* Fixed a few warnings compiling on Linux.antirez2011-10-231-1/+3
|
* Use string2ll in ziplist code (faster)Pieter Noordhuis2011-05-051-16/+2
|
* Fix ziplist regression and update stresserPieter Noordhuis2011-05-051-31/+34
|
* Merge branch 'unstable' into unstable-zsetPieter Noordhuis2011-04-061-0/+10
|\ | | | | | | | | Conflicts: src/object.c
| * ziplist are now endianess agnosticantirez2011-03-091-0/+10
| |
* | Offset should be size_tPieter Noordhuis2011-03-141-6/+8
|/
* encoded types API to get blob lengthantirez2011-02-281-2/+2
|
* Fix compiler warnings on SolarisPieter Noordhuis2010-12-231-2/+4
|
* LRANGE converted into a COW friendly command. Some refactoring, comment, and ↵antirez2010-12-071-1/+6
| | | | new addReply*() family function added in the process.
* removed a number of stupid compilation warnings on Linuxantirez2010-11-021-14/+16
|
* Replace ziplist stresser and fix regressionPieter Noordhuis2010-10-141-41/+100
|
* Add regression test and fix for >255 byte string entriesPieter Noordhuis2010-09-231-1/+20
|
* Allow a random seed argument for the ziplist test binaryPieter Noordhuis2010-09-071-0/+4
|
* Fix updating the prevlen field of consecutive entriesPieter Noordhuis2010-09-071-13/+208
| | | | | | | In the condition where the prevlen field of the next entry on insert and delete operations needs more bytes to be properly encoded, the next entry also needs to be updated with a new prevlen. This patch makes sure that this effect cascades throughout the ziplist.
* Make ziplist schema more efficient for strings with length > 15Pieter Noordhuis2010-08-131-83/+144
|
* fixed a ziplist bug about encoding of integer values overflowing 64 bitantirez2010-07-271-6/+20
|
* Compilation fixed on Linux after the source code splitantirez2010-07-011-1/+1
|
* redis.c split into many different C files.antirez2010-07-011-0/+959
networking related stuff moved into networking.c moved more code more work on layout of source code SDS instantaneuos memory saving. By Pieter and Salvatore at VMware ;) cleanly compiling again after the first split, now splitting it in more C files moving more things around... work in progress split replication code splitting more Sets split Hash split replication split even more splitting more splitting minor change