Using Design by Contract in C
Subject:   Why not GNU nana?
Date:   2004-11-01 12:31:24
From:   notchewie

I know that the wheel often is reinvented because it might not be known that the wheel already exists. This may be the case here. The project GNU nana addresses this coding style for C.

A quote from the GNU nana site: ``This style (Design by Contract) of analysis avoids a classic dilemma of analysis and specification: either you use a programming notation and run the risk of making premature implementation commitments; or you stick with a higher level notation (``bubbles and arrows'') and you must remain vague, forsaking one of the major benefits of the analysis process, the ability to state and clarify delicate properties of the system'' - ISE Inc.

The introduction in the nana manual best explains its features: Nana is a library that provides support for assertion checking and
logging in a space and time efficient manner. The aim is to put common good practice(1) into a library that can be reused rather than writing
this stuff every time you begin a new project.

In addition assertion checking and logging code can be implemented using a debugger rather than as inline code with a large saving in code space.

Full Threads Newest First

Showing messages 1 through 1 of 1.

  • Why not GNU nana?
    2004-11-02 07:13:19  cmills [View]

    I did take a look at GNU Nana last spring. I am definately guilty of reinventing the wheel to some degree, but here are the reasons I chose to do so:
    * By creating a preprocessor I could gather information about the types of function arguments and use that info to make writing the contracts simpler.
    * Having your contacts in comments allows you to compile your code normally.
    * Also I like having contracts seperated from the function definition.
    * I like the readability of OCL.
    * Doxygen integration was very important. This would be possible using Nana, but since (IMHO) the DBC for C contracts have good readability, they provide good documentation.
    * Postconditions (using @pre) and invariants require a little more work in Nana than in DBC for C.
    * Nana requires GCC extensions for some features.
    * Some of Nana's features require C++.

    That said Nana is a great library and many people may find it a more apropriate solution than DBC for C. Nana is probably more space efficient and faster than DBC for C (although I haven't tested this). DBC for C could use Nana to get some of that speed. At the very least if you are using DBC for C and are worried about code size you can define your dbc_error() macro to asm("hlt") (like Nana does) or abort() and ignore the error message.

    For those interested in DBC for C I am releasing a new version today. I got a lot of great feed back from people over the weekend and some bug reports too. :) Many thanks to Marc Verwerft for his bug reports.

    Information about and the lastest version of DBC for C can be found here: