On Fri, Nov 14, 2008 at 7:40 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Neels J. Hofmeyr wrote:
>> Stefan Sperling wrote:
>>> On Fri, Nov 14, 2008 at 06:19:27PM -0800, neels_at_tigris.org wrote:
>>>> Author: neels
>>>> Date: Fri Nov 14 18:19:27 2008
>>>> New Revision: 34214
>>>>
>>>> Log:
>>>> Follow up on r34178, getting rid of compiler warnings.
Ah! Thanks!
>>>> * subversion/include/svn_string.h,
>>>> * subversion/libsvn_subr/svn_string.c
>>>> (svn_cstring_join): Make first parameter STRINGS const.
>>> Hmmm... can already released public API be changed like that?
Yes.
>...
>> We don't want a svn_cstring_join2(), do we?
>> Instead, we could cast explicitly to remove the warnings from gstein's r34178.
No need. This is a valid change. From a developer's standpoint, they
can now pass either non-const (as before) or const arrays into
svn_cstring_join(). We're *adding* capability, but not taking away (or
making source incompatible) anything they had before. At a binary
level, nothing has changed either. We're simply telling developers
"hey, we won't change what you pass to us."
Totally safe change.
*Removing* const is a no-no, however.
> Then bug Greg about it and let him fix it. :P
>
>> But to me the committed fix feels right. svn_cstring_join() doesn't ever
>> change that parameter. Does making the arg const even cause warnings in
>> calling code? It doesn't, does it?
>
> I seem to recall us changing the constness of existing function parameters
> before, but I don't remember whether we were making them const or removing it.
> I seem to think the latter, which feels better for API compatibility, but I
> don't recall for certain.
Adding const is fine, removing is Bad.
Cheers,
-g
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-15 07:49:24 CET