https://bugs.kde.org/show_bug.cgi?id=428078
Espen Sandøy Hustad changed:
What|Removed |Added
Latest Commit||https://invent.kde.org/pim/
https://bugs.kde.org/show_bug.cgi?id=428078
Bug Janitor Service changed:
What|Removed |Added
Status|CONFIRMED |ASSIGNED
--- Comment #5 from Bug Janitor
https://bugs.kde.org/show_bug.cgi?id=428078
Espen Sandøy Hustad changed:
What|Removed |Added
CC||es...@ehustad.com
Ever confirmed|0
https://bugs.kde.org/show_bug.cgi?id=428078
--- Comment #3 from Marcel Bosling ---
Hi again,
I've used typeid().name() on buf to see what type get's deduced from auto buf
and for me it turns out to be the following mangeld type name:
14QStringBuilderI10QByteArrayA3_cE
It seems that a QString
https://bugs.kde.org/show_bug.cgi?id=428078
--- Comment #2 from Marcel Bosling ---
Hi Jan,
indeed the statement is a leftover of my investigations.
These are the results when using auto and QByteArray for buf:
const QString &sername: "someexampleusern...@whereever.org"
auto buf: "a\x00u\x00
https://bugs.kde.org/show_bug.cgi?id=428078
--- Comment #1 from Jan Kundrát ---
I do not understand how the proposed patch is supposed to fix the reported
issue. Inclusion of looks like a leftover from some debugging. Instead
of specifying type of that local variable as `auto`, it's now `QByteAr
