[Development] qsizetype

[Volker Hilsheimer]

> On 5 Sep 2022, at 14:46, Alex Blasche <alexander.blasche at qt.io> wrote:
>> -----Original Message-----
>> From: Development <development-bounces at qt-project.org> On Behalf Of
>> Marc Mutz

[…]

>> I just want to raise awareness of the issue, which, really, is just an incomplete
>> port of the Qt containers to qsizetype in 6.0.
>> 
>> Over the last months, however, I've realized that "just the Qt containers"
>> introduces a nasty API inconsistency in Qt: qsizetype in Qt containers and int
>> elsewhere. This inconsistency is un-Qt-ish and creates problems for our users.

[…]

> I like the container.size() vs setFoo(int) use case as example to decide how far we want to spin this inconsistency further ahead throughout all of Qt . I totally agree with Marc's argument that it is not Qtish and causes pain to every user.  I guess we have three options:
> 
> 1.) What I am wondering though is if we were to sink all the time into Qt to convert all API's, would Qt be blamed for all the continued porting effect throughout the years on this issue? After all we cannot do this for one single release in one go. It would probably find its way into each release over a couple of years. Does this help Qt in its goal to be easy to use? The compatibility layer does add its own layer of complexity.
> 
> 2.) An alternative might be to make this change in one go for Qt 7. We would keep Qt 6.x on the status quo but start adding compatible replacement APi with an absolute change at 7.0 (ifdefs or typedefs come to mind). Users would only be burdened one time (though it being one BIG time effort). Such a change would be much simpler in Qt headers.
> 
> 3.) On the other hand, we have had a lot of Qt 6 ports already and so far, it did not come up as a major issue in those ports. Could we simply accept this inconsistency? After all, would QSplitter ever need setWidget(qsizetype, QWidget*)? Under this scenario we might agree to convert all internal Qt uses of containers but leave the public API untouched. Of course some dedicated use case, where extra large files/chunks of data should be read, could get the treatment much earlier.
> 
> Personally, I cannot agree whether I like Option 2 or 3 more.


We have virtual functions that take int and could potentially be fed by the return value of container.size() (or generally need to be able to handle values >2G), so should take a qsizetype (say, QAbstractItemModel::insertRows, overridden by QSqlTableModel). I don’t see how we can change those until Qt 7.

So we will have to live with some inconsistency. Given that, and also trying to be pragmatic wrt the effort required (potentially also in client code) in relation to the likelihood of real issues, I’d say that we should focus the proactive effort on QtCore, QtNetwork, QtSQL, QtWebSockets/Channel, and perhaps a few more modules that are likely to have to process >2G quantities of data. In those modules, perhaps there’s a security component to consider, where wrong handling of qsizetype might enable an integer overflow attack.

For the other modules, esp those related to user interface development, the chance that an int-API is called with a value above 2G seems very low, even if they are operating internally on Qt containers. I might be missing some real world examples though where e.g. QGraphicsScene or a QTextDocument needs to operate on >2G items.


>> the hope is that  once we've progressed somewhat, we can enlist compiler support
>> by  globally enabling warnings such as -Wshorten-64-to-32


Would be great if we can do that for the modules above, at least, to avoid further deterioration. And once we have established an acceptable baseline, it would help a lot with doing the rest (or at least more) of the work for Qt 7.

Volker