assert

[Giuseppe]

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)?

 

[Zoran Cutura]

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.

 

[Gordon Burditt]

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

 

[Derk Gwen]

(e-mail address removed) (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.

 

[Nick Keighley]

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).

 

[Malcolm]

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.

 

[E. Robert Tisdale]

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.

 

[Richard Heathfield]

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]

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]

(e-mail address removed) (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.

 

[Dan Pop]

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

 

[Eric Sosman]

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.

 

[Giuseppe]

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 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

 

[Malcolm]

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]

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);

 

[Richard Heathfield]

Eric Sosman wrote:

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.

 

[Gordon Burditt]

The purpose of a tool is determined by the person using it. It is

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

 

[Richard Heathfield]

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.

 

[E. Robert Tisdale]

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)

 

[Emmanuel Delahaye]

you want to compile with NODEBUG defined, so that all assertions will be
gone.

ITYM 'NDEBUG'