C++ strcpy, etc.
In making some minor modifications to the main simulation program, CEG-1.4.8, I encountered a compile error using gcc 4.3.2-7. The system is 64-bit AMD based, running Fedora 10. gcc was installed from the rpm package gcc-4.3.2-7.x86_64. The simple compile command g++ -o CEG-1.4.8-SMP CEG-1.4.8-SMP.cpp yielded the following output:
CEG-1.4.8-SMP.cpp: In function ‘int main(int, char**)’:
CEG-1.4.8-SMP.cpp:75: error: ‘strcpy’ was not declared in this scope
CEG-1.4.8-SMP.cpp:114: error: ‘strcpy’ was not declared in this scope
CEG-1.4.8-SMP.cpp:281: error: ‘strcpy’ was not declared in this scope
Given that these lines refer to fairly old parts of the code, and that compilation has been successful for years, I suspected that either there is a bug in this version of gcc, this latest RH update to its gcc package, or that my code is no longer legal. It seems to be the latter, and using strcpy is not really a good idea anyway. Here’s an example of the offending code (all uses referred to file reads from command line arguments or opening files for output):
//open existing matrix file specified by user
do
{
strcpy(matrix_name,argv[2]);
std::cout << "\nName of network matrix file: " << matrix_name;
matrix_file.open(matrix_name);
}
Note the use of strcpy in the fourth line. Simply replacing the routine worked. Here’s a correction:
//open existing matrix file specified by user
do
{
const char *matrix_name = argv[2];
std::cout << "\nName of network matrix file: " << matrix_name;
matrix_file.open(matrix_name);
}
There’s not much context to explain this compilation error. So, I’m gonna guess what happened: You included the header <cstring> which makes the functions visible under the std namespace. There’s no guarantee that the C functions will be visible in the global scope. In fact, the C++ standard says that if you incude a C++ version of a C header (<c___>) the global scope should not be polluted with names. What probably happened is that your new GCC version tries harder to conform to the standard. You can either include <string.h> instead (which introduces the functions in the global scope) or you can qualify strcpy properly (std::strcpy).
I hope you know what you’re doing. The use of strcpy here is both unnecessary and unsafe. It’s unnecessary because you don’t need to copy the string and it’s unsafe because your character buffer “matrix_name” might not be big enough to hold the name. This is a security hole (buffer overflow).
Thanks Pizer. I believe that you are correct about gcc trying harder to conform to the standard. But I’ve been using the code for several years, and it’s worked fine until now. std::strcpy did not improve the situation. I think that I do know what I’m doing,
, and I realize that the older kludge represented a security risk. But the new code (also posted), works fine and does not use strcpy. Buffer overflow because of file name length isn’t a problem; the program is for internal use by my research group only, and we have a file naming protocol.