Why sysread over read? The only difference is that read is buffered, which is a good thing. I'd replace sysread with read.
Partially habit. On my system, at least at some point in the past, the interaction between Perl buffering and the OS caching was less productive that using the systems caching alone.
Partially because in perlfunc sysread it says:
It bypasses buffered IO, so mixing this with other kinds of reads, print, write, seek, tell, or eof can cause confusion because the perlio or stdio layers usually buffers data.
And since I used '<:raw', which (as I understand it, bypasses PerlIO layers), it seems prudent to avoid buffered IO calls.
N* for floats?
Mea culpa. The code is untested as I don't have a relevant data file, and could not mock one up because I do not know what system it was written on.
Basically, the code I posted was intended as an example of how to proceed, not production ready copy&paste.
I don't think a smaller than expected return value is an error. It simply means you need to call the read function again.
I think that's true when reading from a stream device--terminal, socket or pipe--but for a disk file, if you do not get the requested number of bytes, (I believe) it means end of file.
I'm open to correction on that, but I do not see the circumstances in which a disk read would fail to return the requested number of bytes if they are available?
In reply to Re^3: reading binary files with Perl
by BrowserUk
in thread reading binary files with Perl
by jpk1292000
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |