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

Re: svn commit: r1308372 - /subversion/trunk/subversion/libsvn_subr/crypto.c

From: Greg Stein <gstein_at_gmail.com>
Date: Fri, 6 Apr 2012 10:59:26 -0400

On Apr 6, 2012 10:45 AM, "C. Michael Pilato" <cmpilato_at_collab.net> wrote:
>
> On 04/02/2012 07:52 PM, Greg Stein wrote:
>...
> > To be honest, one of my intended updates is to move *all* of the
> > #ifdef stuff into crypto.c's functions. We've had problems where
> > functions only appeared within certain build targets (notably under
> > Windows). I think that the functions should always be available, but
> > just return errors if the underlying library support is not present.
> > Thus, callers never need to understand the vagaries of when something
> > is/not available. Throw in an svn_crypto__is_available(), and it makes
> > things even a bit easier.
> >
> > Any issues with that approach, that you can see?
>
> It's not just the functions that have to deal with this. It's also the
data
> types. Of course, that's all the more reason why your introduction of
> svn_crypto__ctx_t is a Good Thing -- we can #ifdef the
> conditionally-available APR members (leaving an empty-but-defined
structure,
> if need be).

Right. The extra indirection of the typedef was to support the conditional
implementation, in addition to potentially holding an RNG state.

Note that structs need at least one element; "int empty;" works just fine.

Cheers,
-g
Received on 2012-04-06 16:59:59 CEST

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.