QT_TO_UTF8 returns a const char * that, in general, shouldn't be stored.
This is because QT_TO_UTF8(str) expands to str.toUtf8().constData():
toUtf8() returns a QByteArray, and constData() the pointer to its data
which is only valid until the QByteArray goes out of scope, which is
immediately after the call.
The original code that is changed here only works because in all of the
situations, the object that is stored to is actually a std::string that
gets constructed implicitly, so the constData() pointer is valid long
enough for the std::string constructor to copy the data.
The issue is that any "... = QT_TO_UTF8" code *looks* unsafe, and may
lead new or unfamiliar contributors to assume that they can also use it,
only to do "const char *... = QT_TO_UTF8(...)" which is dangerous.
Additionally, it introduces an unnecessary round of implicit conversions
and copies when QString.toStdString() already exists and copies into the
string buffer directly.
At a glance, the GenId function looks like it can only return a
16-character hexadecimal string with all characters being [0-9A-F].
However, it seems that it can rarely return a 16-character string that
has one or two space characters at the beginning due to the value of id,
from which the final string is derived, being too low (lower than
1152921504606846976 or 0x1000000000000000) and the printf format
specifier having a width of 16. This results in a string of less than 16
characters that is padded with blank spaces. The end result is a cookie
directory that has leading spaces in its name, which can cause various
issues, such as breaking syncing on OneDrive.
If we set the format specifier to pad with zeroes instead of spaces, the
resulting hexadecimal value is always 16 characters long without spaces.
