tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Surprising implementation of SSL.hasOp
Date Wed, 03 Oct 2012 18:49:07 GMT

On 10/3/12 1:30 PM, Rainer Jung wrote:
> On 03.10.2012 18:02, Christopher Schultz wrote:
>> Looking at the OpenSSL API (wow, I really miss javadoc), it doesn't
>> appear that there's any function that can sniff the capabilities of the
>> engine and check to see whether a particular option is supported.
>> Instead, the technique of using #ifdefs to conditionally include code
>> that will return TRUE seems to be the only alternative.
> Apache HTTP server uses this style as well.

That's a good sanity check: at least we're all doing it the "long" way ;)

> I think though ugly it's the right approach. You could try to define a
> macro, that takes over the
>    if (op & SSL_OP_FOO) {
>      support |= (op & SSL_OP_FOO);
>      op ^= SSL_OP_FOO; // Clear FOO
>    }
> part and makes it a bit shorter. The ifdef unfortunately has to stay
> outside of the macro, since you can't use if or ifdef inside a cpp macro.
> Totally untested, but maybe something along the lines of

I like the idea of using a macro to compact the code a bit, but in spite
of tcnative's use of macros that don't contain "arguments" for all data
that will be operated on, I prefer to be explicit about mentioning all
data that will be used, like this:

#define TCN_SSL_TEST_OP_SUPPORT(op, option, support) \
  if (op & option) { \
    support |= (op & option); \



Unfortunately, it does modify those "arguments" in call-by-reference
style yet does not pass them by reference, but the use of ALL_UPPER_CASE
should suggest that it's a preprocessor macro and not a method call and
that - possibly - the arguments might be modified.


View raw message