It doesn't look like this is an actual bug, as the surrounding restricts the length of the input and checks the range:

  if (line.length() >= 3) {
    if (base::StringToInt(base::StringPiece(line.begin(), line.begin() + 3),
                          &result.status_code))
      result.has_status_code = (100 <= result.status_code &&
                                result.status_code <= 599);


So although StringToInt() will negative numbers, and numbers with a leading +, "has_status_code" will be correctly updated.

That said this code organization could be improved, but that would be a refactor not a bugfix.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/68da9c5135bad8ed4ed40cb95133d2c313e164a7

commit 68da9c5135bad8ed4ed40cb95133d2c313e164a7
Author: eroman <eroman@chromium.org>
Date: Mon Apr 11 21:36:22 2016

Refactor FtpCtrlResponseBuffer::ParseLine to use net::ParseInt32() rather than base::StringToInt().

I don't believe this fixes any actual bug, since the caller is restricting input length and checking output range.

It should make it easier to reason about though, since the status_code field is now left as kInvalidStatusCode on failure, whereas before StringToInt() may have modified it.

BUG= 596546 

Review URL: https://codereview.chromium.org/1875203002

Cr-Commit-Position: refs/heads/master@{#386479}

[modify] https://crrev.com/68da9c5135bad8ed4ed40cb95133d2c313e164a7/net/ftp/ftp_ctrl_response_buffer.cc