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

Re: svn commit: r35103 - in trunk/subversion: include libsvn_client libsvn_delta libsvn_fs libsvn_fs_base libsvn_fs_base/bdb libsvn_fs_base/util libsvn_fs_fs libsvn_subr libsvn_wc tests/libsvn_delta

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 09 Jan 2009 15:21:46 +0000

On Fri, 2009-01-09 at 06:24 -0800, Greg Stein wrote:
> On Fri, Jan 9, 2009 at 05:52, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> >...
> > So, the svn_checksum_t internals are going to be public. Should we make
> > the "digest" field publically writable? If we don't, there's no public
> > official way to initialize the allocated memory, but there could be
> > public APIs for doing so in the future. That's probably a reasonable
> > position to be in.
>
> It used to be non-const, but hwright constified it a while back. The
> idea was that our APIs would write into it, but third-party users
> should not. Thus, const.

I agree with that strategy.

> The "public" way to create one is via finalizing a context, parsing
> hex data, computing a checksum for a byte block, etc. Just no real way
> to shove bytes into that structure explicitly.
>
> There is an argument that third parties will need __from_digest just
> like we do, as they upgrade from the old digest-style APIs. I'd
> consider waiting to hear from them before officially
> supporting/exposing that API.

Yes.

The current situation is nasty in that a whole bunch of our internal
uses are casting away that "const" at their point of use. They should
have a single point of entry to write into it.

I have reverted r35103 in r35115.

- Julian

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1013927
Received on 2009-01-09 16:22:11 CET

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.