Re^2: Generating a readline error

Thanks, the method used in the second snippet (added since my original reply) will be useful to me. It's even portable (using the appropriate device name)!

It would be ideal if I had a means of generating an error after doing some valid reads, but I can make do without.

Comment on Re^2: Generating a readline error

Replies are listed 'Best First'.
Re^3: Generating a readline error by Marshall (Canon) on Jul 17, 2009 at 18:37 UTC
I guess you could read for awhile and then close the filehandle. It is possible to open 2 filehandles to same file. Close one and keep going with the other one after first bombs. My seek idea didn't work as seek past EOF is not an error (that's how to generate "sparse files"). I've tested that on Perl before (*nix and even XP) and it works fine and you just get EOF if you read something like that. Of course EOF is not an error. And of course a write past EOF is completely legal and produces no error. I've written device drivers that will pass back "known bad data" from say disk system. But that's a special thing and drivers,O/S,app have to know what's going on. That sort of thing is used in huge volume data applications where say 12 bits wrong won't matter in say a video image or a seismic data app. Still curious as to what kind of data recovery is possible in typ Perl app after "bad data" from an I/O device?	[reply]
Re^4: Generating a readline error by ikegami (Patriarch) on Jul 17, 2009 at 18:58 UTC
Still curious as to what kind of data recovery is possible in typ Perl app after "bad data" from an I/O device? Thinking you've reached the end of the file before you actually have can lead to incorrect error messages down the line or no error down the line when there should be one. I'm trying to fix `readline`'s documentation. The snippet is wrong. A fix was provided for bleadperl (5.12-to-be), but it introduced an error while fixing none.	[reply] [d/l]