tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Surprising implementation of SSL.hasOp
Date Thu, 04 Oct 2012 21:14:28 GMT
Rainer,

On 10/3/12 2:49 PM, Christopher Schultz wrote:
> 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); \
>   }
> 
> ...
> 
> #ifdef SSL_OP_MICROSOFT_SESS_ID_BUG
>     TCN_SSL_TEST_OP_SUPPORT(op, SSL_OP_MICROSOFT_SESS_ID_BUG, support)
> #endif

After implementing, testing, and committing this to tcnative-trunk, I
actually think there might be a better way to do it.

Instead of painstakingly examining each bit of the requested op, we
could simply create a bitmask of all supported options and then check
the requested set of bits against that.

For instance, we could use a technique similar to the above to set a
static bitset:

static int supported_ssl_opts = 0;

initialize() {
   ...
#ifdef SSL_OP_MICROSOFT_SESS_ID_BUG
   supported_ssl_opts |= SSL_MICROSOFT_SESS_ID_BUG;
#endif
   ...
}

Then, hasOp becomes:

hasOp(op) {
  return op == (supported_ssl_options & op);
}

If we still want to (and I think we probably should) test for unknown
options in hasOp (to indicate to the user that OpenSSL actually has no
idea what you are talking about -- usually a version-to-low situation),
I'm not sure how to do that.

Come to think of it, I'm not sure that my original solution does that,
either: the code will throw an exception if the option isn't supported
rather than returning null. I think I will revert my change and put a
better one in.

What do you think?

-chris


Mime
View raw message