On Wed, Nov 26, 2014 at 8:55 AM, Joel Sherrill
<joel.sherr...@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.og...@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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
