Here are methods that can be used for conversion:
TQT_NO_ASCII_CASTis not set, the
ascii()method can be automatically used for the conversion.
The problem is that many of these automatic conversions are wrong. It is better when
TQT_NO_ASCII_CASTis set – it is default for CMake builds. The second problem is that the
ascii()method is used – see below.
ascii(). This method has two options as she behaves. If the global
TQTextCodec::codecForCStringsis set, the codec will be used for the conversion. If it is not set, the call is the same as the
The problem is that most of
ascii()calls are wrong. Often these calls should be
latin1()may be used.
All methods appear to be easily replaceable at first glance – for example, use
str.local8Bit() instead of the wrong
str.ascii(). But there is one fundamental difference that represents a hidden danger.
ascii() methods in both use modes create a internal buffer char* in the TQString object and return the pointer to this buffer. As a result, the return value is valid throughout the validity of the TQString object.
local8Bit() methods return a new TQCString object. The TQCString object provides a simple conversion to char*, which makes it easy to use to replace instances of wrong
ascii() calls. However, this object is not referenced in TQString, which may result in very limited validity. We have encountered this problem several times – for example, in connection with the use of
utf8() for password. The current case was in KShutdown (already fixed in the next commit).
There can be many uses of
local8Bit() that are not safe. We can either check all the uses of these methods in all source codes – at least all the recent commits “Added controlled conversions to char* instead of automatic ascii conversions.” – yes, this is my recent contribution to potential problems. Or make the
local8Bit() methods safe as well as
latin1() – as it is in the proposed patch.
The structure of TQStringData is the internal structure used only in TQString. Changing this structure will not cause break API / ABI compatibility. I believe that the proposed solution can eliminate some hidden issues. Therefore, I would like to also backport that solution into the R14.0.x branch.
What is your opinion?