On 27 October 2016 at 18:21, Marvin Gülker wrote: > Hi, > > On Wed, Oct 26, 2016 at 04:55:44PM +0100, Jonathan Wakely wrote: >> Yes, the characters of the u8 string literal are required to be UTF-8 >> encoded code units by the standard. So I think your description is >> correct. > > Thank you. That's good to know. > >> I don't see why a warning should be issued though. u8 literals are >> useful when the execution character set is *not* UTF-8, because you >> can use them to ensure a string is UTF-8 encoded when it otherwise >> wouldn't be. Warning for those use cases seems unnecessary. > > Yes, but the reason I was argueing for a warning is that if you have an > u8 literal in the sourcecode *and* pass -fexec-charset the option is > (correctly) ignored according to your statement. If an option is > ignored, that should yield a warning in my opinion. But it's not ignored. It still determines the execution character set, and the encoding of normal string literals. It's just that u8 string literals are encoded as UTF-8, not the execution character set. > I don't have strong feelings towards adding a warning, though. What I > would like to see still is a comment about the u8 and similar literals > in the documentation of -fexec-charset so there is a point where it is > made clear that the option does not affect this specific kind of string > literals. IMHO it's not necessary, because strings encoded in UTF-8 are encoded in UTF-8, by definition. So it's redundant to say "strings with a specific encoding have that encoding, not the encoding of the execution character set".
