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

[Nowacki Jedrzej]

Hi,

  Sorry if something mess-up in formating / history ordering, I'm answering from a different email account. This email is supposed to be an answer to Stephen's question:

> > > PointerToGObject is a boolean how would you say which value is supperior?
> > >
> > > if (flags & PointerToGObject)
> > >   storeDataInPointerContainer(object)
> > > else
> > >   storeDataInNormalContainer(object)
> > >
> > > It means that the flag can change during execution of an application. I
> > > would say no for such solution .
> >
> > I see... that would indeed be a problem.
> > But if we are aware of it we can still make good use of PointerToGObject
>
> I have to say, I don't see the problem.
>
> Where does if (flags & PointerToGObject) appear? In Qt 5.1, right otherwise
> PointerToGObject would not be defined. The plugin compiled against Qt 5.0
> can't contain code like that. Whether the metatype is a pointer to gobject is
> simply irrelevant to the plugin, until the author of it decides it is useful
> and recompiles with a dependency on Qt 5.1.

But Qt itself may use the flag, code in Qt would be vulnerable. You need to have a 3 different instances to trigger the bug. One instance that register "false" and that register "true", and the last one that do a jump based on the value.

> https://codereview.qt-project.org/#change,34042
>
> would make metatype registration also record whether the metatype is a
> QList<T> or a QVector<T> (in 5.1). That is no different to any other Qt
> release which adds overloads of existing methods which carry newer parameters
> and therefore newer meanings.
>
> Is it acceptable to do that for 5.1?

Short answer: yes, but not as an automatic flag.
There is a difference between adding a method overload and maintaining a data BC. We are talking here about a data / algorithm not about a method signature. It is a bit more complex, but you are right it is not different from what we had in all other releases. It is like having different qmetaobject versions. As we discussed before changing a flag from a value to another may not be BC. Therefore, as Thiago pointed out, Qt should not do it.

Cheers,

  Jędrek