Re: Should undefined behavior be encouraged in Emacs?

[Dave Abrahams <dave@boostpro.com>]

on Sun Oct 02 2011, Paul Eggert <eggert-AT-cs.ucla.edu> wrote:

> A recent comment in Bug#9642 advocates another approach: undefined
> behavior.  For example, it proposes that move-overlay should have
> undefined behavior when given arguments like -5 that are out of
> range.  In other words, (move-overlay OVERLAY -5 1) might signal
> an error, or substitute an in-range value, or wrap around, or
> return a data structure that subtly violates some other guarantee
> made by Emacs; or it might do one of these things sometimes and
> another at other times.  In short, undefined behavior means that
> move-overlay might do *anything* when given out-of-range
> arguments.
>
> The argument given for undefined behavior is that it simplifies
> maintenance of Emacs internals.

Such an interesting question!  

Unefined behavior gets a bad rap, but it has at least one important use:
it distinguishes things that are definitely programming bugs from
everything else.  It is perfectly legitimate (and even encouraged style
in some languages) to rely on the defined behavior that certain
out-of-range arguments will cause errors to be signaled, e.g. for loop
termination:

   (condition-case nil
     (let ((n 0))
        (while t 
         (frobnicate (get-item n))
         (setq n (+ n 1))))
     (error "index out of range"))

The problem with this is that when you see a signal come out of get-item
you can't tell whether it indicates a bug or not.  So I actually favor
something stronger than ordinary defined behavior for out-of-range
arguments.

For elisp programs, I don't think completely *undefined* behavior
(reformat your hard disk, launch a missile) is such a hot idea, since it
should in principle be easy to limit the range of responses to things
that are less damaging.  Maybe unspecified behavior, as suggested
elsewhere in this thread, is closer to the mark.

As the author of get-item above, I'd probably want to express the
unspecified behavior by forcing the debugger to come up, with *no
possibility* of it being suppressed by surrounding constructs such as
condition-case (is that possible in elisp?).  But I wouldn't want anyone
trying to rely on that behavior except maybe as a debugging aid.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com