C++ Logo


Advanced search

Re: [isocpp-core] P2295 Support for UTF-8 as a portable source file encoding

From: Davis Herring <herring_at_[hidden]>
Date: Thu, 9 Jun 2022 13:57:46 -0600
>> What we want to mean by that is that the input file is the sequence
>> of bytes returned from open(2) and read(2), >
> This is definitively not the intent. any piece of textual data can
> be modeled as a sequence of integers, regardless of system specifics
> or underlying storage mechanism.

Of course: I didn't mean to suggest that we wanted to limit anything to
that case, just to say that what we want (and can't have) is that _if_
your compiler is using open and read it must support the results being
UTF-8. That is, after all, what users are hoping when we tell them that
"C++ compilers all support UTF-8 now".

> It may be "toothless" in a very hostile implementation, but we
> already established that. We should not spend so much time thinking
> of the evil ways an implementation could abuse phase 1 wording as it
> is not a game we can win. Nor is it today, an implementation can
> replace the content of the source file by nothing and claim
> conformance. Yet they don't. There needs to be a reasonable starting
> point, otherwise we will find ourselves specifying drive firmwares.
I really agree with this stance; I just think that Hubert's suggestion
is a good way of going far enough to be clear of intent and not so far
as to be ridiculous.


This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 

Received on 2022-06-09 19:57:53