Re: Buffered IO and un-intended slurping

$record=<INDX> is alias for readline, which is buffered ( AFAIK at least when $/ is a newline). As others rightly noted, mixing buffered and non-buffered I/O is not a good idea. It is also not clear also whether your $/ is a newline or 41, - in the latter case it simply can be a perl bug, and all the best practices with locating and reporting it do apply.

Also, you said that you've converted code into using sysread, but I can't think about how sysread($f, $buf, 41) would slurp anything beyond the 41th byte. I'd however use buffered I/O here, but the same question goes to read($f, $buf, 41) as well.

Comment on Re: Buffered IO and un-intended slurping Select or Download Code

Replies are listed 'Best First'.
Re^2: Buffered IO and un-intended slurping by Wiggins (Hermit) on Jan 02, 2010 at 14:31 UTC
There was no mixing of buffered and unbuffered on a file. It all started out buffered; after the lost positioning I converted all the IO calls to unbuffered for that file. 41 is the record size... 40 bytes for the SHA1, 1 byte for the newline .... 40+1=41. I never even touch the $/ value in the program And keep in mind that this happened just 1 in a 1000 times this module was called. It is always better to have seen your target for yourself, rather than depend upon someone else's description.	[reply]
Re^3: Buffered IO and un-intended slurping by dk (Chaplain) on Jan 03, 2010 at 10:56 UTC
If, as you say, you never mix buffered and unbuffered I/O, and never alter $/, then there's something fishy and unexpected. I sincerely doubt that seek() calls, even if done on a buffered stream and even with mixed dos and unix newlines, would produce such an effect. I'd investigate further to find what causes the slurping, at least to make clear if that's a perl bug or not. otoh, if you're only interested in a practical solution, just switch to `read($f, $buf, 41)` instead of `readline`, which depends on $/.	[reply] [d/l] [select]