Again,
premature optimization is the root of all evil (Hoare, Knuth). (Think I'll need to dump this in my sig sometime.) For all you know, the strlen() and strcpy() provided by your compiler libs might be implemented in pure optimized assembly, tuned to the last clock cycle by tens of developers with years of experience in assemblers and compiler design. For all you know they are written as seperate micro-functions to fit completely into your platform's pipeline cleanly so as not to require additional instruction fetches by the processor. For all you know...
First profile (to the millisecond) strcpy and strlen running 1,000,000 times each in adverse conditions, also profiling the kernel, cache, swap and other side-effect processes. Then repeat for various optimization levels of your compiler and for various target platforms. Then profile your entire application to see if the bottlenecks are in these functions. Then, and only then, do you go to the trouble of coding your own buggy, less-portable replacements.
How large? This large?
This large? This large? Can you be sure that the buffer is large enough? What if a user (including other processes and automated clients) enter a very large string for one of the fields?
Why not just use std::string, which is all fast, easy and safe? I think there are some fundemental doo-wizzahs about your overall code design.