Re: [PATCH hail] const-correctness tweaks
Jeff Garzik <[email protected]> Wed, 20 Oct 2010 04:36:45 -0400
| Newsgroups | org.kernel.vger.hail-devel |
|---|---|
| Message-ID | <[email protected]> |
On 10/20/2010 04:00 AM, Jim Meyering wrote: > Jeff Garzik wrote: > >> On 10/06/2010 08:07 AM, Jim Meyering wrote: >>> >>> Make write_cb callback's buffer parameter const, like all write-lik= e >>> functions. >>> Give a few "char *" parameters the "const" attribute. >>> >>> Signed-off-by: Jim Meyering<[email protected]> >>> --- >>> >>> It looks like most of hail's interfaces are const-correct, >>> but one stood out because it provokes a warning when I tried to >>> pass a const-correct write_cb function to hstor_get from iwhd: >>> >>> proxy.c:382: warning: passing argument 4 of 'hstor_get' from = \ >>> incompatible pointer type >>> /usr/include/hstor.h:173: note: expected \ >>> 'size_t (*)(void *, size_t, size_t, void *)' but argument = is of type \ >>> 'size_t (*)(const void *, size_t, size_t, void *)' >>> >>> In case you feel comfortable fixing this, here's a patch: >> >> >> Sorry for not getting back to this; I had hoped to solve some >> additional problems that cropped up, but didn't have time. So, to >> forestall further delay, >> >> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -I../include -pthrea= d >> -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include >> -I/usr/include/libxml2 -O2 -Wall -Wshadow -g -MT hutil.lo -MD -MP -M= =46 >> .deps/hutil.Tpo -c hutil.c -o hutil.o >> hutil.c: In function =E2=80=98hreq_hdr_push=E2=80=99: >> hutil.c:145: warning: assignment discards qualifiers from pointer >> target type >> hutil.c:146: warning: assignment discards qualifiers from pointer >> target type >> >> warnings appear after this patch. When solving these warnings with >> const' markers, it quickly becomes a bit of a rat's nest. >> >> At a minimum, the write_cb callback signature must match libcurl's, >> which does not use 'const'. I can see this makes sense from libcurl >> implementation's perspective, even if it does not really match the >> constness one expects from a foo-get function. > > Hi Jeff. > > Sorry I didn't notice that the first time. > I built with ./autogen.sh&& ./configure&& make. > It looks like you recommend -Wall -Wshadow. > > The two warnings above are the only ones I see with the patch, > and they're easy to fix. When storing const pointer params into > a struct like that, I've found that it's best to cast away the "const= ", > which really does reflect the semantics: by using "const" on the > parameter, I view it as promising not to deref through the pointer > *in that function*. Since it's usually not reasonable to make > the struct member "const" (as you saw, it propagates too far > and often ends up being contradictory), the lesser evil of the cast > is preferable here. > > If you're still game, the following incremental patch seems to be > enough for me: Let me know and I'll resubmit the full one. Well, my primary concern now originates from curl_easy_setopt(3)=20 documentation: CURLOPT_WRITEFUNCTION Function pointer that should match the following prototype: size_t function( void *ptr, size_t size, size_t nmemb, void *stream); hstor's callback is passed directly to libcurl, so we seem to be bound=20 by outside constraints, no? Jeff