If we had a static analyzer that ran automatically as part of the WebKit
development process, and a shared goal to get its complaints down to 0,
then it might be reasonable to skip creating tests for issues that it
diagnoses. But that doesn't seem to be the situation here.
If we ran a static
I completely agree with Maciej here that if this is a reachable code, then
the patch author should put a reasonable effort into creating a test case. And
most importantly, these changes are clearly not code cleanup.
I'm disagreeing here. (as far as NULL checks go).
Unless there's a
I completely agree with Maciej here that if this is a reachable code, then
the patch author should put a reasonable effort into creating a test case. And
most importantly, these changes are clearly not code cleanup.
I'm disagreeing here. (as far as NULL checks go).
Unless there's a
If this issue was spotted by a static analyzer, it would be good to
mention that in the ChangeLog too.
We (the static analysis loons ;) usually try to do that. (The log will
contain CID= to identify the Coverity ID, and most of the time a
[Coverity] tag).
The bug that David mentioned
Hi there!
I'm currently working on Chromium's new tab page, which amongst other things
requires page favicons in different sizes than 16x16. And while the WhatWG
spechttp://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#rel-iconsupports
multiple link rel=icon... elements, webkit
5 matches
Mail list logo