Replace EXPECT_EQ(NULL, foo) with EXPECT_TRUE(NULL == foo)....

Replace EXPECT_EQ(NULL, foo) with EXPECT_TRUE(foo == NULL).

Using NULL as an argument to EXPECT_EQ or ASSERT_EQ is problematic,
because it passes NULL to a template function expecting a const int &,
which can trigger a NULL used as int warning.

An alternative would be EXPECT_FALSE(foo), but some people find that
confusing.
Another alternative would be to make EXPECT_NULL and EXPECT_NOT_NULL
which take templated T*.

Ran tests on Linux.  Passed except for ConditionVariableTest.LargeFastTaskTest,
which also fails without patch.

BUG=none
TEST=app_unittests & base_unittests & media_unittests

[Jacob Mandelson, 2009-09-11 04:45:51]

(Split off from CL 171028)

[Paweł Hajdan Jr., 2009-09-11 15:44:40]

http://codereview.chromium.org/202057/diff/1/6
File net/socket/client_socket_pool_base_unittest.cc (right):

http://codereview.chromium.org/202057/diff/1/6#newcode344
Line 344: EXPECT_FALSE(socket.get() == NULL);
Hmm... IMHO EXPECT_TRUE(... != NULL) is more intuitive.

[Peter Kasting, 2009-09-11 15:54:16]

The idea here is OK, but we don't use "const == var" style in Chromium code, so
please change these to "foo == NULL".

LGTM with that.

[Jacob Mandelson, 2009-09-26 21:50:09]

> Line 344: EXPECT_FALSE(socket.get() == NULL);
> Hmm... IMHO EXPECT_TRUE(... != NULL) is more intuitive.

Everyone seems to have different aesthetics around this.  I've reworked this
from a conditional to directly comparing predicates.

> The idea here is OK, but we don't use "const == var" style in Chromium code,
so
> please change these to "foo == NULL".

Done.

[Peter Kasting, 2009-09-28 01:19:37]

Already said LGTM, you need to tell us if you want someone to commit this for
you.

[Jacob Mandelson, 2009-09-28 21:33:31]

On 2009/09/28 01:19:37, Peter Kasting wrote:
> Already said LGTM, you need to tell us if you want someone to commit this for
> you.

Yes, I'll need a committer to land it.

[Peter Kasting, 2009-09-29 18:13:18]

Landed in r27511.

[wtc, 2009-10-02 23:59:32]

http://codereview.chromium.org/202057/diff/9009/8010
File net/http/http_network_transaction_unittest.cc (right):

http://codereview.chromium.org/202057/diff/9009/8010#newcode1
Line 1: // Copyright (c) 2009 The Chromium Authors. All rights reserved.
I thought we should change
  2006-2008
to
  2006-2009

Is it a new policy to change it to just 2009?

[Peter Kasting, 2009-10-03 00:00:56]

On 2009/10/02 23:59:32, wtc wrote:
> http://codereview.chromium.org/202057/diff/9009/8010#newcode1
> Line 1: // Copyright (c) 2009 The Chromium Authors. All rights reserved.
> I thought we should change
>   2006-2008
> to
>   2006-2009
> 
> Is it a new policy to change it to just 2009?

No, it has always been the policy to just change to 2009, per email from
Rebecca.

[wtc, 2009-10-03 00:14:04]

On 2009/10/03 00:00:56, Peter Kasting wrote:
>
> No, it has always been the policy to just change to 2009, per email from
> Rebecca.

Our coding style guide still uses 2006-2009 as an example:
http://dev.chromium.org/developers/coding-style#TOC-File-headers

Can we have a lawyer update that page authoritatively?

[Peter Kasting, 2009-10-03 16:38:12]

On Fri, Oct 2, 2009 at 5:14 PM, <wtc@chromium.org> wrote:

> Our coding style guide still uses 2006-2009 as an example:
> http://dev.chromium.org/developers/coding-style#TOC-File-headers
>
> Can we have a lawyer update that page authoritatively?


I updated it. I forwarded you the original email from Rebecca that addresses
this question, so you wouldn't have to worry about whether it was justified
:)

http://codereview.chromium.org/202057
>