Craig A. Berry <[EMAIL PROTECTED]> writes: > > >Many thanks. Actually, when I run this I get the correct output >(acf1adf1aef1aff1b0f1b1f1b2f1b3f1) and no warnings, which I think confirms >that we have a buffer getting corrupted (or lost our reference point in it? >[or separate I/O operations getting the two halves of one character?])
I think the Encode issue is due to the last case - a ksc5601 character spanning two stdio buffers - 1st octet in one, 2nd octet in the other. I am hoping that problem is that ungetc() is loosing an octet (why is that not noticed in other tests) or perhaps that multiple-ungetc re-orders the octets. >rather than trouble parsing some particular legitimate byte sequence. Agreed. > >If I create a file containing only lines 229-231 from ksc5601.enc, I also do >not get the warning when reading from it that I get when reading the entire >file. Again good - Encode is blameless IO is looking guilty ;-) -- Nick Ing-Simmons http://www.ni-s.u-net.com/
