在写了成千上万行代码之后，我使用了valgrind，并且很惊讶地看到错误的数量。 之前只是使用GDB。 我的大部分错误都是使用string函数。 我发表了一部分。 我知道错误发生，因为strlen不计算结尾NULL，而strcpy添加它。 这有多严重？ 我真的需要修复它们吗？ 我可以解决它，但担心，如果这可能会导致更多的错误，因为我的代码并没有记住，当我作为wriitng它。
即使没有为它保留的空间，strcpy是否复制尾部NULL？
t.write_length = (strlen("NA\n");/*Line number 116*/ t.data = malloc(strlen("NA\n");/*117*/ strcpy(t.data,"NA\n");/*118*/ Valgrind的：
==3287== Invalid write of size 1 ==3287== at 0x400764E: memcpy (mc_replace_strmem.c:497) ==3287== by 0x804A714: log_txn_commit (Log_manager.c:118) ==3287== by 0x8049D3C: on_txn_commit (TxFS_manager.c:85) ==3287== by 0x804939E: handler (Reader.c:139) ==3287== by 0xBF5F18: start_thread (in /lib/libpthread-2.12.90.so) ==3287== by 0xB37A2D: clone (in /lib/libc-2.12.90.so) ==3287== Address 0x403282b is 0 bytes after a block of size 3 alloc'd ==3287== at 0x4005BDC: malloc (vg_replace_malloc.c:195) ==3287== by 0x804A6F5: log_txn_commit (Log_manager.c:117) ==3287== by 0x8049D3C: on_txn_commit (TxFS_manager.c:85) ==3287== by 0x804939E: handler (Reader.c:139) ==3287== by 0xBF5F18: start_thread (in /lib/libpthread-2.12.90.so) ==3287== by 0xB37A2D: clone (in /lib/libc-2.12.90.so)
这是一个严重的内存覆盖问题。 你的代码应该是
t.write_length = strlen("NA\n");/*Line number 116*/ t.data = malloc(t.write_length + 1); strcpy(t.data,"NA\n");
并需要确定。 strcpy()会追加没有空间的终止'\0' 。
为避免溢出，目标所指向的数组的大小应足够长以包含与源（包括终止空字符）相同的C字符串，并且不应与内存中的源重叠。
总是认真对待Valgrind的建议！
你总是想修复Valgrind报告的错误。 无效的写入会导致意外的行为，根据定义，这不是您的程序应该执行的操作。 根据你的程序在内存中的布局，你可能会覆盖其他重要的变量，或者没有完全写出你期望的内容。
如果解决这个问题会导致代码中出现更多的错误，这意味着代码的其他部分是错误的，而不是Valgrind的报告。 你应该修复这个错误，如果这会导致进一步的错误报告，你也修复这些错误。 自己的危险忽略无效的读/写错误。
是的，你总是需要malloc(strlen(str) + 1)个字节的字符串（对于那个讨厌的空终止符）。 或者更简单的方法是使用strdup 。
可能相当严重，你应该修复它。 如果您不需要结尾空值，请考虑使用strdup()如果您需要结尾空值或memcpy() 。