santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Lautenbach <>
Subject Re: Dynamic_cast in XML-Security-C
Date Fri, 25 Feb 2005 09:23:33 GMT

The code you show below (and anything else like it) is a bug.

In some cases it's used on purpose (mainly around the crypto providers) 
to make sure someone isn't using multiple providers on us for times when 
a provider is relying on a class within the same provider.  However I've 
thought for a while that we should replicate the ::getProviderName() 
method from XSECCryptoProvider into all the crypto classes as a better 
(and more portable) way of validating things.

So theoretically it could be pulled out.  But for some reason I've got 
something in the back of my head telling me there was something that 
relied on RTTI - but I can go through and look.


Jesse Pelton wrote:

> None of my company's code currently relies on real-time type information
> (RTTI), so we disable it to avoid the overhead.  This is possible in
> part because Xerces-C explicitly does not use RTTI (to ensure
> portability).  XML-Security-C, on the other hand, uses dynamic_cast<>
> and thus relies on RTTI.  I don't want to change our build process if I
> can avoid it (mostly because I don't want to step on the toes of other
> projects that don't need or want RTTI).
> Is XML-Security-C's choice to use RTTI a conscious departure from
> Xerces-C's policy, or is there some possibility that this would be
> changed?
> I haven't looked at the code in any great detail, so I'm not sure what
> level of effort would be required to remove RTTI dependencies, but there
> appear to be less than two dozen dynamic casts.  Some of them appear to
> be using dynamic_cast unnecessarily, perhaps dangerously.  Consider, for
> example, the following, from WinCAPICryptoSymmetricKey.cpp:
> 		WinCAPICryptoProvider * cp = 
> dynamic_cast<WinCAPICryptoProvider*>(XSECPlatformUtils::g_cryptoProvider
> );
> 		p = cp->getApacheKeyStore();
> This uses a dynamic cast to obtain a WinCAPICryptoProvider.  However, it
> assumes that the cast succeeds and does not check for NULL.  If the cast
> is guaranteed to succeed, it might as well do a cheaper static cast.  If
> not, it should check for NULL.  Without knowing the intent, I can't
> assess whether a static cast would serve where this practice is
> followed.

View raw message