Hacker News Reader

Comment by ghotli | Hacker News Reader

Invariant vs unit tests aside. Doesn't this being a gcc plugin make it inherently unattractive? Wouldn't want to have to rip that code out if I wanted the code to behave on a non-gcc toolchain.

Otherwise, seems cool if that doesn't matter / will never matter in the lifetime of the codebase

View on HN

  > Doesn't this being a gcc plugin make it inherently unattractive?

I'm the author, and even I think so. I'm more of an LLVM fan myself (though I can't not mention David Malcom's work on the GCC Static Analyzer).

(Ideally it wouldn't be a plugin at all, it'd be a language feature. We got Contracts and left out the most useful contract of them all)

Originally, I started it as a Clang plugin, thinking that I could also implement support for the Contracts "[[pre]]" and "[[post]]" specification on top (or at least some minimal implementation of it).

This turned out to be a lot more work.

If people would like to use this from Clang, even without support for regular Contracts, I will publish a compatible Clang plugin.

I think at some point there was support for Contracts in Clang, maybe longer term I'll try to get them working again? (I've no experience here)

https://github.com/arcosuc3m/clang-contracts

This fellow wrote a whole ~200 page thesis on this just as recently as 2018, such a shame for it to go to waste =/

https://e-archivo.uc3m.es/bitstream/handle/10016/29231/TFG_J...

> Wouldn't want to have to rip that code out if I wanted the code to behave on a non-gcc toolchain.

I can only imagine some companies would literally never have the problem of switching to a new compiler toolchain.

That is a concern, but this makes invariants something the compiler can reason about more easily, since they happen at function boundaries and are distinct from regular code, unlike “vanilla” assertions.

> Wouldn't want to have to rip that code out if I wanted the code to behave on a non-gcc toolchain.

I wonder if it can be wrapped in #ifdef ?

Better to define a macro that evaluates to the contract/invariants on GCC and empty on other compilers, rather than copying the ifdef/else/endif logic around to every usage.

Yeah sure, there's nothing preventing you from using "constexpr" so it's compile-time evaluated and inlined:

(Please no more macros, it's 202- I mean, 2023!)

  static constexpr bool DEBUG = true;

  [[demo::invariant]] [[gnu::used]]
  void check_invariants()
  {
    if constexpr (!DEBUG) return;

    assert(top >= 0 && top <= MAX_SIZE);
  }

Note that `assert`s are disabled if you define the macro `NDEBUG`, e.g. https://godbolt.org/z/hMWo8KM7q

CMake defines the macro in release builds: https://github.com/Kitware/CMake/blob/e1eacbe2c522a8bf9a82af...

Would be nice to have a non-macro solution for controlling behavior at configure time, but the `NDEBUG` macro is basically already your `DEBUG` constexpr.

It's a reasonable concern, but you could wrap it in macros that selectively enable it only on GCC.

Reply on news.ycombinator.com