[PATCH 19/20] libcsupport/src/sync.c: Explicitly ignore return status

[Gedare Bloom]

On Wed, Nov 26, 2014 at 8:55 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
> On 11/26/2014 01:05 AM, Sebastian Huber wrote:
>>
>> On 26/11/14 00:02, Joel Sherrill wrote:
>>>
>>> From: Josh Oguin<josh.oguin at oarcorp.com>
>>>
>>> CodeSonar spotted that the return values were being ignored.
>>> ---
>>>    cpukit/libcsupport/src/sync.c | 6 ++++--
>>>    1 file changed, 4 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/cpukit/libcsupport/src/sync.c
>>> b/cpukit/libcsupport/src/sync.c
>>> index b8e5059..0e935ce 100644
>>> --- a/cpukit/libcsupport/src/sync.c
>>> +++ b/cpukit/libcsupport/src/sync.c
>>> @@ -43,8 +43,10 @@ static void sync_wrapper(FILE *f)
>>>       *  matter if they succeed.  We are just making a best faith attempt
>>>       *  at both and trusting that we were passed a good FILE pointer.
>>>       */
>>> -  (void) fsync(fn);
>>> -  (void) fdatasync(fn);
>>> +  if ( fn != -1 ) {
>>> +    (void) fsync(fn);
>>> +    (void) fdatasync(fn);
>>> +  }
>>>    }
>>>
>>>    /* iterate over all FILE *'s for this thread */
>>
>> This test is superfluous since both functions validate the file
>> descriptor.  All other patches look good.
>>
> How about I add a debug assert on the status code
> and the fileno?
>
You mean in fsync and fdatasync?

Sebastian's point is that you shouldn't condition the function calls
on fn != 1, since the functions check themselves.

> One thing that the analysis of Mars Mission software defects
> over the past decade of missions showed is that code with
> higher level of debug assertions tended to have fewer problems.
> If we are making an assumption, don't just document it,
> enforce it in code.
>
> --joel
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel