readline/histfile.c: Check and retry write() operation in history_truncate_file()

  For regular file, write() operation may also fail, so check it too. If
write() return 0, can simply wait and try again, it should not suspend
infinitely if environments have no critical issues.

The related warning (cross compile for aarch64-linux):

  ../../binutils-gdb/readline/histfile.c: In function ‘history_truncate_file’:
  ../../binutils-gdb/readline/histfile.c:406:13: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Wunused

readline/
    * readline/histfile.c (history_truncate_file):
    Check and retry write() operation.


Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
 readline/ChangeLog.gdb |  5 +++++
 readline/histfile.c    | 25 +++++++++++++++++++++++--
 2 files changed, 28 insertions(+), 2 deletions(-)
  

On 6/10/14, 10:35 PM, Chen Gang wrote:
> For regular file, write() operation may also fail, so check it too. If
> write() return 0, can simply wait and try again, it should not suspend
> infinitely if environments have no critical issues.

Readline-6.3 checks the return value from write() and returns a non-zero
value to the history_truncate_file caller.  I really don't think that
waiting forever if write continues to return 0 is a great idea; an error
return is enough to let the caller deal with it.

Chet
  

On 06/19/2014 04:33 AM, Chet Ramey wrote:
> On 6/10/14, 10:35 PM, Chen Gang wrote:
>> For regular file, write() operation may also fail, so check it too. If
>> write() return 0, can simply wait and try again, it should not suspend
>> infinitely if environments have no critical issues.
> 
> Readline-6.3 checks the return value from write() and returns a non-zero
> value to the history_truncate_file caller.  I really don't think that
> waiting forever if write continues to return 0 is a great idea; an error
> return is enough to let the caller deal with it.
> 

That sounds fine to me, and I will send patch v2 for it. And excuse me,
I have to do some other things today, so I shall try to send it within 2
days (within 2014-06-21) -- if it is too late, please help send it.


Thanks.
  

On 06/19/2014 09:31 AM, Chen Gang wrote:
> 
> 
> On 06/19/2014 04:33 AM, Chet Ramey wrote:
>> On 6/10/14, 10:35 PM, Chen Gang wrote:
>>> For regular file, write() operation may also fail, so check it too. If
>>> write() return 0, can simply wait and try again, it should not suspend
>>> infinitely if environments have no critical issues.
>>
>> Readline-6.3 checks the return value from write() and returns a non-zero
>> value to the history_truncate_file caller.  I really don't think that
>> waiting forever if write continues to return 0 is a great idea; an error
>> return is enough to let the caller deal with it.
>>

Oh, sorry, after think of again, for me, we have to waiting forever if
write() continues to return 0.

When this case happens, the file is already truncated, and the left data
which is writing to file will be free after return from
history_truncate_file().

If return an error code in this case, the caller can not deal with it --
the log data which should be remained, have been lost, can not get them
back again.

> 
> That sounds fine to me, and I will send patch v2 for it. And excuse me,
> I have to do some other things today, so I shall try to send it within 2
> days (within 2014-06-21) -- if it is too late, please help send it.
> 

Thanks.
  

On 6/20/14, 4:57 AM, Chen Gang wrote:
> On 06/19/2014 09:31 AM, Chen Gang wrote:
>>
>>
>> On 06/19/2014 04:33 AM, Chet Ramey wrote:
>>> On 6/10/14, 10:35 PM, Chen Gang wrote:
>>>> For regular file, write() operation may also fail, so check it too. If
>>>> write() return 0, can simply wait and try again, it should not suspend
>>>> infinitely if environments have no critical issues.
>>>
>>> Readline-6.3 checks the return value from write() and returns a non-zero
>>> value to the history_truncate_file caller.  I really don't think that
>>> waiting forever if write continues to return 0 is a great idea; an error
>>> return is enough to let the caller deal with it.
>>>
> 
> Oh, sorry, after think of again, for me, we have to waiting forever if
> write() continues to return 0.

There aren't really any plausible conditions under which write(2) returns
0 instead of -1 when writing a non-zero number of bytes to a regular file.

> 
> When this case happens, the file is already truncated, and the left data
> which is writing to file will be free after return from
> history_truncate_file().
> 
> If return an error code in this case, the caller can not deal with it --
> the log data which should be remained, have been lost, can not get them
> back again.

However, you're right about the data being lost if write fails and returns
-1. Since the sequence of operations is open-read-close-open-write-close, I
think I will change the code for the next version to use a scheme similar
to history_do_write() and restore the original version of the file if the
write fails.

Chet
  

On 06/21/2014 05:53 AM, Chet Ramey wrote:
> On 6/20/14, 4:57 AM, Chen Gang wrote:
>> On 06/19/2014 09:31 AM, Chen Gang wrote:
>>>
>>>
>>> On 06/19/2014 04:33 AM, Chet Ramey wrote:
>>>> On 6/10/14, 10:35 PM, Chen Gang wrote:
>>>>> For regular file, write() operation may also fail, so check it too. If
>>>>> write() return 0, can simply wait and try again, it should not suspend
>>>>> infinitely if environments have no critical issues.
>>>>
>>>> Readline-6.3 checks the return value from write() and returns a non-zero
>>>> value to the history_truncate_file caller.  I really don't think that
>>>> waiting forever if write continues to return 0 is a great idea; an error
>>>> return is enough to let the caller deal with it.
>>>>
>>
>> Oh, sorry, after think of again, for me, we have to waiting forever if
>> write() continues to return 0.
> 
> There aren't really any plausible conditions under which write(2) returns
> 0 instead of -1 when writing a non-zero number of bytes to a regular file.
> 

