Fix crash when an SSL key-log file couldn't be opened.

Fix crash when an SSL key-log file couldn't be opened.

BUG=none
TEST=`SSLKEYLOGFILE=/ ./out/Release/chrome` shouldn't crash.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=144495

[Ryan Sleevi, 2012-06-26 21:01:28]

LGTM

https://chromiumcodereview.appspot.com/10636062/diff/1/net/third_party/nss/ss...
File net/third_party/nss/ssl/sslsock.c (right):

https://chromiumcodereview.appspot.com/10636062/diff/1/net/third_party/nss/ss...
net/third_party/nss/ssl/sslsock.c:2938: perror("Failed open key log file");
nit: SSL_TRACE instead?

I don't feel strongly about this. I can understand why perror is useful (stderr
is a very visible user-surfacing of what we presume was a user intent to log to
a particular file), but I dislike library code writing to stderr (I can only
find four or five places in nss/lib that aren't guarded by #debugs)

[agl, 2012-06-27 17:28:30]

https://chromiumcodereview.appspot.com/10636062/diff/1/net/third_party/nss/ss...
File net/third_party/nss/ssl/sslsock.c (right):

https://chromiumcodereview.appspot.com/10636062/diff/1/net/third_party/nss/ss...
net/third_party/nss/ssl/sslsock.c:2938: perror("Failed open key log file");
On 2012/06/26 21:01:28, Ryan Sleevi wrote:
> nit: SSL_TRACE instead?
> 
> I don't feel strongly about this. I can understand why perror is useful
(stderr
> is a very visible user-surfacing of what we presume was a user intent to log
to
> a particular file), but I dislike library code writing to stderr (I can only
> find four or five places in nss/lib that aren't guarded by #debugs)

Fair enough. I fear that, most of the time, SSL_TRACE won't be defined to do
anything. But I agree that dumping to stderr isn't great so, done.

[commit-bot: I haz the power, 2012-06-27 17:32:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/agl@chromium.org/10636062/6001

[commit-bot: I haz the power, 2012-06-27 18:44:41]

Change committed as 144495