maemo.org - Talk - Android kernel: revealed 359 software defects

maemo.org - Talk (https://talk.maemo.org/index.php)

- Competitors (https://talk.maemo.org/forumdisplay.php?f=4)

- - Android kernel: revealed 359 software defects (https://talk.maemo.org/showthread.php?t=65035)

Re: Android kernel: revealed 359 software defects

Quote:

Originally Posted by lma (Post 863070)

or mess with the charging logic (potential for things going boom).

Not likely, the battery itself is load limited, overcharge protected, undercharge protected and thermal limited, as are all Lithium batteries meant for (high-end) consumers.

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.

Re: Android kernel: revealed 359 software defects

Quote:

Originally Posted by javispedro (Post 863507)

I do marginalize the effectiveness of a static analysis code tool for detecting such issues.

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.

Re: Android kernel: revealed 359 software defects

Quote:

Originally Posted by javispedro (Post 863507)

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();

}

I would ask why there is no
check for c and f at first.
;-)
Plain defensive programming.

Quote:

Originally Posted by javispedro (Post 863507)

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.

It will find this:
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)"

Quote:

Originally Posted by javispedro (Post 863507)

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...".

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.
;)

Re: Android kernel: revealed 359 software defects

Quote:

Originally Posted by microe (Post 863630)

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.

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.

Quote:

Originally Posted by PMaff (Post 863673)

I would ask why there is no
check for c and f at first.
;-)
Plain defensive programming.

Ah, a Java user! ;) 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.

Quote:

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.
;)

And I agree, as I said: the more eyes the better.