Paul Querna wrote:
Joe Orton wrote:
- apr_memcache_hash's data_len argument, apr_memcache_conn_t.blen ,
storage_cmd_write's *_size arguments are all apr_uint32_t and look like
they should be apr_size_t, any reason why that is?
Ah, now I remember why. The memcached protocol states that these data
lengths are all unsigned 32bit ints. So, they can never hold values
larger, or the server will not understand.
So, we violate a basic apr design principal for an oddball service that we
are seeking to support? Or return APR_EINVAL when someone tries to set
aside 10GB? (This is a rather funny quibble when you consider how horrid
using an external socket-cached data store to set aside 10GB for 'quick
access' later on ;-)
If apr-util is designed to be a pluggable abstraction layer, and we all
concur that
char *buf;
apr_size_t *bufsize;
apr_dosomething(*buf, &bufsize);
is our normalized style, obviously this patch was correct, irrespective
of whatever this particular backend cache supports.
FYI - why apr_memcache? Unless it's either an in-memory cache, or some
cache virtualized by page-fault retrieval, this is definately misnamed,
or beholden to one oddball external project.
Bill
