Error in Protocol Docs?
brad at danga.com
Sat Apr 28 16:36:18 UTC 2007
Historically, at least, it was only 16 bits. It might only be 16 bits
currently on accident, and might be truncated back to 16 bits in the
future if we go on another struct item packing mission.
But yeah -- perhaps we should do a range check on it to prevent people
from getting bitten?
Does anybody remember when this changed from 16 bit to 32 bit, and if
there was a good reason?
On Sat, 28 Apr 2007, Alex Stapleton wrote:
> - <flags> is an arbitrary 16-bit unsigned integer (written out in
> decimal) that the server stores along with the data and sends back
> when the item is retrieved. Clients may use this as a bit field to
> store data-specific information; this field is opaque to the server.
> However looking at the source, and testing it out myself, this
> appears to be a lie. unsigned 32-bit ints appear to be used to store
> flags with no range checks which means it works just fine if you
> store 32-bit values in there. afaict the high 16-bits aren't used for
> anything internally either. Is this right? Is it safe to use values
> >65535 in the flags field of a key? Being able to stick a 32-bit
> value in there certainly is rather handy with the rather unusual
> configuration we are using :)
> Alex Stapleton
> alexs at advfn.com
> T: 0207 0700 956
More information about the memcached