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.sherr...@oarcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
