Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > How does assert benefit your code really?

Reply
Thread Tools

How does assert benefit your code really?

 
 
Ian Collins
Guest
Posts: n/a
 
      04-11-2006
Stephen Sprunk wrote:
> "Manuel Tobias Schiller" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>> Sometimes, leaving in a few of those assert statements in the finished
>> product is a good idea as well because it will give a better indication
>> of where things fail in production builds (because of misuse of the
>> program, not buggy coding). I've seen this method being useful in the
>> printer driver I maintain (a driver to use a certain GDI printer under
>> *nix-like OS), so I thought sharing this "trick" with others (who might
>> not yet know it) might be a good idea.

>
>
> Robust code should have all kinds of error-checking built in so that if
> the impossible happens, it can be silently dealt with. Aborting a
> production build in customers' hands is rarely the correct answer.
>

Unfortunately, in embedded systems it is often the only option. A
(quick) reset of the device is often preferable to a lock-up or other
undefined behaviour.

--
Ian Collins.
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      04-11-2006
John Devereux wrote:
> Ian Collins <(E-Mail Removed)> writes:
>
>
>>John Devereux wrote:
>>
>>>Also in embedded systems or time or memory critical code, the overhead
>>>of the asserts may be too high to even run the program properly. For
>>>example assert() may bring in printf and the rest of the stdio
>>>library.
>>>

>>
>>That's where it pays to roll one's own assert macro. If the device has
>>no means to display the message, don't.

>
>
> That's what I usually do. For some platforms I set it to just halt the
> program, then at least you can usually see what happened in a
> debugger.
>

On embedded devices, I prefer to log an error message (if possible) and
reset. At least with a log, service personnel can see what has happened
to the device if it is returned as faulty.

--
Ian Collins.
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      04-11-2006
Manuel Tobias Schiller wrote:
> On 2006-04-11, Kiru Sengal <(E-Mail Removed)> wrote:
>>
>> assert is usually used to catch logical errors in your program,
>> that if deemed nonexistant after proper testing (noticing that
>> the assert never fires), would not require the error checking
>> anymore in your finished product

>
> Sometimes, leaving in a few of those assert statements in the
> finished product is a good idea as well because it will give a
> better indication of where things fail in production builds
> (because of misuse of the program, not buggy coding). I've seen
> this method being useful in the printer driver I maintain (a
> driver to use a certain GDI printer under *nix-like OS), so I
> thought sharing this "trick" with others (who might not yet
> know it) might be a good idea.


Nonsense, to put it mildly. The only asserts that should be left
in production code should be intended to catch hardware errors. It
should not be possible to trigger them in any other manner.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>


 
Reply With Quote
 
John Devereux
Guest
Posts: n/a
 
      04-11-2006
Ian Collins <(E-Mail Removed)> writes:

> John Devereux wrote:
>> Ian Collins <(E-Mail Removed)> writes:
>>
>>
>>>John Devereux wrote:
>>>
>>>>Also in embedded systems or time or memory critical code, the overhead
>>>>of the asserts may be too high to even run the program properly. For
>>>>example assert() may bring in printf and the rest of the stdio
>>>>library.
>>>>
>>>
>>>That's where it pays to roll one's own assert macro. If the device has
>>>no means to display the message, don't.

>>
>>
>> That's what I usually do. For some platforms I set it to just halt the
>> program, then at least you can usually see what happened in a
>> debugger.
>>

> On embedded devices, I prefer to log an error message (if possible) and
> reset. At least with a log, service personnel can see what has happened
> to the device if it is returned as faulty.


Ah, so you leave the asserts in the production code? Not saying that
is always bad, but I think it is not the normal (assumed) usage. AFAIK
the main thing that distinguishes the standard assert() is that it is
removed when NDEBUG is defined.

--

John Devereux
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      04-11-2006
"Stephen Sprunk" <(E-Mail Removed)> writes:
[...]
> For instance, most of the time when I write a function that is
> documented to accept only a non-NULL pointer as a parameter, it'll
> look like this:
>
> void func(void *param) {
>
> assert(param);
> if (!param) return;
>
> /* do useful stuff with param */
>
> }


In C90, assert()'s argument is required to be of type int, so this
isn't guaranteed to work (though any reasonable definition of assert()
is unlikely to care). In C99, the argument merely has to be a scalar,
so the call is legal. Nevertheless, I prefer the more explicit:

assert(param != NULL);

both because I find it clearer in the source code, and because the
argument is stringized and used in the error message:

assertion "param != NULL" failed: file "tmp.c", line 6

[...]
> One might also redefine assert() to print a message to stderr in
> production builds instead of having the test preprocessed out. That's
> the best of both worlds.


I'm not sure you can legally do that. What you can do is define an
assert-like macro with a different name.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-11-2006
John Devereux wrote:
> Ian Collins <(E-Mail Removed)> writes:
>
>
>>John Devereux wrote:
>>
>>>Ian Collins <(E-Mail Removed)> writes:
>>>
>>>
>>>
>>>>John Devereux wrote:
>>>>
>>>>
>>>>>Also in embedded systems or time or memory critical code, the overhead
>>>>>of the asserts may be too high to even run the program properly. For
>>>>>example assert() may bring in printf and the rest of the stdio
>>>>>library.
>>>>>
>>>>
>>>>That's where it pays to roll one's own assert macro. If the device has
>>>>no means to display the message, don't.
>>>
>>>
>>>That's what I usually do. For some platforms I set it to just halt the
>>>program, then at least you can usually see what happened in a
>>>debugger.
>>>

>>
>>On embedded devices, I prefer to log an error message (if possible) and
>>reset. At least with a log, service personnel can see what has happened
>>to the device if it is returned as faulty.

