Re: [webkit-dev] Eliminate potential null pointer dereference?

On Fri, Apr 20, 2012 at 1:48 PM, Rachel Blum wrote: > 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 disa

Re: [webkit-dev] How can I get some debug infomation in MediaPlayerPrivateGStreamer.cpp

hi Philippe, Thank you for your reply. In some functions of MediaPlayerPrivateGStreamer.cpp, I can get output of printf. But when I add printf in some functions just like isAvailable, I cannot get anything output in all of the functions of MediaPlayerPrivateGStreamer.cpp. After many tests, I found

Re: [webkit-dev] Where to call Codeblock::dump from within webcore

On 04/20/2012 08:25 AM, Andy Wingo wrote: On Wed 18 Apr 2012 21:28, pgsery writes: I want to call CodeBlock::dump from webcore in addition to the jsc shell. I've compiled webkit-1.6.1 with the --enable-debug option, modified dump to print to a file, instead of stdout, and set options.dump=true

Re: [webkit-dev] Contributor meeting hackathon: Move methods from layoutTestController

I've long felt guilty about setPOSIXLocale, which was used to regression test an issue that only comes up on non-Qt Linux ports (related to how sprintf handled floating-point numbers dependent on locale). But from a glance at the code it may be used in other places now. On Thu, Apr 19, 2012 at 4:

[webkit-dev] Hackathon: Convert pixel tests to text-only tests

Hi all, I've put together a list of DRT tests that may be convertible to either text or ref tests: . Feel free to either choose a test yourself or pick one of the tests from the list and convert it. Dan __

Re: [webkit-dev] Eliminate potential null pointer dereference?

On Fri, Apr 20, 2012 at 1:48 PM, Rachel Blum wrote: > Unless there's a demonstrable reason that you _need_ a value uninitialized, > why is the burden of proof on the person doing cleanup? Yes, at the point > the code was written, it's well possible that the author was aware that the > value would

Re: [webkit-dev] Eliminate potential null pointer dereference?

On Apr 20, 2012, at 1:48 PM, Rachel Blum wrote: > 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 he

Re: [webkit-dev] Eliminate potential null pointer dereference?

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

Re: [webkit-dev] Eliminate potential null pointer dereference?

> > 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 de

Re: [webkit-dev] Eliminate potential null pointer dereference?

> > 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 de

Re: [webkit-dev] Eliminate potential null pointer dereference?

> 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 st

Re: [webkit-dev] Eliminate potential null pointer dereference?

On Apr 20, 2012, at 12:05 PM, Kentaro Hara wrote: > +1 to the idea that we should try to add a test for each change. That > being said, as rniwa mentioned, it is sometimes difficult to make a > test because > > (A) we do not come up with a test case > (B) we know that the code is unreachable (e.

Re: [webkit-dev] Eliminate potential null pointer dereference?

Hi Luke, I feel like you've been put on the defensive a bit here, which is unfortunate. I do agree with the value of readable code and "hackability" is one of the core values of the WebKit project. Code should indeed be meaningful to programmers. One thing to keep in mind though is that, by th

Re: [webkit-dev] Eliminate potential null pointer dereference?

On Fri, Apr 20, 2012 at 1:39 PM, Maciej Stachowiak wrote: > > On Apr 19, 2012, at 11:11 PM, David Levin wrote: > > I think this all started with a lot of effort put into fixing an issue > reported by a user where they said "the most popular online forum in > Malaysia is broken." Then folks had to

Re: [webkit-dev] Eliminate potential null pointer dereference?

On Apr 19, 2012, at 11:11 PM, David Levin wrote: > I think this all started with a lot of effort put into fixing an issue > reported by a user where they said "the most popular online forum in Malaysia > is broken." Then folks had to do a lot of builds (bisecting) to track down > where the pro

Re: [webkit-dev] How can I get some debug infomation in MediaPlayerPrivateGStreamer.cpp

On Fri, 2012-04-20 at 10:42 +0800, ZiQiangHuan wrote: > hi， > > I build webkit with gstreamer support, but I encountered a problem > when I test with it. When I write a simple statement "printf("* > \n")" in the function isAvailable() of > MediaPlayerPrivateGStreamer.cpp, I got nothing output

Re: [webkit-dev] Eliminate potential null pointer dereference?

On Fri, Apr 20, 2012 at 3:06 PM, Filip Pizlo wrote: > Someone in this thread said something about code readability. So let's > consider that. If I see code like: > > if (!var) thingy(); > > Then I will be under the impression that var might sometimes be zero and > that thingy() might sometimes hap

Re: [webkit-dev] Eliminate potential null pointer dereference?

On Apr 20, 2012, at 11:40 AM, Benjamin Poulain wrote: > On Fri, Apr 20, 2012 at 10:53 AM, Luke Macpherson > wrote: >> What do we hope to achieve by adding a test when fixing a bug? To >> prevent a bug from being reintroduced into the codebase at a later >> date. This is a reasonable goal, so le

Re: [webkit-dev] Eliminate potential null pointer dereference?

+1 to the idea that we should try to add a test for each change. That being said, as rniwa mentioned, it is sometimes difficult to make a test because (A) we do not come up with a test case (B) we know that the code is unreachable (e.g. https://bugs.webkit.org/show_bug.cgi?id=84377) What is the c

Re: [webkit-dev] Eliminate potential null pointer dereference?

On Fri, Apr 20, 2012 at 10:53 AM, Luke Macpherson wrote: > What do we hope to achieve by adding a test when fixing a bug? To > prevent a bug from being reintroduced into the codebase at a later > date. This is a reasonable goal, so let’s remember that the goal is to > prevent the bug from recurrin

Re: [webkit-dev] Eliminate potential null pointer dereference?

On Fri, Apr 20, 2012 at 11:07 AM, Ryosuke Niwa wrote: > Is the code reachable? It's quite possible that the code is unreachable and > therefore there is no way to hit that crash. Without a test, we can't answer > that question. That is not rationally true. A test case can show that there is a cod

Re: [webkit-dev] Eliminate potential null pointer dereference?

On Fri, Apr 20, 2012 at 10:53 AM, Luke Macpherson wrote: > > Tests are a good thing, but they are not the only thing. Consider the > state-space of a large piece of software like webkit - it is > essentially infinite. You can’t test every case and code path to > ensure correctness. While I do und

Re: [webkit-dev] Eliminate potential null pointer dereference?

Changing the two loops to use the same form improves readability because it makes it clear that the form of iteration is the same between the two loops. This is a very common C pattern when dealing with lists where the behavior changes after an element is encountered. The pattern is used instead of

Re: [webkit-dev] Where to call Codeblock::dump from within webcore

On Wed 18 Apr 2012 21:28, pgsery writes: > I want to call CodeBlock::dump from webcore in addition to the jsc > shell. I've compiled webkit-1.6.1 with the --enable-debug option, > modified dump to print to a file, instead of stdout, and set > options.dump=true. This works from the shell, but now