TRACE on external symbols of the COMMON-LISP package should signal an error

[Paul F. Dietz]

As noted in chat, the standard says the results are undefined when TRACE is invoked on an external symbol of the COMMON-LISP package. However, doing (TRACE ASH) causes memory faults when ASH is then called from the command line.

SBCL should signal an error when attempting this undefined behavior, rather than putting the image into a state where faults occur.

[Douglas Katzman (dougk)]

No it shouldn't. Absolute worst, a warning, but preferably not that either. The "undefined behavior" can be usefully exploited.

* (trace open)
* (open "/dev/null")
  0: (OPEN "/dev/null")
  0: OPEN returned #<SB-SYS:FD-STREAM for "file /dev/null" {10018BE193}>
#<SB-SYS:FD-STREAM for "file /dev/null" {10018BE193}>

works perfectly well, and is more convenient than running SBCL under strace.

As to the fact that tracing ASH causes stack overflow, there are plenty of other behaviors that would be more useful than signaling an error
- "wire in" all calls from any system function to any other system function such they they bypass the level of indirection normally imposed specifically so that functions can be redefined and calling by name gets the redefined callee. This would be a pain to deal with for developers.
- silently don't trace functions known to cause stack overflow. Build that list up over time as people report problems. (Because maybe every call to ASH was transformed into something internal that is not ASH. Just pretend it was)

To me this would be a wontfix though.