<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" xmlns:xi="http://www.w3.org/2003/XInclude" type="topic" id="preconditions" xml:lang="de">

  <info>

    <link type="guide" xref="index#specific-how-tos"/>

    <credit type="author copyright">

      <name>Philip Withnall</name>

      <email its:translate="no">philip.withnall@collabora.co.uk</email>

      <years>2015</years>

    </credit>

    <include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>

    <desc>Contract programming with checks on function input and output</desc>

    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">

      <mal:name>Mario Blättermann</mal:name>

      <mal:email>mario.blaettermann@gmail.com</mal:email>

      <mal:years>2016</mal:years>

    </mal:credit>

    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">

      <mal:name>Christian Kirbach</mal:name>

      <mal:email>christian.kirbach@gmail.com</mal:email>

      <mal:years>2016</mal:years>

    </mal:credit>

  </info>

  <title>Pre- and Post-Conditions</title>

  <section id="pre-and-post-conditions">

    <title>Pre- and Post-Conditions</title>

      An important part of secure coding is ensuring that incorrect data does

      not propagate far through code — the further some malicious input can

      propagate, the more code it sees, and the greater potential there is for

      an exploit to be possible.

      A standard way of preventing the propagation of invalid data is to check

      all inputs to, and outputs from, all publicly visible functions in a

      library or module. There are two levels of checking:

    <terms>

      <item>

        <title>Assertions</title>

        
Auf Programmierfehler prüfen und das Programm im Problemfall abbrechen lassen.

      </item>

      <item>

        <title>Überprüfung</title>

          Check for invalid input and return an error gracefully on failure.

      </item>

    </terms>

      Validation is a complex topic, and is handled using

      <link xref="gerror">GErrors</link>. The remainder of this section

      discusses pre- and post-condition assertions, which are purely for

      catching programmer errors. A programmer error is where a function is

      called in a way which is documented as disallowed. For example, if

      NULL is passed to a parameter which is documented as

      requiring a non-NULL value to be passed; or if a negative

      value is passed to a function which requires a positive value. Programmer

      errors can happen on output too — for example, returning NULL

      when it is not documented to, or not setting a GError output when it

      fails.

      Adding pre- and post-condition assertions to code is as much about

      ensuring the behavior of each function is correctly and completely

      documented as it is about adding the assertions themselves. All assertions

      should be documented, preferably by using the relevant

      <link xref="introspection">introspection annotations</link>, such as

      (nullable).

      Pre- and post-condition assertions are implemented using

      <link href="https://developer.gnome.org/glib/stable/glib-Warnings-and-Assertions.html#g-return-if-fail">g_return_if_fail()</link>

      and

      <link href="https://developer.gnome.org/glib/stable/glib-Warnings-and-Assertions.html#g-return-val-if-fail">g_return_val_if_fail()</link>.

      The pre-conditions should check each parameter at the start of the

      function, before any other code is executed (even retrieving the private

      data structure from a GObject, for example, since the GObject pointer

      could be NULL). The post-conditions should check the return

      value and any output parameters at the end of the function — this requires

      a single return statement and use of goto to

      merge other control paths into it. See

      <link xref="memory-management#single-path-cleanup"/> for an example.

  </section>

</page>