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

[Olivier Goffart]

Reviving old thread because it was discussed on IRC:

On Friday 08 June 2012 10:31:31 Jedrzej Nowacki wrote:
> 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.

What's wrong by saying that when there are "binary incompatible" registration, 
we keep the maximum of flag set?  So the second registration which say the 
type is a PointerToGObject override the previous one.

The code that expect PointerToGObject to be set for a given type will continue 
to work because that library should register that type.

>   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.

-- 
Olivier

Woboq - Qt services and support - http://woboq.com