Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Glk: seekmode_End in memory streams #8

Open
curiousdannii opened this issue Jan 10, 2023 · 0 comments
Open

Glk: seekmode_End in memory streams #8

curiousdannii opened this issue Jan 10, 2023 · 0 comments

Comments

@curiousdannii
Copy link
Member

curiousdannii commented Jan 10, 2023

I've found something that's not fully specified: when you use seekmode_End in a memory stream I had thought that it should seek based on the end of the buffer. memstreamtest however expects it to be seeking based on how much has already been written to the stream, even though that doesn't really seem to be a concept in the spec. Looking at the implementations of GlkOte and RemGlk, it appears that this only happens when a memory stream is created with filemode_Write, otherwise the bufeof is set to the end of the buffer. It also prevents you from seeking using seekmode_Start past bufeof, meaning that you can't seek ahead to write data and then go back to fill in the skipped bytes.

Honestly this seems like a mistake to me - there doesn't seem to me to be any innate reason why seeking in a filemode_Write memory stream should behave differently than a filemode_ReadWrite or filemode_WriteAppend stream. It would make a difference for a file stream, where filemode_Write means a clean start, but memory streams are different.

But even if Zarf agreed with me that it was conceptually a mistake (and he probably won't 😉), it would be too late to change the behaviour. So I'll change my implementation to match the memstreamtest. But the spec should also be edited to explain this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant