poke-devel
[Top][All Lists]
Advanced

[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 12:38:37 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

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

Agreed EOF is no good. See the patch series for E_perm I just sent to
the list.

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

Yeah, documentation.




reply via email to

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