Dynamic_cast in XML-Security-C

[Jesse Pelton <js...@PKC.com>]

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.

Re: Dynamic_cast in XML-Security-C

[Berin Lautenbach <be...@wingsofhermes.org>]

Jesse,

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.

Cheers,
	Berin

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.
> 
>