Talk:Assertion (software development)

message: I have noticed you quote Hoare paper and claim you use the same syntax as the original paper, but that is in fact not true at all, I suspect people have not read the paper at all. The modern Hoare tripple notation is the one used on here, that is {P} Q {R} and not like the paper which says P {Q} R.  —Preceding unsigned comment added by 79.72.191.93 (talk) 11:38, 19 March 2010 (UTC)
replies: text: The operation is called assertion checking; a test which performs it is called an assertion. Calling it an "assert", as if that were a noun, is not particularly literate. It is as if someone who had learned about the <TT>for</TT> keyword in C started calling the writing of loops "foring" .... --FOo 06:19, 6 Dec 2003 (UTC)
thread_title: Hoare paper

message: :an assertion is a programming language construct which immediately aborts program execution if a certain condition or expression is false
This is often the case, but not always: writing a warning and continuing, or simply ignoring the assertion are possible reactions to failed assertions at runtime.  Often one is not really all that interested in assertions at runtime, but regard them as a piece of information for compilers or program analysers. ---- Charles Stewart 14:47, 21 Sep 2004 (UTC)
replies: text: Fixed in the latest version of the article. Neilc 23:54, 29 Mar 2005 (UTC)
thread_title: Inaccuracy

message: The following has been removed:
:In some cases, assertions may be configured so that when they fail they do not terminate the program, but leave a log entry. This is often the case when the program involves access to networks or intricate caching or concurrent executions. In those cases, it is often difficult to reproduce the same execution path, thus the assertions failure.
Is it not true? I myself did see this kind of implementation before. -- Taku 04:14, Mar 30, 2005 (UTC)
: The current version of the article talks about the various ways of handling assertion failure (ignore it, halt program, print information about the error, etc.), so I think the content of the first sentence is still in the article. The second and third sentences don't make sense to me — I'm not sure why a concurrent program would be more or less likely to dump core when an assertion failure occurs. Part of the point of halting the program immediately (in languages like C) is getting a stack trace, which can be particularly useful in concurrent programs. If you want to discuss how different kinds of programs handle assertion failure in different ways (in general), that's fine with me -- I'm just not sure how broadly you can generalize here. Neilc 07:04, 30 Mar 2005 (UTC)
thread_title:  Handling assertion failure 

message: : The article's content is rated an age +16 comprehension level by Kristan Wifler
 maybe someone could make a -15 sibling page?
PJTraill 21:35, 30 April 2006 (UTC)
thread_title:  Comprehensibility 

message: The material on Hoare triples in the introductory section strikes me as far to long, detailed, and one-sided.
I reckon it belongs later, perhaps in a section on theory.
PJTraill 00:59, 19 January 2007 (UTC)
thread_title:  [[WP:LEAD]] - introduction overweight 

message: The malloc() example (illustrating incorrect use of assertions) is a bad one.  On modern operating systems with memory overcommit, running out of memory will not cause malloc() to return NULL.  Instead, it will usually result in a segmentation fault in some random part of the code, not necessarily anywhere near the malloc() call.  Running out of address space, on the other hand, will cause malloc() to return NULL, but it is usually the result of a programming error.  This is especially true on a 64-bit platform, where address space size exceeds actual memory size by several orders of magnitude.
Combine those facts with the difficulty of gracefully recovering from an allocation failure, and you will see that it often makes sense to treat malloc() as if it can never return NULL.  There isn't much point in sticking an assertion in there, though, since the simple act of using the NULL pointer will terminate the program much like an assertion failure would (and will often leave a more useful stack trace).
DES (talk) 22:58, 21 January 2008 (UTC)
replies: text: I'd prefer another example, too. Input validation would be a better example for badly used assert() as it would allow malicious input to terminate the program. However, after input has been validated, assertions can be useful as they allows safety checks that can be easily disabled for optimal performance. Also I think in practice very few software recovers gracely from allocation failures. Even if they're handled, the internal state of the program may become dysfunctional which can easily be worse than terminating as the latter is easy to detect. --77.8.99.210 (talk) 17:56, 15 January 2011 (UTC)
thread_title:  malloc example 

message: Is there any particular reason that the C example goes like this
x = 5;
// {x > 0}
x = x + 1;
// {x > 1}
rather than like this?
x = 5;
assert(x > 0);
x = x + 1;
assert(x > 1);
The latter is certainly clearer to any C programmer (not to mention that it can
actually be checked at runtime).
JöG (talk) 07:32, 4 January 2009 (UTC)
replies: text: I agree that it is a bad example, but not for the reason you state.  The text preceding the example clearly mentions unchecked assertions.  The example is intended to illustrate the use of source comments to document assertions in languages which lack checked assertions.  However, assertions in C are not a language mechanism; assert(cond) simply expands to code that terminates the program (usually by calling abort()) if cond evaluates to 0 at run time.  This means that assertions can not be checked at compile time.  A good compiler will eliminate the assertion check if the condition is obviously true (as it is in this case), but it will not issue an error, or even a warning, if it is obviously false.  Still, it's better than nothing... DES (talk) 14:57, 14 January 2009 (UTC)
thread_title:  The initial C example 

message: Hi Everyone,
I feel like the article conflates the concept of asserts (state, preconditions, postconditions, Design by Contract) and implementations details (specifications like POSIX assert and languages like C and C++). I think the article should make a distinction between the two.
For what its worth, I love asserts. They create self-debugging programs so I don't have to waste time under a debugger. But asserts in C and C++ are a debug facility and they should be removed in release configurations. In C and C++ you need to write a real `if` statement at runtime to enforce the conditions.
Two related discussions are Asserts considered harmful (or GMP spills its sensitive information) and Crypto++ Assertions. They provide a discussion of some of the problems in practice for C and C++. I've never seen a "Design by Contract" doc that says sensitive information, like passwords and private keys, will be breached due to a failed precondition. But that is what sometimes happens in practice in C and C++.
Jeffrey Walton  (talk) 06:31, 9 November 2020 (UTC)
thread_title:  Conflating concept and implementation 

message: If you are looking for an example of a statement being removed inside an assert macro due to NDEBUG (and the need for verify macro instead), then see Nettle's bug at GMP and assert() on LWN.
Here's the article's example of the assert/verify macro problem:
  int *ptr;
  // Statement below fails if malloc() returns NULL,
  // but is not executed at all when compiling with -NDEBUG!
  assert(ptr = malloc(sizeof(int) * 10));
  // use ptr: ptr isn't initialised when compiling with -NDEBUG!
Jeffrey Walton  (talk) 07:15, 9 November 2020 (UTC)
thread_title:  Assert/Verify macro example