On 18/03/2019 17:02, Matthew Woehlke wrote:
On 16/03/2019 12.13, Giuseppe D'Angelo via Development wrote:What I meant is this: during phase 5 and 6, are string literals simply sequences of symbols from a set, or are they already encoded in some encoding? From my reading, it's the former (the execution character set is just this -- a set of symbols), and it's only after phase 6 that those symbols are encoded in sequences of char/char16_t/... values (depending on the string literal prefix).I would certainly read 5 as*implying* that at the conclusion of that phase, string literals have a definite encoding.*Not* applying that assumption seems to be how we get the broken MSVC behavior of "reinterpreting" a UTF-8 string as CP-1252.
Is there a "not" or a double negation somewhere? The way I am what _should_ happen is: at the end of phase 5 / 6, string literals are just sequences of symbols from a set. Encoding is still not a thing. After phase 7 (\0 appended at the end), then the string gets actually encoded as an array of char/char16_t/etc.
The fact that MSVC is not seeing sequences of symbols but encoded sequences at the end of phase 5, and then messing things up in phase 6, is IMHO the bug.
At the end of this... did anyone submit a bugreport against MSVC? Is it worth proposing a clarification against the Standard?
Cheers, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
