apr_memcache flags parameter should be apr_uint32_t, not apr_uint16_t

[Kevac Marko <ma...@kevac.org>]

Hello

apr_memcache flags parameter should be apr_uint32_t, not apr_uint16_t

Comments?

-- 
Marko Kevac

Re: apr_memcache flags parameter should be apr_uint32_t, not apr_uint16_t

[Paul Querna <pa...@querna.org>]

On Sun, Mar 22, 2009 at 8:19 PM, Kevac Marko <ma...@kevac.org> wrote:
> Can someone say something about this?
>
> On Tue, Mar 17, 2009 at 3:08 PM, Kevac Marko <ma...@kevac.org> wrote:
>> Hello
>>
>> apr_memcache flags parameter should be apr_uint32_t, not apr_uint16_t
>>
>> Comments?

No, it should always be an apr_uint16_t, per the protocol specification:
<http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt>
"""
- <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.
  Note that in memcached 1.2.1 and higher, flags may be 32-bits, instead
  of 16, but you might want to restrict yourself to 16 bits for
  compatibility with older versions.
"""

Maybe in a few years once all older memcached servers are gone, or
everyone switches to the binary protocol, then it makes sense.

(or we go around and add -2 postfix functions for all of the
apr_memcache things that can deal with the flags, which i'm fine with
doing, but would rather spend energy on binary protocol support.)

Re: apr_memcache flags parameter should be apr_uint32_t, not apr_uint16_t

[Graham Leggett <mi...@sharp.fm>]

William A. Rowe, Jr. wrote:

> yes, on all architectures to speak of, 8 or 16 are promoted to 32 bits
> anyways, so anything less than a 32 bit flag arg is absurd.
> 
> But we won't/can't address the problem until APR 2.0.

Trunk right now is apr-2.0. :)

Regards,
Graham
--

Re: apr_memcache flags parameter should be apr_uint32_t, not apr_uint16_t

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Kevac Marko wrote:
> On Mon, Mar 23, 2009 at 4:18 AM, William A. Rowe, Jr.
> <wr...@rowe-clan.net> wrote:
>> yes, on all architectures to speak of, 8 or 16 are promoted to 32 bits
>> anyways, so anything less than a 32 bit flag arg is absurd.
>>
>> But we won't/can't address the problem until APR 2.0.
> 
> Why not? It is clearly bug, not just some API change. Memcached flag IS 32 bit.


Because you can't change the binary API, we have to stomach our mistakes
until the next rev...

http://apr.apache.org/versioning.html

Re: apr_memcache flags parameter should be apr_uint32_t, not apr_uint16_t

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Kevac Marko wrote:
> Can someone say something about this?

yes, on all architectures to speak of, 8 or 16 are promoted to 32 bits
anyways, so anything less than a 32 bit flag arg is absurd.

But we won't/can't address the problem until APR 2.0.

> On Tue, Mar 17, 2009 at 3:08 PM, Kevac Marko <ma...@kevac.org> wrote:
>> Hello
>>
>> apr_memcache flags parameter should be apr_uint32_t, not apr_uint16_t
>>
>> Comments?
> 

Re: apr_memcache flags parameter should be apr_uint32_t, not apr_uint16_t

[Kevac Marko <ma...@kevac.org>]

Can someone say something about this?

On Tue, Mar 17, 2009 at 3:08 PM, Kevac Marko <ma...@kevac.org> wrote:
> Hello
>
> apr_memcache flags parameter should be apr_uint32_t, not apr_uint16_t
>
> Comments?

-- 
Marko Kevac