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

[Tor Arne Vestbø]

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. 

Since it all flattens down to e.g. qint64 I don’t suppose there’s anything we can do to make the %z case less confusing by adding convenience for size_t? If not a doc update would be helpful at least.

Cheers,
Tor Arne 

> On 2 Sep 2020, at 09:15, Mathias Hasselmann <mathias at taschenorakel.de> 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.
> 
> Am 01.09.2020 um 19:29 schrieb Thiago Macieira:
>> On Tuesday, 1 September 2020 08:44:07 PDT Giuseppe D'Angelo via Development
>> wrote:
>>> Il 01/09/20 16:23, Thiago Macieira ha scritto:
>>>> So even if you use %td or %zd, GCC will complain in one of three different
>>>> platform configurations (namely, 64-bit Unix).
>>> Pedantically, do we need the PRIxQSS (?) macro and friends to use
>>> qsizetype into qWarning etc.?
>> That's ugly. Just cast the type itself to ptrdiff_t or int.
>> 
>> That is, write:
>> 
>>     qWarning("List too big: %zd", ptrdiff_t(list.size());
>> 
>> Qt's internal sprintf-like functions actually use qsizetype, not ptrdiff_t, so
>> pedantically-strictly speaking the compiler is wrong and your code was right
>> without the cast. In real-life, it just works.
>> 
>> Note: this only applies to the functions that actually use Qt's own sprintf-
>> like functions. You can't use with printf family itself because we still
>> support MinGW and that one uses a C99-incompatible standard library by default
>> (no "z" and no "t" modifier and no 64-bit support on 32-bit systems).
>> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development