pecl-php-uploadprogress | An extension to track progress of a file upload | File Upload library

The bug produced by that commit has absolutely nothing to do with the safety of strcpy (or lack thereof).

strcpy is not safe unless you have some way to ensure that the destination object is big enough to hold the source (including its NUL terminator). If you do that, then it is as safe as your checks are.

Other than the confusion with dereference operators, the methodology of the linked code is adequate. Measuring strlen of the source string and adding one is a sufficient method to determine the length required; malloc of this amount is a sufficient method for allocating this much space. To that extent, strcpy(malloc(strlen(src) + 1), src) is as safe as you're going to find in C (aside from the cheekiness of not testing the return code of malloc for NULL; in real production code, you should do that, or use a malloc wrapper like emalloc in the PHP source).

However, strdup(src) is much more concise and readable, and its conciseness makes typos less probable. Personally, I would recommend to always use strdup for such cases; if you are worried that your target platform doesn't contain an implementation, it's easy enough to shim.