[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-gnulib] Re: [PATCH]: fix warning in the hash module

From: Jim Meyering
Subject: [bug-gnulib] Re: [PATCH]: fix warning in the hash module
Date: Tue, 17 May 2005 17:40:59 +0200

Yoann Vandoorselaere <address@hidden> wrote:
> On Tue, 2005-05-17 at 14:21 +0200, Jim Meyering wrote:
>> Yoann Vandoorselaere <address@hidden> wrote:
> This requirement is technically wrong since you allow modification of
> the input argument through the user provided callback.

I am well acquainted with the problem, but please bear in mind that it
is a theoretical one.  There is an overriding practical reason for the
current hash_insert and hash_delete signatures:

What if we were to convert to the const-less signatures you prefer,
and then an application wants to call hash_insert with a variable of
type `char const *'? -- of course, the key-freer function is NULL
in that case.  Then, it's not just the relatively obscure -Wcast-qual
that evokes a warning, but instead it's gcc's more commonly used
-W option:

  warning: passing argument 2 of 'hash_insert' discards qualifiers
    from pointer target type

And since there are applications that do precisely that, I prefer
to incur a little bit of technically unclean code under the covers
than to require every such caller to cast-away their perfectly
reasonable `const' attributes.

> Additionally, the last warning is not unavoidable, you can adapt the
> union patch to fix up this problem

Yes, I see what you mean.  But I don't think avoiding four -Wcast-qual
warnings is worth the ugliness induced by adding 40+ uses of a union.

> (but I still maintain that you should
> not use const at all).
> - strdup return a copy of the string. It's expected it won't return a
> const.

Not strdup, of course :)
My point was that sometimes casting away `const' is unavoidable.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]