Hi, Il 15/03/19 19:09, Matthew Woehlke ha scritto:
The mapping of \u escape sequences to the execution character set happens before string literal concatenation (translation phases 5/6). But AFAIU the mapping is purely symbolic, and has nothing to do with any actual encoding, so MSVC is at fault here?Why do you think it's "symbolic"? The standard clearly says "if there is no corresponding member [of the target character set], [the character] is converted to an implementation-defined member". That's obviously the case for the characters in question, so they get mapped to '?'.AFAICT, in my example (execution character set == CP-1252), MSVC is doing what the standard requires it to do. It's unfortunate that this isn't what the user wanted, but I don't see a "solution" except to swap phases 5 and 6. (But again, this does*not* apply to the ECS == UTF-8 case.
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? F
rom 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).
My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | 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: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
