Oh, I failed to notice this typo. Clang is just better than gcc in this.

Vladimír Čunát authored 8 years ago and Grigorii Demidov committed 8 years ago

At least for now.  It didn't compile.

first, and disable EDNS in a second round.  This adds some latency
(one more roundtrip), but it's safer to not drop EDNS0 on a first
failure.

At least for now.  It didn't compile.

Fixes #129.  CNAMEs could get broken before this commit.

The change of `cut->name` to `current_cut` should cause no real change,
but the meaning seems more cleaner this way.

layer/iterate: change the order of records in the answer when CNAME refers to the record that we already have

... at least until we implement (some of) them correctly.

At least until we implement them properly.

Split NDEBUG to NDEBUG (asserts) and NOVERBOSELOG (verbose logging); rename all related symbols to use VERBOSE instead of DEBUG

- The API and ABI for modules changes slightly (details below).
  KR_MODULE_API is bumped to avoid loading incompatible code.
  We have bumped libkres ABIVER since the last release 1.1.1,
  so leaving that one intact.

- Make KR_STATE_YIELD not reuse 0 value anymore.
  It's easy to e.g. return kr_ok() by mistake.
- struct kr_layer_t:
  * ::mm was unused, uninitialized, etc.
  * Make ::state an int, as it was everywhere else.
  * void *data was ugly and always containing struct kr_request *
- struct kr_layer_api:
  * Drop the void* parameter from ::begin, as it was only used
    for the request which is available as ctx->req anyway
    (formerly ctx->data).
  * Drop ::fail.  It wasn't even called.  Modules can watch for
    KR_STATE_FAIL in ::finish.
- Document the apparent meaning of the layer interface, deduced mainly
  from the way it's used in the code.  Caveats:
  * enum knot_layer_state handling seems to assume that it holds exactly
    one of the possibilities at a time.  The cookie module does NOT
    follow that (intentionally), apparently depending on the exact
    implementation of the handling at that moment.  It feels fragile.
  * I was unable to deduce a plausible description of when ::reset is
    called.  It's practically unused in modules, too.

It causes lots of line changes, but it would be confusing to keep the
current state over long term.