anchor.diff:  }
   ---------------------
   
  -In this example you can clearly see what difference the BDD-ish style
  -makes when it comes to naming. Convention, and natural language,
  -dictates that typical names for what TDD would call tests, now starts
  -with 'can' or 'finds' or other verbs, which makes the specification so
  -much easier to read.
  -
  -Yes, I wrote 'specification'. Because that is how BDD views what TDD
  -basically calls a test suite. The suite specifies the behaviour of a
  -`class´. (That's why some BDD frameworks draw on 'spec', like
  -*RSpec*.)
  +In this example you can clearly see what difference the BDD-ish style makes when it comes to naming.
  +Convention, and natural language, dictates that typical names for what TDD would call tests, now starts with 'can' or 'finds' or other verbs, which makes the specification so much easier to read.
  +
  +Yes, I wrote 'specification'. Because that is how BDD views what TDD basically calls a test suite. The suite specifies the behaviour of a `class´.
  +(That's why some BDD frameworks draw on 'spec', like *RSpec*.)
   
   
   === Contexts and Before and After
   
  -The complete specification of the behaviour of a SUT might become long
  -and require various forms of setup. When using TDD style you
  -would probably break this up into multiple suites having their own
  -`setup()` and `teardown()`.
  -
  -With BDD-ish style we could consider a suite as a behaviour
  -specification for our SUT 'in a particular context'. E.g.
  +The complete specification of the behaviour of a SUT might become long and require various forms of setup.
  +When using TDD style you would probably break this up into multiple suites having their own `setup()` and `teardown()`.
  +
  +With BDD-ish style we could consider a suite as a behaviour specification for our SUT 'in a particular context'.
  +E.g.
   
   [source, c]
   ------------------------
  
positive.code: include::tutorial_src/crash_tests1.c[lines=8..11]
  -----------------------------
  
  Crashes are not something you would normally want to have in a test
  run. Not least because it will stop you receiving the very test output
  you need to tackle the problem.
  
  To prevent segmentation faults and other problems bringing down the
  test suites, *Cgreen* runs every test in its own process.
  
  Just before calling the `BeforeEach()` (or `setup`) function, *Cgreen*
  `fork()`:s. The main process waits for the test to complete normally
  or die. This includes calling the `AfterEach()`(or `teardown`)
  function, if any. If the test process dies, an exception is reported
  and the main test process carries on with the next test.
  
  For example...
  
  
negative.code: `double`, it will have to be used as `box_double(d)` in the call to
  `mock()`.
  <2> The corresponding `expect()` uses a double constraint.
  <3> The mock function in this small example also returns a `double`.
  The `expect()` uses `will_return_double()` so the mock function needs to unbox the return value from `mock()` to be able to return the `double` type value.
  
  NOTE: Strange errors may occur if you box and/or unbox or combine `double` constraints incorrectly.
  
  [[floating_point_comparison_algorithm]]
  ==== Details of floating point comparison algorithm
  
  The number of significant digits set with `significant_figures_for_assert_double_are()` specifies a _relative_ tolerance.
  Cgreen considers two double precision numbers +x+ and +y+ equal if their difference normalized by the larger of the two is smaller than +10^(1 - significant_figures)^+.
  Mathematically, we check that +|x - y| < max(|x|, |y|) * 10^(1 - significant_figures)^+.
  
  Well documented subtleties arise when comparing floating point numbers close to zero using this algorithm.
  The article https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/[Comparing Floating Point Numbers, 2012 Edition] by Bruce Dawson has an excellent discussion of the issue.
  The essence of the problem can be appreciated if we consider the special case where +y == 0+.
  In that case, our condition reduces to +|x| < |x| * 10^(1 - significant_figures)^+.
  After cancelling +|x|+ this simplifies to +1 < 10^(1 - significant_figures)^+.
  But this is only true if +significant_figures < 1+.
  In words this can be summarized by saying that, in a relative sense, _all_ numbers are very different from zero.
  To circumvent this difficulty we recommend to use a constraint of the following form when comparing numbers close to zero:
  
  [source,c]
  -----------------------
  