Re: 27.8.1.4/19: "reconstruct the original contents of the file"?

[David Krauss <potswa at mac dot com>]

OK, that's good news. I just can't be too sure :v) . In practice, encoding transitions are never solved by the converter itself. Instead you have some sequence like XML's "<![CDATA[...]]>" which you can lock onto and synchronize with. That's what is important to support, not the most general case.

For the general case, however, assuming the file was written using C++ (or reasonably at all), a preceding encryption encoding will terminate the block when imbue() is called when writing the file, so assuming the file is at the same position when imbue() is called when reading, skipping the expected unshift sequence will reach the correct position just after the block. As I mentioned, this will fail (perhaps quietly) if the encodings are inherently incompatible but then the user deserves it. I'm writing up such a testcase now.

Since the "precondition" text appears to be normative and require the function to fail if not met, that should probably be filed as a defect.

	- thanks,
	D

On Sep 25, 2010, at 3:51 PM, Jerry Schwarz wrote:

> 
> I'm afraid I don't remember having anything to do with this paper.  It only has Steve's name on it.  And I don't remember any discussion of this issue.
> 
> However my opinion at this time would be that "This is less reasonable ..." is an understatement.  I would say the second interpretation of imbue is unreasonable.
> 
> The tough cases are those in which the encoding isn't just stateful but involves block encodings such as compression, encryption, error correction codes, etc.  However I doubt that the note was based on actual experience with such encodings so I wouldn't take what it says too seriously.  I'm not even sure whether codecvt is flexible enough to deal with those at all.  The thinking at the time was mainly focused on Asian multi-byte character sets of various sorts.  
> 
> The special case you hypothesize of run encoding for 0's is just a special case of this problem.
> 
> I think the essential ingredient in any solution of these problems would involve knowing where the block boundaries are.  It's been a long time since I looked at this so I'm not sure whether it can be done in general.  My guess is you would need to impose some special requirements on the code facets.  
> 
> Sorry I can't be of more help.  It's an interesting problem so keep me informed about how you resolve it.