Re^2: binmode layer and seek

Ah I see. Thanks for the explanation. What I didn't understand was why the layer was working for one thing and not another. I've had a look at the MD5.pm and it's using XSloader, which I presume means the MD5.pm is using C and therefore bypassing the layer. Having said that, if it was bypassing the layer I'd expect it to give the correct result. John

Comment on Re^2: binmode layer and seek

Replies are listed 'Best First'.
Re^3: binmode layer and seek by moritz (Cardinal) on Jul 08, 2008 at 13:46 UTC
MD5.pm doesn't bypass anything. If it would, you'd get the same result for all three outputs. Here is, in more detail, what happens: You open a file, and apply the crlf IO layer. You write a "\n" to that file. The crlf layer converts that to CRLF MD5.pm reads from the very same filehandle. That means that the CRLF is converted to "\n" again upon reading. MD5.pm interprets that as binary data, and thus as LF. You close the file, and open it again, this time without any layer MD5.pm reads from that file, and this time the line ending comes out as CRLF, because no IO layer converts anyting. MD5.pm computes a hash, which is different than before because the source data is different	[reply]

Replies are listed 'Best First'.

Re^3: binmode layer and seek
by moritz (Cardinal) on Jul 08, 2008 at 13:46 UTC

Here is, in more detail, what happens:

You open a file, and apply the crlf IO layer.
You write a "\n" to that file. The crlf layer converts that to CRLF
MD5.pm reads from the very same filehandle. That means that the CRLF is converted to "\n" again upon reading. MD5.pm interprets that as binary data, and thus as LF.
You close the file, and open it again, this time without any layer
MD5.pm reads from that file, and this time the line ending comes out as CRLF, because no IO layer converts anyting. MD5.pm computes a hash, which is different than before because the source data is different

[reply]