>
>
> Ah, so you leave the asserts in the production code? Not saying that
> is always bad, but I think it is not the normal (assumed) usage. AFAIK
> the main thing that distinguishes the standard assert() is that it is
> removed when NDEBUG is defined.
>

Always expect the unexpected!

--
Ian Collins.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      04-12-2006
CBFalconer wrote:
> Manuel Tobias Schiller wrote:
>
>>On 2006-04-11, Kiru Sengal <(E-Mail Removed)> wrote:
>>
>>>assert is usually used to catch logical errors in your program,
>>>that if deemed nonexistant after proper testing (noticing that
>>>the assert never fires), would not require the error checking
>>>anymore in your finished product

>>
>>Sometimes, leaving in a few of those assert statements in the
>>finished product is a good idea as well because it will give a
>>better indication of where things fail in production builds
>>(because of misuse of the program, not buggy coding). I've seen
>>this method being useful in the printer driver I maintain (a
>>driver to use a certain GDI printer under *nix-like OS), so I
>>thought sharing this "trick" with others (who might not yet
>>know it) might be a good idea.

>
>
> Nonsense, to put it mildly. The only asserts that should be left
> in production code should be intended to catch hardware errors. It
> should not be possible to trigger them in any other manner.
>

I disagree, they can be useful to catch error conditions that slipped
through testing.

--
Ian Collins.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      04-12-2006
Ian Collins <(E-Mail Removed)> writes:
> CBFalconer wrote:
>> Manuel Tobias Schiller wrote:
>>
>>>On 2006-04-11, Kiru Sengal <(E-Mail Removed)> wrote:
>>>
>>>>assert is usually used to catch logical errors in your program,
>>>>that if deemed nonexistant after proper testing (noticing that
>>>>the assert never fires), would not require the error checking
>>>>anymore in your finished product
>>>
>>>Sometimes, leaving in a few of those assert statements in the
>>>finished product is a good idea as well because it will give a
>>>better indication of where things fail in production builds
>>>(because of misuse of the program, not buggy coding). I've seen
>>>this method being useful in the printer driver I maintain (a
>>>driver to use a certain GDI printer under *nix-like OS), so I
>>>thought sharing this "trick" with others (who might not yet
>>>know it) might be a good idea.

>>
>>
>> Nonsense, to put it mildly. The only asserts that should be left
>> in production code should be intended to catch hardware errors. It
>> should not be possible to trigger them in any other manner.
>>

> I disagree, they can be useful to catch error conditions that slipped
> through testing.


Agreed. Asserts should not be used in production to handle errors
that can actually happen (failing to open a vital file, running out of
memory), but it's reasonable IMHO to use them for
this-should-never-happen errors (that can show up only if there's a
bug in the program).

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
pinkfog
Guest
Posts: n/a
 
      04-12-2006

lovecreatesbeauty wrote:
> Besides printing out for example
>
> " a.out: p113.c:8: main: Assertion `0' failed.
> Aborted "
>
> and a switch option NDEBUG, what other benefits does assert() provide
> in any scope of designing, debugging/coding and/or testing?
>
> Do you prefer the if statement of the language to the assert MACRO of
> the precompiler?
>
> --
> lovecreatesbeauty

assert just let you avoid the errors which are not expected to happen.
you use if statement or try_catch statement to mend the errors which
may happen by accident.
Hope what i say is right.

 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      04-12-2006
Keith Thompson schrieb:
> Ian Collins <(E-Mail Removed)> writes:
>>CBFalconer wrote:
>>>Manuel Tobias Schiller wrote:
>>>>On 2006-04-11, Kiru Sengal <(E-Mail Removed)> wrote:
>>>>
>>>>>assert is usually used to catch logical errors in your program,
>>>>>that if deemed nonexistant after proper testing (noticing that
>>>>>the assert never fires), would not require the error checking
>>>>>anymore in your finished product
>>>>
>>>>Sometimes, leaving in a few of those assert statements in the
>>>>finished product is a good idea as well because it will give a
>>>>better indication of where things fail in production builds
>>>>(because of misuse of the program, not buggy coding). I've seen
>>>>this method being useful in the printer driver I maintain (a
>>>>driver to use a certain GDI printer under *nix-like OS), so I
>>>>thought sharing this "trick" with others (who might not yet
>>>>know it) might be a good idea.
>>>
>>>Nonsense, to put it mildly. The only asserts that should be left
>>>in production code should be intended to catch hardware errors. It
>>>should not be possible to trigger them in any other manner.

>>
>>I disagree, they can be useful to catch error conditions that slipped
>>through testing.

>
> Agreed. Asserts should not be used in production to handle errors
> that can actually happen (failing to open a vital file, running out of
> memory), but it's reasonable IMHO to use them for
> this-should-never-happen errors (that can show up only if there's a
> bug in the program).


Depends; at my day job, we have "internal" and "release" "asserts".
The former are used as debugging aid in the debug version, i.e.
....
else
{
INTERNAL_ASSERT(0);
return F;
}
where F is a return value indicating failure for a function which
must not return F in normal circumstances. Even some of the paranoia
checks work this way. There are some places in the code where
assumptions that are integral and should always be completely true
but for hardware errors or some sneaky scenario that one can ask
for the permission to use a release assert instead. These are rare.
Usually we have an orderly "death" with numbered error messages even
for some more obscure cases.


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
To assert or not to assert... ImpalerCore C Programming 79 05-17-2010 12:47 PM
assert 0, "foo" vs. assert(0, "foo") Thomas Guettler Python 3 02-23-2005 07:53 PM
assert(x) and '#define ASSERT(x) assert(x)' Alex Vinokur C Programming 5 11-25-2004 08:48 PM
RE: remove assert statement (Was: Re: PEP new assert idiom) Robert Brewer Python 1 11-07-2004 06:53 PM



Advertisments