memcpy() comparison: C, Rust, and D

[Walter Bright via Digitalmars-d]

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.