[Development] Possible binary compatibility problem in a future Qt version

[Jedrzej Nowacki]

Hi,

  Qt meta-type system is assuming that type information is constant and 
consistent. It make sense because in C++ a type trait can not be changed 
during execution of an application. We agreed that unregistering of a type is 
a bad idea and that updating a type data can cause malfunction in Qt itself 
(not mentioning external library or applications). In Qt5 we introduced a lot 
of template based auto-detection for different features. Most of the data 
gathered by QTypeInfo, QMetaTypeId helpers classes are stored in QMetaType 
internal data, so it can also be used during a runtime introspection. So far 
so good, we have inlined data which is constant and consistent with data that 
we stored in QMetaType. So what will happen if we compile an application with 
an older Qt and link against a newer one, assuming that we introduced or 
changed a new type's information? Nothing special :-), during type 
registration old data will be registered, so again both source of type data 
would be consistent. 

  To break the current design a 3rd client of the type data has to be 
introduced. It can be Qt itself or a library linked with Qt. So lets create 
theoretical situation that we created a new type flag isPointerToGObject in 
Qt5.1. Then someone write an application that is compiled against Qt5.1 and 
use that flag with a type T that is coming from a 3rd party library compiled 
with Qt5.0. Now, if both, the application and the library register the same 
type T in Qt we will detect binary incompatible registration. It will be like 
that because the application will have different feature detection inlined code 
then the library. 

  What can go wrong then? From nothing to crash, it depends on the flag. For 
example if the flag is just an optimization hint, like 
"typeHasThreadSafeConstructor" then it is quite safe because we could 
"downgrade" the registered data to a safe value, it would work, maybe a bit 
slower :-). On other hand isPointerToGObject doesn't have such safe value, 
because it points to a feature that is rather a type description. 

  Currently we save "NeedsConstruction", "NeedsDestruction", "MovableType", 
"PointerToQObject", "IsEnumeration" flags. It would be great to save more in 
future, as it is really useful. Please mark that if there is a bug in code 
that detects the last two features, we will not be able to fix it until Qt6.

  What now? We can:
  1. ignore the problem as an edge case, to be honest the scenario is quite 
complex.
  2. create a policy to add only "downgradable" flags, so in case of problems 
we will fall-back to a safe value.
  3. start versioning types data, always access a data information with a 
special implicit marker.
  4. drop concept completely.

  I believe that only option 2 and 3 are acceptable, but I would love to know 
what you think.

Cheers,

  Jędrek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120608/df2907ea/attachment.html>