On Tuesday, 4 August 2026 07:14:12 Pacific Daylight Time Andreas Hartmetz 
wrote:
> I mainly combined these ideas:
> - AutoText is only a security problem if the string is externally
>    supplied
> - Fixed strings in the (QML) source code are not externally supplied
> - The QML engine has some compiler-like facilities that could possibly,
>    with minimal extra effort, identify fixed strings in the source code;
>    not sure how much of that runs in maximally interpreted mode.
> 
> The minimal extra effort part is important for the cost-benefit ratio to
> make any sense.
> 
> AutoText also seems most useful when throwing something together quickly
> without much care (prototypes and such), which is a case in which fixed
> or at most translated strings are very common.

I don't think QML is the main user here. It's going to be C++ code using 
legacy widgets, as rich text can be applied to QLabel and friends. That also 
means we have less control on the language.

I thought of something similar to std::format: it enforces that the pattern be 
a literal at compilation time, so we could then detect at compilation time 
whether it is rich text or not. Setting a non-compile-time QString would then 
automatically switch to plain text mode. The problem with this -- and with 
std::format() -- is the lack of integration with l18n: we'd need to pass on 
through the tr() call or equivalent whether the literal string was a rich text 
or not, and assume the translators used the same mode.

And this requires consteval, so C++20, which is not acceptable for Qt 6. So I 
think the solution is what the OP proposed: simply flip the default, possibly 
with a #define choice to opt in or out.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Principal Engineer - Intel DCG - Platform & Sys. Eng.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

-- 
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development

Reply via email to