chore(security): avoid use of strcpy

[Saadnajmi]

Internally, we use this library with React Native. We noticed that Xcode's static analysis would point out a potentially unsafe call to strcpy. We are doing a proper bound check, but to be safer, we could also use something like strncpy / strncpy_s / strlcpy / memcpy to handle this case. Of those, the latter felt the most portable, so I went with that.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Saadnajmi]

Signed the CLA

[sergiud]

Thanks for the PR.

Silencing the static analyzer by reimplementing strcpy is not meaningful. Given the bounds are checked I don't understand what the current changes actually fix.

[Saadnajmi]

Thanks for the PR.

Silencing the static analyzer by reimplementing strcpy is not meaningful. Given the bounds are checked I don't understand what the current changes actually fix.

Fair. I would have preferred to use something like 'strlcpy' which Xcode actually suggested, but I wasn't sure that would be portable enough, as I'm not sure what Google's C / C++ standards are. Would you have an idea?

[Saadnajmi]

@sergiud Would strlcpy work?
w.r.t what this actually fixes, it's mostly me not wanting to maintain a fork of glog / glog with a patch for this one line. I understand Xcode / clang is over-reporting here since the usage is actually sage, but 🤷‍♂️

[sergiud]

@Saadnajmi I suggest we test this in ng-log that supersedes glog which is being deprecated.

Please open a PR there.