Active Topics
-
Maemo 20th Anniversary (4)
to Brainstorm by teroyk - 18 hrs, 59 mins ago -
Nokia Booklet 3G (RX-75) Drivers (64)
to Alternatives by teroyk - 19 hrs, 15 mins ago -
Porting apps to Leste (46)
to Maemo 7 / Leste by teroyk - 2 days, 22 hrs ago -
Maemo repository (8)
to Community by Maemish - 6 days, 16 hrs ago - more...
|
2010-11-04
, 20:43
|
|
Posts: 93 |
Thanked: 30 times |
Joined on Oct 2007
@ Glendale, CA
|
#12
|
Originally Posted by javispedro
FWIW, Coverity does a very good job on showing only real invalid pointer defects (or real defects of any type for that matter). If you have experience w/ the tool, I am surprised that you would still have that opinion.
I do marginalize the effectiveness of a static analysis code tool for detecting such issues.
 |
|
2010-11-04
, 21:17
|
|
Posts: 361 |
Thanked: 219 times |
Joined on Sep 2010
|
#13
|
Originally Posted by javispedro
I would ask why there is no
I do marginalize the effectiveness of a static analysis code tool for detecting such issues.
Code:struct some_interface *c = get_from_global_variable(); some_callback_type f = default_callback(); if (c->do_something(c, &f)) { f(); }
check for c and f at first.
;-)
Plain defensive programming.
Originally Posted by javispedro
It will find this:
What's a static code analysis tool doing to do here? It may
a ) Either detect a "potential NULL dereference", thus indicating that the 5000000 potential bugs found count is pure crap.
http://scan.coverity.com/report/Cove...eport_2009.pdf
and there the stuff about
"In drivers/net/tun.c, the relevant code fragment is
static unsigned int tun_chr_poll(struct file *file, poll_table * wait)"
Originally Posted by javispedro
You know that sometimes when you look at your code over and over again you simply miss certain points.
Now, of course their tools ain't cheap. They're doing a great service to the community IMHO but also getting some free marketing for a tool a decade or two ago would be laughed at.
Note: not saying it is useless; it's as useless as getting a human to do it: they might get it wrong, but "the more eyes...".
Especially after long nights, much coffee and pizza.
 |
|
2010-11-04
, 21:46
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#14
|
Originally Posted by microe
I have no doubt it makes the best good job it could do. The problem is that it is theoretically impossible for it to do the perfect job. I have no experience with Coverity, but I do have some experience in compiler design.
FWIW, Coverity does a very good job on showing only real invalid pointer defects (or real defects of any type for that matter). If you have experience w/ the tool, I am surprised that you would still have that opinion.
Only in an insane world 359 "potential" null dereferences implies 359 software defects, and only in an even more insane world 359 software defects imply 359 CRITICAL security issues.
Originally Posted by PMaff
Ah, a Java user!
I would ask why there is no
check for c and f at first.
;-)
Plain defensive programming.
Do you know that GCC has both a always-check-for-nulls-before-first-deference and a array bounds checking patch? I leave as an exercise to the reader why Linux doesn't use them.You know that sometimes when you look at your code over and over again you simply miss certain points.
Especially after long nights, much coffee and pizza.
Last edited by javispedro; 2010-11-04 at 21:48.
If it weren't, it would go boom if the phone got stuck in an infinite loop: high drain, software dead, overheat > boom. The battery cuts power by itself if it's worth any of that 1000% markup Nokia puts on it.
The scenario you proposed would be indeed valid if Nokia used an enthusiast/modeling battery - those are only limited in amps - sometimes not even that. IIRC, they don't even make them in the same form factor.
N900 dead and Nokia no longer replaces them. Thanks for all the fish.
Keep the forums clean: use "Thanks" button instead of the thank you post.