assert

Discussion in 'C Programming' started by Giuseppe, Jul 16, 2003.

  1. Giuseppe

    Giuseppe Guest

    is assert() for debug only or not?
    Is it possible that I have seen the use of assert() in the Borland
    c++ 32 compiler (so assert is not for debug only)?
     
    Giuseppe, Jul 16, 2003
    #1
    1. Advertising

  2. Giuseppe

    Zoran Cutura Guest

    Giuseppe <> wrote:
    > is assert() for debug only or not?


    Yes. Or let it state in another way. Assert should only be used while
    the code is in development, than when you release your product/program,
    you want to compile with NODEBUG defined, so that all assertions will be
    gone.

    > Is it possible that I have seen the use of assert() in the Borland
    > c++ 32 compiler (so assert is not for debug only)?


    It is possible, though one cannot conclude from that fact that this is
    the correct usage anyway. Borland seams to have released a debug-version
    or their product.

    --
    Z ()
    "LISP is worth learning for the profound enlightenment experience
    you will have when you finally get it; that experience will make you
    a better programmer for the rest of your days." -- Eric S. Raymond
     
    Zoran Cutura, Jul 16, 2003
    #2
    1. Advertising

  3. >is assert() for debug only or not?

    The purpose of a tool is determined by the person using it. It is
    possible that someone out there uses assert() for driving nails and
    uses pencils for murdering people.

    >Is it possible that I have seen the use of assert() in the Borland
    >c++ 32 compiler (so assert is not for debug only)?


    Is it possible that you have seen the source code of the Borland
    c++ 32 compiler? I don't know. If you have, whether or not it
    uses assert() says little about whether or not assert() is for debug
    only. Just because code is a production release does not mean it
    is bug-free. However, I'm not sure I'd be comfortable riding in
    an airplane or spacecraft whose flight-control software used assert(),
    or living near a nuclear reactor whose control software used it.

    Gordon L. Burditt
     
    Gordon Burditt, Jul 16, 2003
    #3
  4. Giuseppe

    Derk Gwen Guest

    w (Giuseppe) wrote:
    # is assert() for debug only or not?
    # Is it possible that I have seen the use of assert() in the Borland
    # c++ 32 compiler (so assert is not for debug only)?

    The most diffult to debug, to understand problems occur in once the code
    is in production, where it is constantly hammerred to its limits by people
    who have no respect for your test suite.

    Therefore in the interest of speed, production code is precisely when
    you need to disable all checking, assertions, array bounds and other
    ranges, stacks popped properly, etc. This ensures the maximum damage and
    the least possibility of fixing it.

    --
    Derk Gwen http://derkgwen.250free.com/html/index.html
    So....that would make Bethany part black?
     
    Derk Gwen, Jul 16, 2003
    #4
  5. w (Giuseppe) wrote in message news:<>...

    > is assert() for debug only or not?
    > Is it possible that I have seen the use of assert() in the Borland
    > c++ 32 compiler (so assert is not for debug only)?


    as you may have gathered there are some differences of
    opinion on this one. Try googling comp.lang.c for "assert".

    For instance I've posted some particularly good things on
    assert :)

    (google for my surname, you're unlikely to get false positives
    in comp.lang.c).


    --
    Nick Keighley
     
    Nick Keighley, Jul 16, 2003
    #5
  6. Giuseppe

    Malcolm Guest

    "Derk Gwen" <> wrote in message
    >
    > The most diffult to debug, to understand problems occur in once the code
    > is in production, where it is constantly hammerred to its limits by people
    > who have no respect for your test suite.
    >

    It depends what your product is. If you release a game, and it assert fails,
    a savvy player will know that there must be a design bug. However it is
    unlikely that your studio is set up to release patches and maintenance
    versions, so you end up in an awkward position.
    Far better to just crash.
     
    Malcolm, Jul 16, 2003
    #6
  7. Zoran Cutura wrote:

    > Giuseppe wrote:
    >
    >>Is assert() for debug only or not?

    >
    > Yes. Or let it state in another way.
    > Assert should only be used while the code is in development,
    > then when you release your product/program,
    > you want to compile with NODEBUG defined,
    > so that all assertions will be gone.


    For amateur programmers (programmers who write code for their own use),
    there is no clear distinction between
    the program development phase and the program deployment phase.
    They try to use their code with no formal testing
    as soon as they can get it to compile without any errors.
    They are always modifying and debugging their code
    until they are finished using it -- then they throw it away.
    For amateur programmers, it is usually sufficient
    to simply exit from a program when an exception is encountered.
    For professional programmers, it is almost always necessary
    to include code to detect and handle the exception for users
    because the users may not be programmers themselves.
    The C preprocessor assert macro is almost never
    the best way to detect and handle exceptions so it is not used
    for exception handling by professional programmers.
     
    E. Robert Tisdale, Jul 17, 2003
    #7
  8. Zoran Cutura wrote:

    > Giuseppe <> wrote:
    >> is assert() for debug only or not?

    >
    > Yes. Or let it state in another way. Assert should only be used while
    > the code is in development, than when you release your product/program,
    > you want to compile with NODEBUG defined, so that all assertions will be
    > gone.


    You meant: NDEBUG

    <snip>

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Jul 17, 2003
    #8
  9. Malcolm wrote:

    >
    > "Derk Gwen" <> wrote in message
    >>
    >> The most diffult to debug, to understand problems occur in once the code
    >> is in production, where it is constantly hammerred to its limits by
    >> people who have no respect for your test suite.
    >>

    > It depends what your product is. If you release a game, and it assert
    > fails, a savvy player will know that there must be a design bug. However
    > it is unlikely that your studio is set up to release patches and
    > maintenance versions, so you end up in an awkward position.
    > Far better to just crash.


    The "savvy player" whose game crashes will not be keen to buy games from the
    same company again.

    Far better not to do things that might make the game crash.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Jul 17, 2003
    #9
  10. Derk Gwen wrote:

    > w (Giuseppe) wrote:
    > # is assert() for debug only or not?
    > # Is it possible that I have seen the use of assert() in the Borland
    > # c++ 32 compiler (so assert is not for debug only)?
    >
    > The most diffult to debug, to understand problems occur in once the code
    > is in production, where it is constantly hammerred to its limits by people
    > who have no respect for your test suite.
    >
    > Therefore in the interest of speed, production code is precisely when
    > you need to disable all checking, assertions, array bounds and other
    > ranges, stacks popped properly, etc. This ensures the maximum damage and
    > the least possibility of fixing it.


    If you're not 100% sure that the program can run correctly without the
    assertions, your program is not ready for production.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Jul 17, 2003
    #10
  11. Giuseppe

    Dan Pop Guest

    In <bf5h7v$mbc$> Richard Heathfield <> writes:

    >If you're not 100% sure that the program can run correctly without the
    >assertions, your program is not ready for production.


    By this logic, complex programs, like compilers, would be *never*
    released.

    Real life constraints impose the release of programs that are not 100%
    bug-free, simply because it cannot be demonstrated that they are 100%
    bug-free with a reasonable amount of time and manpower resources.

    The question is what to do with such programs: mask the bugs, so that
    the user is not aware that he's getting the wrong results or expose them
    to the user (when they can be internally detected). gcc's ICEs
    (Internal Compiler Errors) are certainly the moral equivalent of asserts
    left activated in production code. And I've gotten once a plain assertion
    failure from the Digital Unix linker. In either case I was much happier
    than when I had to discover an unreported toolchain error myself.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Jul 17, 2003
    #11
  12. Giuseppe

    Eric Sosman Guest

    Richard Heathfield wrote:
    >
    > Derk Gwen wrote:
    >
    > > w (Giuseppe) wrote:
    > > # is assert() for debug only or not?
    > > # Is it possible that I have seen the use of assert() in the Borland
    > > # c++ 32 compiler (so assert is not for debug only)?
    > >
    > > The most diffult to debug, to understand problems occur in once the code
    > > is in production, where it is constantly hammerred to its limits by people
    > > who have no respect for your test suite.
    > >
    > > Therefore in the interest of speed, production code is precisely when
    > > you need to disable all checking, assertions, array bounds and other
    > > ranges, stacks popped properly, etc. This ensures the maximum damage and
    > > the least possibility of fixing it.

    >
    > If you're not 100% sure that the program can run correctly without the
    > assertions, your program is not ready for production.


    Corollary: No non-trivial program is ever ready for
    production.

    It seems to me that "ready for production" and "100%
    bug-free" are not equivalent notions. A program is ready
    for production when it is "good enough" for the application
    at hand. A program may be "good enough" without being
    "perfect" -- and certainly without satisfying the still
    stronger condition of "proven perfect."

    To put it another way: If unachievable perfection is the
    criterion, the program will never be put into production.
    The expected waiting time for the program to perform its
    function is therefore infinite, and the ultimate result
    (i.e., "nothing useful happens") can be achieved much more
    quickly and cheaply by writing a program that crashes as
    soon as it's invoked. In this sense, "100% bug-free" and
    "100% bug-ridden" are operationally equivalent ;-)

    Returning to the question of whether "production" code
    should be built with or without NDEBUG defined, I seem to
    recall PJ Plauger opining in "The Standard C Library" that
    the problem with assert() in production code isn't that it
    wastes cycles or some such, but that when it (inevitably)
    *does* catch a problem the error message is gibberish to
    the end user. It would seem to follow (although I don't
    recall whether Plauger said so explicitly) that production
    code should in fact test for its own correct operation, but
    should use some nicer mechanism than the developer-oriented
    bare assert().

    There's also the experience some years back of the little
    robot that landed on Mars, crawled around doing stuff, and
    kept mysteriously freezing up and rebooting. The problem (a
    classic priority inversion) was fixed only because the on-Mars
    software (a "production" deployment if I've ever heard of one!)
    still had its debugging probes activated; this facilitated
    Earth-side analysis and provided a vehicle for uploading what
    amounted to a patch. Looking back on the incident, a senior
    software person on the project gave it as a mantra: "Test what
    you fly, and fly what you test" -- in short, if you test the
    code with debug probes in place, pulling out the probes leaves
    you with a program that has seen *no* testing at all! Put the
    former, not the latter, into production.

    --
     
    Eric Sosman, Jul 17, 2003
    #12
  13. Giuseppe

    Giuseppe Guest

    On 16 2003, (Gordon Burditt) wrote:
    >>is assert() for debug only or not?

    >
    >The purpose of a tool is determined by the person using it. It is
    >possible that someone out there uses assert() for driving nails and
    >uses pencils for murdering people.
    >
    >>Is it possible that I have seen the use of assert() in the Borland
    >>c++ 32 compiler (so assert is not for debug only)?

    >
    >Is it possible that you have seen the source code of the Borland
    >c++ 32 compiler? I don't know. If you have, whether or not it
    >uses assert() says little about whether or not assert() is for debug
    >only. Just because code is a production release does not mean it
    >is bug-free. However, I'm not sure I'd be comfortable riding in
    >an airplane or spacecraft whose flight-control software used assert(),
    >or living near a nuclear reactor whose control software used it.


    living near a nuclear reactor is always not good
    and there are programs that can't fail
    but
    where is the problem with assert() or with escise()?

    #include <stdio.h>
    #include <stdlib.h>
    #define escise(a) fun(a, #a, __FILE__, __LINE__)

    void fun(int b, char* a, char* c, unsigned d)
    {if(b==0) return;
    fflush(stdout);
    if(!ferror(stderr))
    fprintf(stderr,
    "Esco per %s in file: %s linea:%u Ciao\n", a, c, d);
    fflush(stderr);
    abort(); /* Is the problem here? */
    }


    int main()
    {int *a=0;

    escise(a==0);
    printf("fuori uno\n");
    return 0;
    }

    Thanks
    _______
    Sistema maggioritario== DITTATURA
    Sistema proporzionale==democrazia
     
    Giuseppe, Jul 17, 2003
    #13
  14. Giuseppe

    Malcolm Guest

    "Eric Sosman" <> wrote in message
    >
    > It seems to me that "ready for production" and "100%
    > bug-free" are not equivalent notions. A program is ready
    > for production when it is "good enough" for the application
    > at hand.
    >

    How many people would spend ten times as much money on a car that was
    designed so that it never broke down?
     
    Malcolm, Jul 17, 2003
    #14
  15. Giuseppe

    Malcolm Guest

    "E. Robert Tisdale" <> wrote in message
    >
    > The C preprocessor assert macro is almost never
    > the best way to detect and handle exceptions so it is not used
    > for exception handling by professional programmers.
    >

    It is used to detect an error by the calling programmer.

    eg

    double squareroot(double x)
    {
    assert(x >= 0);
    ...
    }

    However not

    printf("Input number you want the square root of\n");
    scanf("%f\n", &x);
    assert(x >= 0);
     
    Malcolm, Jul 17, 2003
    #15
  16. Eric Sosman wrote:

    <snip>

    > Returning to the question of whether "production" code
    > should be built with or without NDEBUG defined, I seem to
    > recall PJ Plauger opining in "The Standard C Library" that
    > the problem with assert() in production code isn't that it
    > wastes cycles or some such, but that when it (inevitably)
    > *does* catch a problem the error message is gibberish to
    > the end user.


    That is indeed a serious problem.

    It would seem to follow (although I don't
    > recall whether Plauger said so explicitly) that production
    > code should in fact test for its own correct operation, but
    > should use some nicer mechanism than the developer-oriented
    > bare assert().


    And that brings you right back to the old trade-off between speed and
    "security".

    > There's also the experience some years back of the little
    > robot [...] Looking back on the incident, a senior
    > software person on the project gave it as a mantra: "Test what
    > you fly, and fly what you test" -- in short, if you test the
    > code with debug probes in place, pulling out the probes leaves
    > you with a program that has seen *no* testing at all! Put the
    > former, not the latter, into production.


    I have no problem with that idea, but I would recommend not using assert()
    in that situation. Rather, recover gracefully from the error if possible,
    and in any event provide meaningful information to the user. Assertions
    were not designed to do this.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Jul 17, 2003
    #16
  17. >>The purpose of a tool is determined by the person using it. It is
    >>possible that someone out there uses assert() for driving nails and
    >>uses pencils for murdering people.
    >>
    >>>Is it possible that I have seen the use of assert() in the Borland
    >>>c++ 32 compiler (so assert is not for debug only)?

    >>
    >>Is it possible that you have seen the source code of the Borland
    >>c++ 32 compiler? I don't know. If you have, whether or not it
    >>uses assert() says little about whether or not assert() is for debug
    >>only. Just because code is a production release does not mean it
    >>is bug-free. However, I'm not sure I'd be comfortable riding in
    >>an airplane or spacecraft whose flight-control software used assert(),
    >>or living near a nuclear reactor whose control software used it.

    >
    >living near a nuclear reactor is always not good


    That depends on how much it leaks and how well it is designed, and
    how close "near" is. I'd much rather live 50 miles from a reactor
    programmed to shut down in case of an emergency, with multiple
    fail-safes that it can do so, than live 500 miles from one that's
    going to shut down the control computer with the control rods still
    set for full-blast power generation if one of the sensors says
    something it doesn't like, and in all probability cause a core
    meltdown.

    >and there are programs that can't fail


    Really? I doubt that there is anything a program can run on
    that can't fail, and reality intrudes on ANSI C with things
    like the impossibility of guaranteeing that there will be no
    power failures or nuclear EMP while the program is running.

    >but
    >where is the problem with assert() or with escise()?


    Generally:

    The higher-level routines of the program don't have a chance
    to clean up (delete temporary files, finish half-written files, etc.)
    or actually try to RECOVER from the error.
    The error message generally has all the clarity of
    "Shut 'er down Scotty, she's sucking mud again" (to anyone recognizing
    that message: what did it REALLY mean?) especially to someone to
    whom you did not sell the source code but sold the binary. It
    generally does not report possibly-relevant info (for your function
    below, what WAS the value of b? It's not 0, but what was it? This
    might be relevant debugging info.)
    If the program is in the middle of doing something physical
    and important, say, flying an airplane, just halting tends to lead
    to catastrophic consequences.

    Gordon L. Burditt

    >#include <stdio.h>
    >#include <stdlib.h>
    >#define escise(a) fun(a, #a, __FILE__, __LINE__)
    >
    >void fun(int b, char* a, char* c, unsigned d)
    >{if(b==0) return;
    > fflush(stdout);
    > if(!ferror(stderr))
    > fprintf(stderr,
    > "Esco per %s in file: %s linea:%u Ciao\n", a, c, d);
    > fflush(stderr);
    > abort(); /* Is the problem here? */
    >}
    >
    >
    >int main()
    >{int *a=0;
    >
    > escise(a==0);
    > printf("fuori uno\n");
    > return 0;
    >}
    >
    >Thanks
     
    Gordon Burditt, Jul 17, 2003
    #17
  18. E. Robert Tisdale wrote:

    > The C preprocessor assert macro is almost never
    > the best way to detect and handle exceptions


    Of course not. That's like saying getchar() is almost never the best way to
    calculate the square root of a number. It's a self-evident truth of no
    intrinsic value.

    > so it is not used
    > for exception handling by professional programmers.


    Of course not. It's a program error detection facility, not an exception
    handler.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
     
    Richard Heathfield, Jul 17, 2003
    #18
  19. Giuseppe wrote:

    > Is assert() for debug only or not?


    ASSERT(3) Linux Programmer’s Manual ASSERT(3)

    NAME
    assert - abort the program if assertion is false

    SYNOPSIS
    #include <assert.h>

    void assert(scalar expression);

    DESCRIPTION
    If the macro NDEBUG was defined at the moment <assert.h> was last
    included, the macro assert() generates no code, and hence does
    nothing at all. Otherwise, the macro assert() prints an error
    message to standard output and terminates the program by calling
    abort() if expression is false (i.e., compares equal to zero).

    The purpose of this macro is to help the programmer find bugs in
    his program. The message "assertion failed in file foo.c,
    function do_bar(), line 1287" is of no help at all to a user.

    RETURN VALUE
    No value is returned.

    CONFORMING TO
    ISO9899 (ANSI C). In the 1990 standard, expression is required
    to be of type int and undefined behavior results if it is not,
    but in the 1999 standard it may have any scalar type.

    BUGS
    assert() is implemented as a macro; if the expression tested has
    side- effects, program behaviour will be different depending on
    whether NDEBUG is defined. This may create Heisenbugs which
    go away when debugging is turned on.

    SEE ALSO
    exit(3), abort(3), assert_perror(3)

    C99 2002-08-25 ASSERT(3)
     
    E. Robert Tisdale, Jul 18, 2003
    #19
  20. Emmanuel Delahaye, Jul 19, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Newby
    Replies:
    1
    Views:
    1,705
  2. Robert Brewer
    Replies:
    1
    Views:
    491
    bsmith
    Nov 7, 2004
  3. Thomas Guettler

    assert 0, "foo" vs. assert(0, "foo")

    Thomas Guettler, Feb 23, 2005, in forum: Python
    Replies:
    3
    Views:
    2,526
    Carl Banks
    Feb 23, 2005
  4. Alex Vinokur

    assert(x) and '#define ASSERT(x) assert(x)'

    Alex Vinokur, Nov 25, 2004, in forum: C Programming
    Replies:
    5
    Views:
    918
    Keith Thompson
    Nov 25, 2004
  5. ImpalerCore

    To assert or not to assert...

    ImpalerCore, Apr 27, 2010, in forum: C Programming
    Replies:
    79
    Views:
    1,671
    Richard Bos
    May 17, 2010
Loading...

Share This Page