It would appear that Mac OS X's copy of string.h is invalid.
It declares strcpy as
char *strcpy(char *, const char *);
But the C standard declares it as
char *strcpy(char * restrict, const char * restrict);
These two types are actually incompatible with each other according to the C standard, and a function that is declared  more than once in different translation units with different declarations is considered undefined behavior. Thus, any correctly conforming C library will cause any code that includes string.h to be undefined.
Oops!
Interesting. What would be the correct way to fix this here?
The restrict keyword should be added to OS X's string.h.
You should report this to the OS X developers then and have them modify their code.
Interesting find, but... how meaningful is it really? As you say, "any correctly conforming C library will cause any code that includes string.h to be undefined". But if the C library included with OS X is coherent with the .h file (and thus not strictly conforming to the standard), then no Undefined Behavior should appear.
The consequence is that if I write code on OSX that assumes that the C library is not restrict-qualifying these types, that code may not port to other platforms, and may lead to extremely subtle bugs that are not visible at the source level because the arise from the way in which the C compiler is optimizing aliasing restrictions.
Good point.
Really, it was high time some tools like RV's appeared.