>> 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.

Davis

-- 
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 
shipping.