[Development] Is qsizetype *documented* to be ptrdiff_t?

[Thiago Macieira]

On Wednesday, 2 September 2020 00:15:37 PDT Mathias Hasselmann wrote:
> I'd rather say that cast is entirely ugly. Seems like a perfect example
> or code smell: Something is fundamentally wrong they way qsizetype is
> defined.

Lars has asked for qsizetype to be defined as the same type (not just the same 
size) as ptrdiff_t. Effectively, this means defining qint64 as the same type 
as int64_t. Sounds easy, right?

Please remember that qlonglong is the same type in Qt as qint64. That means on 
these platforms, qlonglong would then be "long", not "long long". This is also 
reflected in our API: QString::toLongLong and QVariant::toLongLong -- will 
they return long? Those types are probably also used in a lot of overload sets 
and could break existing code. Moreover, it could make maintaining Qt5 and Qt6 
codebases working together cumbersome.

I'm not completely opposed to changing this. But I am asking whether it's 
worth the trouble.

Tor Arne wrote:
> As a user of this API I was also stumped by not being able to just call
> printf with %z and a qsizetype, under the assumption that qsizetype’s
> purpose in life was to mask _away_ the differences of what a size was
> represented as.

That is indeed why C99 added the "z" and "t" modifiers. But unfortunately we 
still support one pre-C99 runtime, so you can't use them in cross-platform 
code.

For restricted scenarios (MSVC-only or Unix-only code), you can use those 
modifiers. And in MSVC-only scenarios, there will be no type mismatch either, 
in both 32- and 64-bit.

On 64-bit Unix, the result will be correct too, since the types are the right 
size. The only thing is you may get a compiler warning that the types 
mismatched. We could disable -Wformat.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering