Yoann Vandoorselaere <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-05-17 at 14:21 +0200, Jim Meyering wrote:
>> Yoann Vandoorselaere <[EMAIL PROTECTED]> 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.
_______________________________________________
bug-gnulib mailing list
bug-gnulib@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnulib
