svn commit: samba r6127 - in branches/SAMBA_3_0/source: include lib libads libsmb nsswitch rpc_server tdb utils

[derrell at samba.org]

Andrew Bartlett <abartlet at samba.org> writes:

>> Eliminated all compiler warnings pertaining to mismatched "qualifiers".  The
>> whole of samba comiles warning-free with the default compiler flags.
>
> However, when you compile --enable-developer, these all come back again,
> just different :-)

I had just begun a compile with --enable-developer so I was about to discover
this. :-) I expected it, though, when I saw the list of compiler flags that
are enabled by that option.

> Sorry to jump on the new guy, but const issues have been gone over many
> times, and they are not easy unless you start fooling the compiler - see
> the discard_const_p() macro from Samba4 to do it reliably.

This is actually a gripe that I wanted to discuss.  Although I put a band-aid
on it, you're right, my casts don't solve the problem.  If "const" isn't going
to be used properly, or more accurately, consistently, it really shouldn't be
used at all.  Passing a "char *" to a function that expects a "const char *"
which in turn passes it to a function that expects a "char *" just seems
screwy.  Is it const or isn't it?  Fooling the compiler should not be
necessary.

We should be able to produce a functional interface that is consistent as to
what types of variables are passed and expected.

Short of that, we should at least be able to use a reasonably strict set of
compiler flags for warning, and compile warning-free.  Maybe that set is
simply "-Wall" or maybe some of the others enabled by --enable-developer are
appropriate as well.

> The current situation was pretty much the minimum warnings we could get
> without invoking discard_const_p(), and already used a similar trick in
> tdb. 

Given the current munging of the meaning of "const", discarding "const" seems
appropriate.  I suspect that gets into religious issues, so I won't propose
discarding them, but I think the topic is worthy of some discussion.  (If
y'all have discussed this to bits already and don't want to rehash, then maybe
someone can give me the executive summary and I'll crawl back into my corner.)

This is a bit of a hot-button for me, because I have seen, way too often,
programmers have bugs whose cause immediately became obvious after compiling
with -Wall, or in some even worse cases, -Wall was on, the warnings were
blaring out at them from their screen, and they continually ignored them.
Sigh.

Derrell