Re: Minor libmemcache issue inside php extension

> I worked on a php extension wrapper for libmemcache over the weekend 
> and
> made good progress.  Currently get, set, replace, add, stats, and
> add_server are all working. I still need to implement multi-gets, and I
> need to consider whether the callback mechanism makes sense to 
> implement
> in php, as well as whether trying to implement persistent memcache()
> objects makes sense for the initial release.

Persistent memcache objects make sense, but not requests or anything 
else like that.  I wouldn't do callbacks for PHP unless someone 
requests it, but ... well, I don't hear many people screaming for a PHP 
SAX interface.

> I did run into one minor issue, it seems that the %hu and %zu format
> strings do not work.

Grrr...  This is where I start to hate gcc'isms and the lack of 
standards in the grey areas of what should be apart of a standard.  
size_t (ie: uint32_t or uint64_t) is universally standard, but size_t 
has variable widths depending on the architecture, yet there is no 
printf(3) format specifier that's universal when converting it to a 
string.  On OS-X and FreeBSD from fprintf(3):

         Modifier          d, i           o, u, x, X            n
         hh                signed char    unsigned char         signed 
char *
         h                 short          unsigned short        short *
         l (ell)           long           unsigned long         long *
         ll (ell ell)      long long      unsigned long long    long 
long *
         j                 intmax_t       uintmax_t             
intmax_t *
         t                 ptrdiff_t      (see note)            
ptrdiff_t *
         z                 (see note)     size_t                (see 
note)
         q (deprecated)    quad_t         u_quad_t              quad_t *

There is no equiv fprintf(3) format string on many other OSes.  Think 
it'd fly if I said the solution to this can be found here:

http://www.FreeBSD.org/

?  Probably not, eh?  Crap.  Alright, I'll convert this to %u for now 
with the explicit understanding that you're going to take a cluebat to 
each and every broken distro out there and ask them to get their shit 
together.  Thanks in advance.  *grin*

> I can only assume php is overriding my systems
> snprintf as they always work outside of the php extension.  What is
> happening is that they don't fail gracefully either, and they just
> output SET key %zu 0 %hu or whatever to the server, which obviously
> fails.

%u had better work as a format specifier.

> As such I'm currently working with having patched the
> mcm_storage_command to just use %u in place of %hu and %zu.

Ah, cool... arrived at the same solution.

> Maybe for portability it should just be changed to that?

Yup, already done.

> I plan to clean up my php extension work and finish up the remaining
> methods tonight.  Hopefully I'll post up an initial release by tommorow
> morning.

It's been exciting to see your benchmarks.  :)  1.2.1 is minutes away 
from seeing the light of day.  -sc

--
Sean Chittenden