[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jose E. Marchesi
Subject: Re: [PATCH] [IOS] Avoid spurious EOF when writing partial bytes
Date: Sat, 27 Mar 2021 14:45:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

>>> 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]