[omniORB] [RFC] reverting ABI change in sslContext introduced in 4.1.2

[Thomas Girard]

Hello,

while preparing Debian packages for omniORB4 4.1.2, we noticed the
following change in include/omniORB4/sslContext.h:

class sslContext {
private:
// ...
SSL_CTX* pd_ctx;
omni_tracedmutex* pd_locks;
CORBA::Boolean pd_ssl_owner; <-- this attribute was added
};

According to [1], to make a binary compatible change in C++, you can't:
"add new data members to a class or change order of data members in a
class (doesn't apply to static ones)"

so this change breaks the ABI. Since the SONAME of libomnisslTP4 was not
changed it's safer to rebuild all binaries depending on the sslContext
class (e.g. the Python module _omnisslTPmodule.so.3). Of course I'd
like to avoid that, and would prefer not to bump the SONAME, since that
would introduce a change between upstream and Debian versions.

The attached patch is another approach that does not break the ABI.
Could you please review it? It's supposed to be equivalent to the other
one.

Thanks,
Regards,

Thomas

[1] http://techbase.kde.org/index.php?title=Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: omniorb4_revert_sslcontext_abi_change.diff
Type: text/x-diff
Size: 2166 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080403/5a429c9e/omniorb4_revert_sslcontext_abi_change.bin

[Duncan Grisby]

Post by Thomas Girard
while preparing Debian packages for omniORB4 4.1.2, we noticed the
class sslContext {
// ...
SSL_CTX* pd_ctx;
omni_tracedmutex* pd_locks;
CORBA::Boolean pd_ssl_owner; <-- this attribute was added
};
"add new data members to a class or change order of data members in a
class (doesn't apply to static ones)"

You are right. The change should not have been made.

However, now that it has been changed, I think it is just as bad to
revert it, since that's another incompatible ABI change. We just need to
be more careful in future.

Duncan.