You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 withfilemode_Write
, otherwise thebufeof
is set to the end of the buffer. It also prevents you from seeking usingseekmode_Start
pastbufeof
, 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 afilemode_ReadWrite
orfilemode_WriteAppend
stream. It would make a difference for a file stream, wherefilemode_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.
The text was updated successfully, but these errors were encountered: