🚀 go-pugleaf

In article <DLMLL6.A0H@ukpsshp1.serigate.philips.nl>, baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
>Tanmoy Bhattacharya (tanmoy@qcd.lanl.gov) wrote:
>>In article <DLKrx7.6p6@ukpsshp1.serigate.philips.nl>
>>baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes: 
>>>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.

>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)?

What do you want?  Execution continues to be defined for a maximum of
255 C language statements plus whatever library functions are invoked,
and then suddenly becomes undefined?  I sort of think the answer was that
a program that keeps executing indefinitely keeps executing indefinitely.

>[Note: There is a large class of programs that never exit at all [...]
>I agree it would be perverse of such a program to make exactly one call
>to exit and then abandon it by a long jump from an atexit function to main.
>One can also construct programs that do this longjump and terminate later
>by calling abort.

Why do you suppose there's an IOCCC but no IOCC for other languages?
Anyway, you know how to build yourself an IOCCC entry.  Yes, C permits it.

>However I think it is reasonable to ask if it is defined what happens after
>the longjump in the example is made.]

Hmm.  Maybe you want undefinition to begin at the point where a powerful
implementation could theoretically detect that the program will never be
able to terminate in a defined manner, instead of waiting until the program
tries to exit again?  Well, what about a daemon with an infinite loop that
neglects to test any termination status?  Should it start as undefined?

>A related question - does undefined behaviour invalidate (make undefined)
>all defined behaviour that has gone before?

It's hard to argue that defined behavior that went before was really
undefined, but it's easy to argue that this is an irrelevant point.
When undefined behavior makes your disk drive melt, it doesn't matter
if a the files being melted were correctly output by the implementation's
execution of the program.  Less dramatically, undefined behavior can cause
garbage to be scribbed all over your disk, and it still doesn't matter
whether it was good stuff or bad stuff getting erased.

>If so does this mean that any program 
>that does not exit() or return from main have any defined behaviour?

A program that does not exit() or return from main can still do a bunch
of other stuff, and if all that stuff is defined by the standard then
it has defined behavior.

(Incidentally, I still opine that an implementation can finish executing
the program in a finite time if the implementation knows how to make
all the output correct as defined.)
--
 <<  If this were the company's opinion, I would not be allowed to post it.  >>
"I paid money for this car, I pay taxes for vehicle registration and a driver's
license, so I can drive in any lane I want, and no innocent victim gets to call
the cops just 'cause the lane's not goin' the same direction as me" - J Spammer