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

[Mohammad-Reza Nabipoor]

Hi, Jose.

On Sat, Mar 27, 2021 at 10:07:33AM +0100, Jose E. Marchesi wrote:
> 
> I forgot to mention a corollary of this bug.
> 
> In poke sometimes writing requires reading, like for example when
> writing weird integers or unaligned integers, i.e. when working with
> partial bytes, which should be "completed" with their current value in
> the IO space.
> 
> Now, we support write-only IO spaces.
> 
> Without this patch, this raises EOF:
> 
>   (poke) var fd = open ("lalala", IOS_M_WRONLY | IOS_F_CREATE)
>   (poke) int @ 0#B = 0xffffffff
>   -----> at this point the IO space has 4 0xff bytes
>   (poke) uint<3> @ 0#B = 2
>   unhandled EOF exception
> 
> With this patch, the EOF exception is gone, but since the completing
> byte cannot be read it is assumed to be 0, and therefore the resulting
> data is not the right one:
> 
>   (poke) var fd = open ("lalala", IOS_M_WRONLY | IOS_F_CREATE)
>   (poke) int @ 0#B = 0xffffffff
>   ------> With this patch, the write above will use 0 to complete the
>           first byte of the file, instead of 0xff!
>   (poke) uint<3> @ 0#B = 2
>   (poke) close (fd)
>   (poke) .file lalala
>   (poke) dump
>   76543210  0011 2233 4455 6677 8899 aabb ccdd eeff  0123456789ABCDEF
>   00000000: 40ff ffff                                @...
> 
> So I propose the following fix:
> 
> - If reading a completing byte is needed in a write, _and_ the IO space
>   doesn't allow reading, the write operation should raise an EOF
>   exception.
> 
> WDYT?
> 

The only thing is that EOF is not a good choice. Maybe EIO is a better
option.
But it'll not help the confused user (but maybe because the user is dealing
with a weird situation (write-only file), he/she deserves a weird error :D).
I think documenting this behavior under the `IOS_M_WRONLY` flag will solve
the UX problem.