Re: [PATCH] [IOS] Avoid spurious EOF when writing partial bytes

[Jose E. Marchesi]

>>> c) [your proposal] Support write-only IOS, but anything that would
>>>     need to read fails with an exception.
>>>
>>>     This is something of a consistency breakage; everywhere else, poke
>>>     appears to ignore the common limitations of byte-level writing,
>>>     etc.
>> Agreed.  But on the other hand, it is documented and assumed that IO
>> devices are byte oriented (unlike the IOS abstraction built on top of
>> it.) so this need to read completing bytes shoulnd't be much of a
>> surprise.
>>
>>>     Using an EOF exception would be quite confusing for the user as
>>>     well; if this is implemented, please use a more accurate exception
>>>     (maybe a new one needs to be added)
>> Yes, EOF is confusing.
>>
>> I think we really want to introduce an E_perm exception, and raise it in
>> every peek* PVM instruction if the IO space doesn't support read.  Then
>> a dump of a non-readable IO space, for example, would raise the
>> exception instead of showing us an "empty" IO space.
>>
>>>     With this idea, if the user wishes to use a write-only IOS in a
>>>     fully general manner, they must use another IOS as temporary
>>>     storage.
>> Right.  That is easy to do with .mem IOS.  If we go with this option I
>> will write a tutorial-like section in the manual describing how to
>> operate on write-only IO spaces.
>>
>> Let's also keep in mind that write-only IO spaces will be very rare.
>
> This case is handled well by the stream IOS too. Indeed we keep a
> buffer there as Georgiy describes. We could reuse that code to handle
> such cases in the future as well.

But that won't work for write-only files with pre existing contents.
Output streams (write-only streams) are always created anew and
"empty".  That's why the caching strategy works there.

Or I am missing something?