Module bitmaps 

The bitmap commands, which are string commands wearing a different hat.

A bitmap in Redis is a string, and that is not an implementation detail a caller can ignore: SET k "A" then GETBIT k 1 answers 1, because A is 0x41 and the second bit from the top of that byte is set. So there is no bitmap type here either, and everything in this file works on the same string records strings writes. The kernels are in bits; this is where a key turns into bytes, where a write is allowed to grow a value and where Redis’s edges live.

Three of those edges are worth stating up front, because all three have been measured on a real server rather than reasoned about.

A write always leaves the value raw. SET n 12345 reports int and a SETBIT n 0 0 that changes nothing at all still reports raw afterwards, because Redis unshares the object before it looks at a bit. A read does not: GETBIT n 3 on the same key leaves it int. That is why the in place fast path below only takes a record that is already raw.

A write creates the key and pads it with zero bytes, even when the bit being written is zero and the byte is past the end. SETBIT nokey 0 0 on an empty database leaves a one byte string behind.

A BITFIELD is checked all the way through before any of it runs, so a bad field type in the last subcommand leaves the key untouched and, if it was not there, uncreated. That ordering is the wire layer’s to keep, and it is why Keyspace::bitfield takes a list of already parsed subcommands rather than words to parse.

Structs

Sub

One BITFIELD subcommand.

Enums

SubOp

The three things a BITFIELD subcommand does.

Unit

Whether a range’s two ends count bytes or bits.

Constants

BIT_OFFSET_MAX

The highest bit SETBIT and GETBIT take.

Functions

apply

Run one subcommand against a value, answering what the client is owed.

max_bits

The largest value a bit range can name, for a caller checking its own limit.

reach

How many bytes a value needs before sub can be written into it.