[Development] Possible binary compatibility problem in a future Qt version
Jedrzej Nowacki
jedrzej.nowacki at nokia.com
Fri Jun 8 10:31:31 CEST 2012
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>
More information about the Development
mailing list