Minor libmemcache issue inside php extension
Sean Chittenden
sean at chittenden.org
Thu Jan 20 00:56:35 PST 2005
> 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
More information about the memcached
mailing list