This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: 27.8.1.4/19: "reconstruct the original contents of the file"?
On Sep 25, 2010, at 2:13 PM, David Krauss wrote:
> 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.
Ok. The block encodings I mentioned (encryption, compression, ...) were speculative and you're saying that nobody is doing these operations using codecvt's. I can believe that. They really are the wrong way to do that kind of operation, but the standard didn't offer any alternative (and I think the new standard doesn't either.)
>
> 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.
I may be missing something, but I don't see how you can ask a codecvt facet to skip the unshift sequence. Are you expecting that to be handled by the new codecvt? Is that what you mean by "compatible encoding"?
>
> 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.
>