fatalassert ( flag n u -- ) abort if flag is false, log n and u after restart assert ( flag n u -- ) abort if flag is false and assertion is activated, log n and u after restart assert? ( -- flag ) Was there an assert? assert# ( -- u ) How many asserts occurred since cold startup? assert@ ( -- u1 u2 ) Assert number u1 and parameter u2 e.g. address where the assert occurred .assert ( u -- ) Print assert messageIf logging is activated (
CFG_LOG_MSG
defined) the logs are written to
0:/var/log/messages
A cold restart is a CPU reset with RTC domain reset (power cycle). A warm restart is a CPU reset without RTC domain reset.
During development cycle, the programmer will typically run the program with assertions enabled. When an assertion failure occurs, the programmer is immediately notified of the problem. Many assertion implementations will also halt the program's execution: this is useful, since if the program continued to run after an assertion violation occurred, it might corrupt its state and make the cause of the problem more difficult to locate. Using the information provided by the assertion failure (such as the location of the failure and perhaps a stack trace, or even the full program state if the environment supports core dumps or if the program is running in a debugger), the programmer can usually fix the problem. Thus assertions provide a very powerful tool in debugging. When a program is deployed to production, assertions are typically turned off, to avoid any overhead or side effects they may have.