First, it seems that there are no real "reconstruction algorithm" at all. Seek is allowed to point to any byte position, even to place "inside" characters for multibyte encodings, such as UTF-8.

Second, about performance:  I talk about implementation mentioned in first message. If it is not used (and will not be used), we may forget about that sentence.

Next, once again:

I consider it is a bug in allowing to seek to invalid byte offsets for text files. Since we cannot easily calculate what offset will be valid (for example, seek past the end of file, or places inside character), just disallow seek. In real applications, no one will seek/peek to places other than

* beginning of the file
* current byte offset
* seeking to the end of file.

so this seeks/peeks must be allowed.

This is applicable only to variable multibyte encodings (such as UTF-8).