Remove unused errno parsing for leveldb status codes

Remove unused errno parsing for leveldb status codes

When file errors are encountered by the chromium "env" for leveldb,
we encode the failing method and the specific error code into the messages
returned to leveldb so that when leveldb in turn returns the error
to the caller (e.g. Indexed DB) we can update histograms and/or
or emit more specific errors (e.g. disk full vs. i/o error).

This mechanism used to encode either base::File::Error codes (platform
file error) or "errno" codes, depending on which filesystem API was
used. Now that we only use base::File we can drop support for parsing
the "errno" codes.

R=cmumford@chromium.org

Committed: https://crrev.com/ab87bce6b23bf1a0e88245959aac54f92a63f1e6
Cr-Commit-Position: refs/heads/master@{#317397}

[jsbell, 2015-02-19 19:56:51]

cmumford@ - please take a look?

https://codereview.chromium.org/936073003/diff/1/third_party/leveldatabase/en...
File third_party/leveldatabase/env_chromium_unittest.cc (right):

https://codereview.chromium.org/936073003/diff/1/third_party/leveldatabase/en...
third_party/leveldatabase/env_chromium_unittest.cc:34: base::File::Error error =
base::File::FILE_OK;
I thought about using base::File::FILE_ERROR_MAX here instead. Or I could
static_cast<>. Opinions?

[cmumford, 2015-02-20 19:21:24]

lgtm % nit. I don't feel that strong on FILE_ERROR_MAX vs. FILE_OK - your call.

https://codereview.chromium.org/936073003/diff/1/third_party/leveldatabase/en...
File third_party/leveldatabase/env_chromium_unittest.cc (right):

https://codereview.chromium.org/936073003/diff/1/third_party/leveldatabase/en...
third_party/leveldatabase/env_chromium_unittest.cc:34: base::File::Error error =
base::File::FILE_OK;
On 2015/02/19 19:56:51, jsbell wrote:
> I thought about using base::File::FILE_ERROR_MAX here instead. Or I could
> static_cast<>. Opinions?

I guess the original intent of -75 was to verify that the error value was
unchanged as method errors don't have a number. I'd probably use anything but
FILE_OK (0) and would probably go with FILE_ERROR_MAX.

[jsbell, 2015-02-20 20:03:41]

https://codereview.chromium.org/936073003/diff/1/third_party/leveldatabase/en...
File third_party/leveldatabase/env_chromium_unittest.cc (right):

https://codereview.chromium.org/936073003/diff/1/third_party/leveldatabase/en...
third_party/leveldatabase/env_chromium_unittest.cc:34: base::File::Error error =
base::File::FILE_OK;
On 2015/02/20 19:21:24, cmumford wrote:
> On 2015/02/19 19:56:51, jsbell wrote:
> > I thought about using base::File::FILE_ERROR_MAX here instead. Or I could
> > static_cast<>. Opinions?
> 
> I guess the original intent of -75 was to verify that the error value was
> unchanged as method errors don't have a number. I'd probably use anything but
> FILE_OK (0) and would probably go with FILE_ERROR_MAX.

Agreed. Given that we should never assign FILE_ERROR_MAX I'll go with that.

[jsbell, 2015-02-20 20:06:54]

New patchsets have been uploaded after l-g-t-m from cmumford@chromium.org

[jsbell, 2015-02-20 20:07:09]

The CQ bit was checked by jsbell@chromium.org

[commit-bot: I haz the power, 2015-02-20 20:07:44]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/936073003/20001

[commit-bot: I haz the power, 2015-02-20 20:59:10]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-02-20 20:59:41]

Patchset 2 (id:??) landed as
https://crrev.com/ab87bce6b23bf1a0e88245959aac54f92a63f1e6
Cr-Commit-Position: refs/heads/master@{#317397}