Hmm... for me, what you said is acceptable.  And the function comment need be
changed:

  "Returns 0 on success, errno or -1 on failure"

>>
>> When this case happens, the file is already truncated, and the left data
>> which is writing to file will be free after return from
>> history_truncate_file().
>>
>> If return an error code in this case, the caller can not deal with it --
>> the log data which should be remained, have been lost, can not get them
>> back again.
> 
> However, you're right about the data being lost if write fails and returns
> -1. Since the sequence of operations is open-read-close-open-write-close, I
> think I will change the code for the next version to use a scheme similar
> to history_do_write() and restore the original version of the file if the
> write fails.
> 

OK, thanks.

And since you will work for it next, is it still necessary to send patch v2 for
the temporary fix, at present?


Thanks
  

On 6/20/14, 10:25 PM, Chen Gang wrote:

>> There aren't really any plausible conditions under which write(2) returns
>> 0 instead of -1 when writing a non-zero number of bytes to a regular file.
>>
> 
> Hmm... for me, what you said is acceptable.  And the function comment need be
> changed:
> 
>   "Returns 0 on success, errno or -1 on failure"

history_truncate_file will never return -1.

> And since you will work for it next, is it still necessary to send patch v2 for
> the temporary fix, at present?

I will take care of making those changes, thanks.

Chet
  

On 06/22/2014 07:19 AM, Chet Ramey wrote:
> On 6/20/14, 10:25 PM, Chen Gang wrote:
> 
>>> There aren't really any plausible conditions under which write(2) returns
>>> 0 instead of -1 when writing a non-zero number of bytes to a regular file.
>>>
>>
>> Hmm... for me, what you said is acceptable.  And the function comment need be
>> changed:
>>
>>   "Returns 0 on success, errno or -1 on failure"
> 
> history_truncate_file will never return -1.
> 

Hmm... do you mean:

  "for regular file, write() never return 0, if parameter 'count' > 0?"

  or

  "if write() return 0, can also return 0 to history_truncate_file()?".


>> And since you will work for it next, is it still necessary to send patch v2 for
>> the temporary fix, at present?
> 
> I will take care of making those changes, thanks.

OK, thanks (I need/shall not send patch v2 for it).


Thanks.
  

On 6/21/14, 10:01 PM, Chen Gang wrote:

>> history_truncate_file will never return -1.
>>
> 
> Hmm... do you mean:
> 
>   "for regular file, write() never return 0, if parameter 'count' > 0?"
> 
>   or
> 
>   "if write() return 0, can also return 0 to history_truncate_file()?".

Both of those things are true, but neither is what I said above.
  

On 06/23/2014 09:57 PM, Chet Ramey wrote:
> On 6/21/14, 10:01 PM, Chen Gang wrote:
> 
>>> history_truncate_file will never return -1.
>>>
>>
>> Hmm... do you mean:
>>
>>   "for regular file, write() never return 0, if parameter 'count' > 0?"
>>

I am not quite sure whether it is true, in my experience, it should be
true, but I have no any proofs for it (if you have, welcome to supply).

thank.

>>   or
>>
>>   "if write() return 0, can also return 0 to history_truncate_file()?".
> 

For me, if write() could return 0, when it happened, we had to process the
case within history_truncate_file(), could not only return 0 to indicate
all things go on well.


> Both of those things are true, but neither is what I said above.
> 

If both of those things are not true, what your originally said above
are not true, either.


Thanks.
  

And I guess, we can simply bypass this discussion, because the new fix
can process write() well and let history_truncate_file() never return -1.

Thanks.

On 06/23/2014 10:59 PM, Chen Gang wrote:
> On 06/23/2014 09:57 PM, Chet Ramey wrote:
>> On 6/21/14, 10:01 PM, Chen Gang wrote:
>>
>>>> history_truncate_file will never return -1.
>>>>
>>>
>>> Hmm... do you mean:
>>>
>>>   "for regular file, write() never return 0, if parameter 'count' > 0?"
>>>
> 
> I am not quite sure whether it is true, in my experience, it should be
> true, but I have no any proofs for it (if you have, welcome to supply).
> 
> thank.
> 
>>>   or
>>>
>>>   "if write() return 0, can also return 0 to history_truncate_file()?".
>>
> 
> For me, if write() could return 0, when it happened, we had to process the
> case within history_truncate_file(), could not only return 0 to indicate
> all things go on well.
> 
> 
>> Both of those things are true, but neither is what I said above.
>>
> 
> If both of those things are not true, what your originally said above
> are not true, either.
> 
> 
> Thanks.
>