On 2/1/2017 12:38 PM, Richard Delorme wrote:
Right, if defined in another file, the compiler will not emit any warning.
However other tools can detect this kind of error. For instance, valgrind works
great in this example, directly on the executable:
$ valgrind --track-origins=yes mymemcpy
[...]
==31041== Conditional jump or move depends on uninitialised value(s)
==31041== at 0x4E843C7: vfprintf (in /usr/lib64/libc-2.23.so)
==31041== by 0x4E8B9A8: printf (in /usr/lib64/libc-2.23.so)
==31041== by 0x400682: main (main.c:15)
==31041== Uninitialised value was created by a stack allocation
==31041== at 0x400652: main (main.c:13)
[...]
Thus, I still have a mitigated feeling on attributes. In my humble opinion, it
is wrong to put on the programmer the responsibility to make his program safer
by stacking attributes on function declarations. I prefer to ask the compiler to
detect as much defects as possible (but not more!), and to rely on external
tools like valgrind, gdb, etc. to detect more subtle bugs.
You're right that valgrind can detect these sorts of things, and valgrind is
such an amazing tool I suspect that it has almost single handedly saved C from
oblivion.
That said, there are limitations:
1. Valgrind does not detect errors if it isn't run, and not many people run it
regularly.
2. Valgrind does not detect errors unless the error actually happens in the
running code. This means you'll need a test suite with 100% coverage for
valgrind to find all the errors.
3. The prevalence of memory safety errors in shipped code shows that valgrind is
not being used enough nor is effective enough.
4. Valgrind slows down the execution of code by an order of magnitude or two.
This makes it impractical for many applications, and impossible to instrument
code being run by the user. (It isn't run by the D autotester, for example.)
5. Bugs caught at compile time are far, far cheaper to fix than those caught by
the test suite. This is well documented.
6. Valgrind isn't available on all platforms, like Windows, embedded systems,
phones (?), etc.
7. There is value in having a guarantee that code doesn't suffer from certain
kinds of bugs. Valgrind cannot offer such a guarantee.
It's much like the dynamic typing vs static typing debate. Do you prefer finding
problems at run time or compile time?
And lastly, D does not require you to use these annotations.
