Elazar Leibovich wrote:
IIRC the problem was using a different library, and tracing which
problems are yours and which are of the library.
See for instance this
rant http://www.mega-nerd.com/erikd/Blog/CodeHacking/house_of_cards.html
I haven't really got into this, so maybe the suprresion files does
allow you to quickly fix it.
The way I see it, a problem in a library you use is still a problem in
your product. This is not really a false positive.
It's more complex than that. The code currently work on the embedded
device. This is a mission critical device, so we cannot make changes
to the runtime code without testing it throughly first.
I try therefor to fix the problem in the emulation level without
touching the actual code. (for instance, overriding a certain
problematic function which used an uninitialized variable, and got
away with it in the embedded device, but not in the desktop, or,
replace the macro which stores a specific memory address (hex number)
which is used by a the code, and is obviously relevant only for the
embedded device)
I'll repeat it again, and then stop, as I don't want it to become a war.
The fact it is mission critical is another reason to fix all warnings,
not a reason to ignore them.
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
_______________________________________________
Linux-il mailing list
Linux-il@cs.huji.ac.il
http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
