backward/forward binary compatibility checker

Thiago Macieira thiago at kde.org
Thu Jul 30 11:15:39 BST 2009


Em Quarta-feira 29 Julho 2009, às 19:01:00, Thiago Macieira escreveu:
> Em Quarta-feira 29 Julho 2009, às 17:11:09, Andrey Ponomarenko escreveu:
> > We have fixed your problem, but we have tested your library descriptors
> > only on Qt4.2.3 and Qt4.3.0 because we have not new Qt versions (4.5.3
> > and 4.6) yet and don't know where to find it. You may use beta 4 version
> > of tool, it is in the attachment. It must work on your library versions.
>
> Thank you, now it worked.

And here's the 4.4-to-4.5 report.

Parsing it:

=== section Added Interfaces
No comment, it seems correct

=== section Withdrawn Interfaces
variantToDomProperty: ignored, it's an internal function

operator*(QPointF const&, QMatrix const&):
qmatrix.h is exactly the same and I can't find the symbol in either shared 
object. Definitely a false positive. And it's inline in the header.

qtransform.h: both symbols are present in Qt 4.4 as weak symbols and absent in 
4.5. But it's not a problem since they are inline and present in the header.

=== section Problems in Data Types (High risk)
QByteArrayMatcher:
The report says "Size of this type has been changed from 1032 to 1024 bytes". 
That's completely wrong. Here's the diff:

 private:
     QByteArrayMatcherPrivate *d;
     QByteArray q_pattern;
-    uint q_skiptable[256];
+    union {
+        uint dummy[256];
+        struct {
+            uchar q_skiptable[256];
+            const uchar *p;
+            int l;
+        } p;
+    };

As you can see, the size holds the same, at sizeof(QByteArrayMatcherPrivate *) 
+ sizeof(QByteArray) + 256*sizeof(int) = 4 + 4 + 1024 = 1032. I have no clue 
how it came up with 1024, since there's no addition that would result in that.

QCalendarWidget:
Wrong report. This is just a reimplemented virtual, which means the size and 
layout of the virtual table has not changed.

QGraphicsProxyWidget:
This is the binary-incompatibility we introduced by accident. The report is 
correct.

QInputDialog:
The report says qt_metacall and metaObject changed positions. This makes no 
sense whatsoever. The Q_OBJECT macro did not change, the virtual table diff 
proves nothing changed and in any case, the order of these methods come from 
the QObject base.

QLocalServer:
This makes no sense. The headers are exactly alike.

QNetworkAccessManager:
Also wrong: the method was already present in 4.4.0.

QNetworkDiskCache:
New class in 4.5, so it's impossible to call it from 4.4.0.

QNetworkProxy:
It's complaining about this change:
 private:
-    QNetworkProxyPrivate *d_ptr;
+    QSharedDataPointer<QNetworkProxyPrivate> d;

The change is safe because QSharedDataPointer has the same size as a pointer, 
and it's a private member.

QNetworkProxyFactory:
New class.

QPaintEngine:
The member "extended" was added:
     uint active : 1;
     uint selfDestruct : 1;
+    uint extended : 1;

That is correct, but the size of the structure did not change. It's just using 
an unused bit in the bit field. There were only 2 bits used, with 30 bits left 
in the padding. Using the pahole tool to dump the debugging info, here's what 
it says now in 4.5:
        classQPaintEngineState *   state;                /*     4     4 */
        class QFlags<QPaintEngine::PaintEngineFeature> gccaps; /*     8     4 
*/
        uint                       active:1;             /*    12:31  4 */      
        uint                       selfDestruct:1;       /*    12:30  4 */      
        uint                       extended:1;           /*    12:29  4 */      

        /* XXX 29 bits hole, try to pack */

        classQPaintEnginePrivate * d_ptr;                /*    16     4 */

QPrintDialog:
same as QInputDialog: the report makes no sense

QStringMatcher:
same as QByteArrayMatcher

=== section Problems in Data Types (Medium risk)
QObjectData:
new field in bitfield, size of the type didn't change (the size of 
QObjectData::unused did, though)

QMetaObject:
The type of a public member changed:
-        const QMetaObject **extradata;
+        const void *extradata;
So the report is correct to point out the problem. (The change was intentional 
though and the member is not documented)

=== section Problems in Data Types (Low risk)
This section is listing all the reimplemented virtuals. As I noted yesterday, 
it is correct to point it out. It's not correct to list new classes here 
(QDBusPendingCallWatcher and QGtkStyle for example).

The QMetaObject report appears in both sections, which isn't correct. Please 
decide for one or the other.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Software
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abi_compat_report.html.bz2
Type: application/x-bzip
Size: 24577 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090730/f1f41194/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090730/f1f41194/attachment.sig>


More information about the kde-core-devel mailing list