On 04.10.2012 23:14, Christopher Schultz wrote:
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);
}
That looks good.
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.
Wouldn't unknown options result in the same as non-supported ones? That
should be OK.
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?
Go ahead :)
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
