Coverity Scan on main_help.c

Joel Sherrill joel.sherrill at OARcorp.com
Tue Sep 17 15:00:36 UTC 2013


On 9/17/2013 9:16 AM, Sebastian Huber wrote:
> On 2013-09-17 16:05, Joel Sherrill wrote:
>> Hi
>>
>> Take a peek at Issue 1063872 and 1063873. These are in main_help.c
>> and I think Scan is not happy with newlib's putchar() macro. It
>> increments the buffer pointer but it always ends up one past
>> what you use on any given call.
>>
>> Since the pointer ends up pointing at something which is not
>> visibly dereferenced, Scan is not happy.
>>
>> I think this is another intentional and OK to ignore but a
>> double check is also appreciated.
>>
>>
> The macro expansion is
>
> int myputchar(int c)
> {
>    return (--(((__getreent())->_stdout))->_w < 0 ?
> (((__getreent())->_stdout))->_w >= (((__getreent())->_stdout))->_lbfsize ?
> (*(((__getreent())->_stdout))->_p = (c)), *(((__getreent())->_stdout))->_p !=
> '\n' ? (int)*(((__getreent())->_stdout))->_p++ : __swbuf_r((__getreent()),
> '\n', ((__getreent())->_stdout)) : __swbuf_r((__getreent()), (int)(c),
> ((__getreent())->_stdout)) : (*(((__getreent())->_stdout))->_p = (c),
> (int)*(((__getreent())->_stdout))->_p++));
> }
>
> so I would also complain ;-)
>
Wow! That's pretty ugly!!

The complaint itself is surprisingly simple.

CID 1063873 (#1 of 1): Incorrect pointer increment (NO_EFFECT)
no_effect_deref: The dereference in "(int)*__getreent()->_stdout->_p++" 
has no effect.

This happens whether the value passed in is constant or not.

Do we ignore this or pass this report on to the newlib list for
further discussion?

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985




More information about the devel mailing list