All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jim Meyering <jim@meyering.net>
To: Jeff Garzik <jeff@garzik.org>
Cc: Project Hail <hail-devel@vger.kernel.org>
Subject: Re: [PATCH hail] const-correctness tweaks
Date: Wed, 20 Oct 2010 10:00:23 +0200	[thread overview]
Message-ID: <878w1t5m5k.fsf@meyering.net> (raw)
In-Reply-To: <4CBE1AA2.5020004@garzik.org> (Jeff Garzik's message of "Tue, 19 Oct 2010 18:24:34 -0400")

Jeff Garzik wrote:

> On 10/06/2010 08:07 AM, Jim Meyering wrote:
>>
>> Make write_cb callback's buffer parameter const, like all write-like
>> functions.
>> Give a few "char *" parameters the "const" attribute.
>>
>> Signed-off-by: Jim Meyering<meyering@redhat.com>
>> ---
>>
>> 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 -pthread
> -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 -MF
> .deps/hutil.Tpo -c hutil.c -o hutil.o
> hutil.c: In function ‘hreq_hdr_push’:
> 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.

diff --git a/lib/hutil.c b/lib/hutil.c
index 13a8d5e..b74460b 100644
--- a/lib/hutil.c
+++ b/lib/hutil.c
@@ -142,8 +142,8 @@ int hreq_hdr_push(struct http_req *req, const char *key, const char *val)
 		val++;

 	hdr = &req->hdr[req->n_hdr++];
-	hdr->key = key;
-	hdr->val = val;
+	hdr->key = (char *) key;
+	hdr->val = (char *) val;

 	return 0;
 }

  reply	other threads:[~2010-10-20  8:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-06 12:07 [PATCH hail] const-correctness tweaks Jim Meyering
2010-10-07  6:00 ` Jeff Garzik
2010-10-07  6:38   ` Jim Meyering
2010-10-19 22:24 ` Jeff Garzik
2010-10-20  8:00   ` Jim Meyering [this message]
2010-10-20  8:36     ` Jeff Garzik
2010-10-20  8:53       ` Jim Meyering
2010-10-23  1:49         ` Jeff Garzik
2010-10-23  3:01           ` Jeff Garzik
2010-10-23  6:47           ` Jim Meyering

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=878w1t5m5k.fsf@meyering.net \
    --to=jim@meyering.net \
    --cc=hail-devel@vger.kernel.org \
    --cc=jeff@garzik.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.