Re: The definition of *bomb*

Paul Havlak <>
Mon, 18 Jan 1993 18:40:28 GMT

          From comp.compilers

Related articles
Compile Time vs. Run Time TDARCOS@MCIMAIL.COM (Paul Robinson) (1993-01-08)
The definition of *bomb* (1993-01-15)
Re: The definition of *bomb* nickh@CS.CMU.EDU (1993-01-18)
Re: The definition of *bomb* (Paul Havlak) (1993-01-18)
| List of all articles for this month |

Newsgroups: comp.compilers
From: Paul Havlak <>
Organization: Center for Research on Parallel Computation
Date: Mon, 18 Jan 1993 18:40:28 GMT
References: 93-01-041 93-01-110
Keywords: debug, design

        Not to belabor the definition of "bomb", but it seems to me that there
is a useful distinction between undefined behavior and other kinds of
unwanted program behavior. Neither is necessarily easier to find by hand.
        Undefined behavior makes a program meaningless according to the
language standard. Most high-level languages have large realms of
undefined behavior, especially if they are portable; for example, type
mismatches, subscripts out of bounds, or nondeterministic parallel access.
        Hidden undefined behavior means that the abstract model of the
language has been violated, and the mapping of errors to behavior can be
subtle and unpredictable.
        Functional language implementations have the advantage of
automatically detecting many kinds of undefined behavior. For example,
type mismatches are detected at compile time in ML, at run time in most
Lisp dialects. Their users pay for this in more restrictive languages,
slower compilers and/or slower execution. They gain a robust abstract
        As hardware get faster and more complicated, and software also more
complicated, languages that are robust in this sense will do increasingly

Paul Havlak Dept. of Computer Science
Graduate Student Rice University, Houston TX 77251-1892
PFC/ParaScope projects (713) 527-8101 x2738

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.