Sadahiro Tomoyuki <[EMAIL PROTECTED]> writes:
>seek $fh, 2**14, SEEK_SET;
>read($fh, my $data, 16);
>close $fh;
>print unpack('H*', $data), "\n";
># says 'acf1adf1aef1aff1b0f1b1f1b2f1b3f1'.
>__END__
>
>I don't know what a magic number 2**14 would be

It might be (a multiple of) VMS's stdio buffer size.

If VMS's buffer is < 16K then there is a mystery as to why 
earlier buffers did not fail same way.

>nor what does it mean,
>anyhow, correct character boundaries around here are
>
>  (f1)ac | f1ad | f1ae | f1af | f1b0 | f1b1 | ...
>
>but, on VMS, they seem to be:
>
>  acf1 | ad | f1ae | f1af | ...
>         ^^HERE warned?
>  (\xAC\xF1 is an existing euc-kr char.)

The current hypothesis is that this point is near where :encoding is 
asks for more data from stdio. This is done by 

   ch = fgetc(f);
   ungetc(ch,f);

and then resuming buffer snooping. The theory is that VMS's ungetc
gets this wrong for some reason.

-- 
Nick Ing-Simmons
http://www.ni-s.u-net.com/



Reply via email to