🚀 go-pugleaf

In article <DLMLL6.A0H@ukpsshp1.serigate.philips.nl>, baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
|> 
|> 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?

This is a very good question.  I understand the standard to imply
that all previous defined behaviour must have 'occurred', but
there is (in general) no necessity for it to have had an effect
on the outside world (assuming that such a thing exists).  Some
constructions (e.g. fflush()) require effects to be transmitted
to the environment.

But many vendors justify poor implementations by defining a most
bizarre 'environment', and then claiming that it is all the fault
of the latter :-(  In other cases, when the underlying system
does not provide appropriate primitives, this excuse is justified.


An even nastier problem is what happens after a C run-time system
has correctly trapped and recovered from a case of undefined
behaviour (e.g. SIGFPE).  Many or most vendors will use the
weasel words in the standard to refuse to accept ANY bug report
that relates to this area, no matter how obvious the bug is.

However, I tried to think of any wording that would handle this
case properly, and failed.  I believe that some of the critical
areas (e.g. signal() and longjmp()) could be improved by adding
more requirements for implementation defined behaviour (instead
of undefined), but that is about all.


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679