🚀 go-pugleaf

--text follows this line--
In article <DLMLL6.A0H@ukpsshp1.serigate.philips.nl>
baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes: 
<snip>
   :    :    main() calls setjmp() and then calls exit().  An atexit() function
   :    :    calls longjmp() and returns to main().  This repeats (or does it?)

   :    : Neither of these is permitted in any sense that I understand!
   :    : 7.10.4.3: If more than one call to the exit function is executed by
   :    : a program, the behaviour is undefined. No `permission by omission'
   :    : that I can see.

   :    In this example what happens if no second call to exit is been made (after
   :    longjumping back to main the program does not attempt to call exit again -
   :    instead it keeps executing indefinately)?

   : I don't understand the question: are you asking what happens if a
   : program keeps executing indefinitely? Well, it just keeps executing
   : indefinitely. After that infinite period, the rest of the exit
   : processing happens and a return status is indicated to the rts.

   The question I am asking is if:
       main() calls setjmp() and then calls exit().  An atexit() function
       calls longjmp() and returns to main().  main() then continues to
       execute other code. Is the execution of this code defined behaviour
       (so long as no attempt is made to exit again)?

Okay, let me be more precise: what in the standard suggests that this
is undefined behaviour? It is difficult to have an opinion about
something when I do not even see the counterpoint.

(Note: nothing in the standard implies that anything takes a finite
non-zero amount of time. A program continuing `for ever' after a call
to exit should therefore be perfectly fine. I do not see any reason to
think otherwise.)

<snip>
   A related question - does undefined behaviour invalidate (make undefined) all 
   defined behaviour that has gone before? If so does this mean that any program 
   that does not exit() or return from main have any defined behaviour?

I again feel that the question is wrongly phrased. Once a program uses
a construct that leads to undefined behaviour, the international
standard imposes no constraints on how the _program_ is translated and
executed. (except, due to TC1 I believe, some possible diagnostics
continue to be required) There is no concept that I can find in the
standard that justifies the concept of `before' or `after' an
`undefined behaviour' occurs.

The last question I can't parse. But I think that the question you
want to discuss is whether a program that doesn't terminate falls in
the category of programs using constructs with `undefined behaviur'. I
fail to see what construct that may be.

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]