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

Re: svn commit: r1041230 - /subversion/trunk/subversion/include/svn_checksum.h

From: Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de>
Date: Sun, 05 Dec 2010 23:12:33 +0100

On 02.12.2010 07:57, Blair Zajac wrote:
> On 12/1/10 4:38 PM, stefan2_at_apache.org wrote:
>> Author: stefan2
>> Date: Thu Dec 2 00:38:17 2010
>> New Revision: 1041230
>> URL: http://svn.apache.org/viewvc?rev=1041230&view=rev
>> Log:
>> Fix the svn_checksum_to_cstring() docstring to actually say what
>> was intended. Also, make clear that the behavior is new for 1.7 and
>> trying to use it in 1.6 will cause segfaults.
>> * subversion/include/svn_checksum.h
>> (svn_checksum_to_cstring): fix docstring
> What happens if somebody makes a svn tool that is compiled and built
> against the new 1.7 behavior and then it is backported to 1.6, it may
> core dump.
> Should we add a svn_checksum_to_cstring2() instead with the new
> behavior or backport this change to 1.6? But even then we'll have 1.6
> versions with different behavior. It seems making a new
> svn_checksum_to_cstring2() is better.
I've felt kind of uneasy about that issue as well.
However, it would have been difficult to implement
a deprecated svn_checksum_to_cstring() in terms
of svn_checksum_to_cstring2(). For instance:

const char *
svn_checksum_to_cstring(const svn_checksum_t *checksum,
                         apr_pool_t *pool)
   if (checksum == NULL)

   return svn_checksum_to_cstring2(checksum, pool);

does not have the exact same behavior as the old
implementation. Even if we added error output etc.,
that very message may be ignored by / masked in
the calling process. Forcing a segfault via

if (checksum == NULL)
   return (const char*)checksum->digest;

might not be liked by some compilers / optimizers
because they know checksum to be NULL in the
return statement.

-- Stefan^2.
Received on 2010-12-05 23:13:16 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.