Greetings! Robert Boyer <[EMAIL PROTECTED]> writes:
> Are you interested in interpreted calls of system functions > that cause GCL 2.7.0 to say something like: > > Caught fatal error [memory may be damaged]? > Yes! These are all mistakes. They are basically missing check-types at the top of the functions. System functions at present are compiled at safety 1, which means "check arguments". Errors are automatically triggered if the call signature does not match the function signature, but type checking must be done explicitly. The alternative is to compile at safety 2, which disables certain inlining, making essentially all calls within the function check arguments too, e.g. car, cdr .... It appears that the best way to pass Paul's tests on system functions without sacrificing performance is the above method at safety 1. > Some examples: > > (WRITE-LINE 0 0) > (WRITE-STRING 0 0) > (ETYPECASE '(1 2 3) 4) > (CTYPECASE 1 2 3 4 5) > > Let me know if you have any interest in more. I'm merely > feeding to a random, external, fboundp symbol of package > COMMON-LISP some random objects in the GCL 2.7.0 image. > > I am not smart enough to know for sure whether "memory may > be damaged" is "ANSI wrong". > > As a user, I could tell you what I think, but as a > government employee I better not use such words in email. > > I don't mind such "memory may be damaged" messages when I > run something compiled at SAFETY 0. There I get what I > deserve and am taking my chances. > > However, when debugging with interpreted code, I would > prefer to have such errors caught more gracefully than > "memory maybe damaged". > > It could well be that I am asking for too much. It may be > that "memory may be damaged" is actually what we really > want, after several decades of consideration, so that, for > example, at SAFETY 0 one can get better performance. > > Here's a somewhat encouraging passage from the ANSI: > > The informal intent is that the programmer can rely on a > call to be safe, even when system code is involved, if > all reasonable steps have been taken to ensure that the > call is safe. For example, if a programmer calls mapcar > from safe code and supplies a function that was compiled > as safe, the implementation is required to ensure that > mapcar makes a safe call as well. > > But just what are "reasonable steps"? The ANSI does not > spell that out as far as I can tell. So, what is the > possible penalty for passing an operation an argument of the > wrong type? > > Except as explicitly specified otherwise, the > consequences are undefined (i.e., it says elsewhere, may > range from harmless to fatal) if these type restrictions > are violated. > > So, for example, in the case of 'car', since an error > "should" be signalled, the form (car 3) typed to the very > top-level read-eval-print-loop at SAFETY 3 must cause an > error. However, the form (* 'a) only "might" signal an > error, and so could in principle delete all your files, even > at SAFETY 3. Or even do the dread: (push-the-button)! > > Who knows? Not me. > > Bob > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gcl-devel
