Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #23556 > unrolled thread

Asserting Failure

Back to article view | Back to comp.lang.forth

Contents

  Asserting Failure "Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> - 2013-06-13 18:20 +0100
    Re: Asserting Failure Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-06-13 20:43 -0700
    Re: Asserting Failure anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-06-14 12:30 +0000

#23556 — Asserting Failure

The link is an article by Jack Ganssle about using the assert() feature in C 
programming. I am not advocating we consider these in Forth but thought 
others might like to see what they do in another language to try and produce 
correct software.

<http://www.embedded.com/electronics-blogs/break-points/4416078/Asserting-
Failure?cid=Newsletter+-+Whats+New+on+Embedded.com>

The Forth philosophy of "Crash Hard, Crash often" during development is I 
think much better but we also need to ensure that the code is inspected for 
the quieter systematic problems that can creep in.

-- 
********************************************************************
Paul E. Bennett...............<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

[toc] | [next] | [standalone]

#23576

On Jun 13, 10:20 am, "Paul E. Bennett" <Paul_E.Benn...@topmail.co.uk>
wrote:
> The link is an article by Jack Ganssle about using the assert() feature in C
> programming. I am not advocating we consider these in Forth but thought
> others might like to see what they do in another language to try and produce
> correct software.
>
> <http://www.embedded.com/electronics-blogs/break-points/4416078/Assert...
> Failure?cid=Newsletter+-+Whats+New+on+Embedded.com>
>
> The Forth philosophy of "Crash Hard, Crash often" during development is I
> think much better but we also need to ensure that the code is inspected for
> the quieter systematic problems that can creep in.

Forth's ABORT" and C's ASSERT are essentially the same thing, except
that the flag is backwards --- in both cases, they "crash hard" (well,
not so hard that they don't display an error message first).

It used to be common to have a compile-time flag to indicate whether
ABORT" should be compiled or not, so it is not slowing down production
code. I've seen cases in which there are levels, such as L1ABORT"
L2ABORT" etc.. This is easy to implement in Forth --- in C, I suppose
you would have to have a macro-formatter that takes a marked-up source-
file and produces a new source-file, according to the mark-ups in the
original source-file (everything is complicated in C). Nowadays,
considering how fast the processors are, I would just leave the ABORT"
stuff active all the time including in the production code.

Anyway, this is classical debugging --- pretty standard stuff when you
don't have a source-level debugger.

[toc] | [prev] | [next] | [standalone]

#23591

"Paul E. Bennett" <Paul_E.Bennett@topmail.co.uk> writes:
>The link is an article by Jack Ganssle about using the assert() feature in C 
>programming. I am not advocating we consider these in Forth but thought 
>others might like to see what they do in another language to try and produce 
>correct software.
>
><http://www.embedded.com/electronics-blogs/break-points/4416078/Asserting-Failure?cid=Newsletter+-+Whats+New+on+Embedded.com>

http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Assertions.html

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web