3 ms·

Can the D compiler prove things about the code? I didn't know. How does this work?

WalterBright 4y ago
For one thing, it won't let you take the address of a local variable and return it, or store it in a global, or throw it as an exception, or any other way for it to survive the stack frame. It won't let you "sanitize" it by passing it through a wrapper function, either. (This is all in functions annotated with `@safe`.) Try it and see for yourself. There's a long list of things like this D does. For another example, it won't allow reading from uninitialized variables. It will check your printf/scanf format string against the arguments. (This last one was a big win.)
- ryao 4y ago
  > It will check your printf/scanf format string against the arguments. (This last one was a big win.) Clang and GCC are able to do this on C/C++ code via the format function attribute: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute... I agree about it being a big win. I have been dragging my feet on retrofitting the OpenZFS source code to use it since I have just not had much time to revise my pull request doing it after code review asked me to use `(u_longlong_t)` instead of PRId64 and friends and the initial attempt to retrofit the OpenZFS codebase using it did not find anything I considered to be a real bug. That might be because a number of real bugs in this area had already been identified and fixed thanks to static analyzers. That said, there is this annoying oscillation that both GCC and Clang have where they complain that my type is long long and I should use %lld when I use %ld for uint64_t, only to complain that my type is long and I should use %ld when I use %lld for uint64_t. Using `PRId64` from stdint.h weirdly suppresses that behavior. Using a typecast to `(u_longlong_t)` also suppresses it.
  - ryao 4y ago
    Just a brief erratum report since it is too late to edit my previous comment to correct the mistake, I meant to write PRIu64 for my example. Writing PRId64 was a typo.
  - WalterBright 4y ago
    I know about the function attributes. But those are extensions, not part of the language, and hence unreliable. The core language needs to be fixed. Think of all the stupid problems arising in C from `long` not having a defined size. I can't believe all the time I've lost dealing with that. In D, a `long` is 64 bits. Period. Problems just vanish into the ether.

For one thing, it won't let you take the address of a local variable and return it, or store it in a global, or throw it as an exception, or any other way for it to survive the stack frame. It won't let you "sanitize" it by passing it through a wrapper function, either. (This is all in functions annotated with `@safe`.) Try it and see for yourself. There's a long list of things like this D does. For another example, it won't allow reading from uninitialized variables. It will check your printf/scanf format string against the arguments. (This last one was a big win.)

ryao 4y ago
> It will check your printf/scanf format string against the arguments. (This last one was a big win.) Clang and GCC are able to do this on C/C++ code via the format function attribute: https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attribute... I agree about it being a big win. I have been dragging my feet on retrofitting the OpenZFS source code to use it since I have just not had much time to revise my pull request doing it after code review asked me to use `(u_longlong_t)` instead of PRId64 and friends and the initial attempt to retrofit the OpenZFS codebase using it did not find anything I considered to be a real bug. That might be because a number of real bugs in this area had already been identified and fixed thanks to static analyzers. That said, there is this annoying oscillation that both GCC and Clang have where they complain that my type is long long and I should use %lld when I use %ld for uint64_t, only to complain that my type is long and I should use %ld when I use %lld for uint64_t. Using `PRId64` from stdint.h weirdly suppresses that behavior. Using a typecast to `(u_longlong_t)` also suppresses it.
- ryao 4y ago
  Just a brief erratum report since it is too late to edit my previous comment to correct the mistake, I meant to write PRIu64 for my example. Writing PRId64 was a typo.
- WalterBright 4y ago
  I know about the function attributes. But those are extensions, not part of the language, and hence unreliable. The core language needs to be fixed. Think of all the stupid problems arising in C from `long` not having a defined size. I can't believe all the time I've lost dealing with that. In D, a `long` is 64 bits. Period. Problems just vanish into the ether.