[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: CVS update: subversion/subversion/libsvn_fs clones-table.c dag.c txn-table.c

From: Branko Čibej <brane_at_xbc.nu>
Date: 2001-01-12 01:53:22 CET

kfogel@tigris.org wrote:

> User: kfogel
> Date: 01/01/11 13:21:08
> Modified: subversion/libsvn_fs clones-table.c dag.c txn-table.c
> Log:
> Add casts away from const, to get rid of compiler warnings.
> We have const strings being passed into functions that take non-const
> strings, but -- if I understand correctly -- we don't want those
> functions promising the incoming data will never be changed. After
> all, the functions are just storing the data directly (non-copying)
> into skels, and it would be too restrictive if all skels had to
> promise never to modify the data in their strings.
> If this is wrong, and skels can make such a promise, then we should do
> this change the other way, adding const to the string parameters of
> svn_fs__str_atom(), svn_fs__parse_skel(), and svn_fs__str_to_dbt().

Well, skels don't change their contents directly right now, and there's
no API for that. I'm +1e5 for constifying those parameters, and also the
data pointers within the skels (not the child and sibling pointers, of

Anyway, if we're going to point from skels into constant strings, we'd
better make sure those pointers are to const, or we'll regret it
someday. I think the casts in this case are dangerous. If we can't agree
to constify the pointers, then I'd rather see we leave the warnings
rather than add the casts. At the very least, the poor guy that's gonna
have to fix the segfaults will know where to look.

Brane �ibej
    home:   <brane_at_xbc.nu>             http://www.xbc.nu/brane/
    work:   <branko.cibej_at_hermes.si>   http://www.hermes-softlab.com/
     ACM:   <brane_at_acm.org>            http://www.acm.org/
Received on Sat Oct 21 14:36:19 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.