Mac OS X上的Valgrind错误对于printf来说是双倍的
目前，我正在学习C语言，这是一个很棒的学习代码 。 我遇到了以下情况：
我编译以下代码，一切对我来说都很好：
#include int main(int argc, char *argv[]) { int bugs = 100; double bug_rate = 1.2; printf("You have %d bugs a the imaginary rate of %f!\n", bugs, bug_rate); return 0; } 它也正常工作。
当我现在运行Valgrind（3.11.0; 应该更新为OS X El Capitan ）时，我得到以下消息：
==18896== Memcheck, a memory error detector ==18896== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==18896== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info ==18896== Command: ./ex7 ==18896== You have 100 bugs a the imaginary rate of 1.200000! ==18896== ==18896== HEAP SUMMARY: ==18896== in use at exit: 26,081 bytes in 188 blocks ==18896== total heap usage: 272 allocs, 84 frees, 32,321 bytes allocated ==18896== ==18896== 148 (80 direct, 68 indirect) bytes in 1 blocks are definitely lost in loss record 42 of 65 ==18896== at 0x100007EA1: malloc (vg_replace_malloc.c:303) ==18896== by 0x1001C58D6: __Balloc_D2A (in /usr/lib/system/libsystem_c.dylib) ==18896== by 0x1001C621F: __d2b_D2A (in /usr/lib/system/libsystem_c.dylib) ==18896== by 0x1001C2877: __dtoa (in /usr/lib/system/libsystem_c.dylib) ==18896== by 0x1001EB3E6: __vfprintf (in /usr/lib/system/libsystem_c.dylib) ==18896== by 0x1002146C8: __v2printf (in /usr/lib/system/libsystem_c.dylib) ==18896== by 0x1001EA389: vfprintf_l (in /usr/lib/system/libsystem_c.dylib) ==18896== by 0x1001E8223: printf (in /usr/lib/system/libsystem_c.dylib) ==18896== by 0x100000F32: main (ex7.c:10) ==18896== ==18896== 2,064 bytes in 1 blocks are possibly lost in loss record 59 of 65 ==18896== at 0x10000821C: malloc_zone_malloc (vg_replace_malloc.c:305) ==18896== by 0x1004F6EFD: _objc_copyClassNamesForImage (in /usr/lib/libobjc.A.dylib) ==18896== by 0x1004EA182: protocols() (in /usr/lib/libobjc.A.dylib) ==18896== by 0x1004EA093: readClass(objc_class*, bool, bool) (in /usr/lib/libobjc.A.dylib) ==18896== by 0x1004E7C13: gc_init (in /usr/lib/libobjc.A.dylib) ==18896== by 0x1004EF24E: objc_initializeClassPair_internal(objc_class*, char const*, objc_class*, objc_class*) (in /usr/lib/libobjc.A.dylib) ==18896== by 0x1004FC132: layout_string_create (in /usr/lib/libobjc.A.dylib) ==18896== by 0x1004EA83C: realizeClass(objc_class*) (in /usr/lib/libobjc.A.dylib) ==18896== by 0x1004EA300: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib) ==18896== by 0x1004EA2E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib) ==18896== by 0x1004EA2E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib) ==18896== by 0x1004EA2E9: copySwiftV1MangledName(char const*, bool) (in /usr/lib/libobjc.A.dylib) ==18896== ==18896== LEAK SUMMARY: ==18896== definitely lost: 80 bytes in 1 blocks ==18896== indirectly lost: 68 bytes in 2 blocks ==18896== possibly lost: 2,064 bytes in 1 blocks ==18896== still reachable: 0 bytes in 0 blocks ==18896== suppressed: 23,869 bytes in 184 blocks ==18896== ==18896== For counts of detected and suppressed errors, rerun with: -v ==18896== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 18 from 18)
我不明白。 我的台词没有错：10不是吗？
多谢。
不幸的是， printf使用的库并不总是以理想的方式运行。 Valgrind会注意到所有错误 – 例如，不仅是您所做的错误，而且是OSX上标准C库实现中的每个错误。
其中一些“错误”可能是实际的错误（这是非常罕见的），其他可能是库开发人员所采用的快捷方式，这对Valgrind来说可能看起来不完全正确。 一个这样的事情就是在程序退出时依靠操作系统来清除和释放所有剩余的内存 – 当在一个迂腐的世界中时，程序应该在退出之前释放所有内存。 然而，在DOS和AmigaOS的日子里，这已经停止了。
我并不是说这肯定是你在那个错误中看到的，但是你需要注意Valgrind所说的。
要在实践中使用Valgrind，您可能需要一个抑制文件，它会删除与系统库相关的错误消息。 这是一篇关于这个问题的近期（2015年1月） 博客文章，其正是因为在OSX上“学习C艰难的方式”。