OS/2 Shareware BBS: 5 Edit/05-Edit.zip/me34src.zip/me3/doc/mm.bug

Lisp/Scheme | 1995-01-14 | 5KB | 135 lines

                                -*-text-*-
              The Mutt Machine Bug List
              --- ---- ------- --- ----

====================================================================
====            MM2 Needed Features            ====
====================================================================


====================================================================
====            The MM2 Low End of the Want List            ====
====================================================================


====================================================================
====            MM2 Bug and Change list            ====
====================================================================
- means bug in this (and subsequent) releases
* means bug fixed in next release
+ means new feature in next release


v2.6 2/13/94    [Released , 1994]
---- -------

v2.3 2/21/93    [Released June, 1993]
---- -------
* (defun bug (pointer int x) { (x 123) }) didn't compile.  Fixed 2/94.
* mm.h GET_INT32 macro (long form) didn't work on Borland C (probably
  all 16 bit ints).  Fixed 3/94.

v2.1 1/30/93    [Released January 30, 1993]
---- -------
* BAD bug when passing pointers to function addresses.  If the function1
  passes a pointer to function2 (f1 and f2 are in the same block) to
  function3 in another block and f3 calls though the pointer, there is
  no switching to f2 address space so bad things usually happen.
  Example:
    bug1.mut
    (defun
      bug1 { (bug2 (floc bug3)) }
      bug3 { (msg "This is bug3") }
    )
    bug2.mut
    (defun bug2 (pointer defun bugger) { (bugger) })

    Calling bug1 is bad.
  All other form of floc are OK - (floc "bug3"), tokens, within the
    same block, etc.
  Work around:  Pass the function name as a string:  (floc "bug3").
  9/92
  Fix:  Have to be able to query, set and remember the current block
    though function calls.  This means a bigger stack frame and new
    routines in the application.  Oh well.  I created a "long"
    (segmented) address type that can be used for interblock calls.  It
    is 32 bits, divided into N bits of block id and (32 - N) bits of
    offset from the start of the block.  Somewhat sleezy.  2/93

* Result register can get stomped in some cases.  If a string is pushed
  into the stack frames local storage and the function returns that
  string AND then another string is pushed into the [parents] frame, the
  new string can overwrite the returned string.
  For example:
    (defun
      zip HIDDEN { (arg 0) }
      bug MAIN
      {
    (msg (zip (concat "666")) "," (concat "hmm"))
      }
    )
  When bug is run, "hmm,hmm" is returned, not "666,hmm".
  Why:  RV is pointing into the local stack frame after the frame is
    freed, the parents frame grows over the freed frame (as it should)
    so the new string is pushed over RV.
  6/93
  Fix:  Do a little more checking in PUSHRV.

- mm_ask() (mm.c) can overflow result[] and cause mm to dump core.
  mm_ask() calls MMask() and passes result[] to be filled in.  It has no
  clue how much will be put there.  Ran into this when yanking long
  (600+ character) X server compile lines into the minibuffer.  12/92
- MMload_code() (mm.c) should also print the file name when complaining.
  5/92
- In MMload_code() (mm.c) I don't check fread() for errors.  Could be a
  problem when reading bogus .mco files.  4/92

v2.0 2/2/92    [MM2 beta, released February 28, 1992]
---- ------
* On small int machines (MS-DOS), length-of can go negative.  1/93

- BAD bug when passing pointers to function addresses.  If the function1
  passes a pointer to function2 (f1 and f2 are in the same block) to
  function3 in another block and f3 calls though the pointer, there is
  no switching to f2 address space so bad things usually happen.
  Example:
    bug1.mut
    (defun
      bug1 { (bug2 (floc bug3)) }
      bug3 { (msg "This is bug3") }
    )
    bug2.mut
    (defun bug2 (pointer defun bugger) { (bugger) })

    Calling bug1 is bad.
  All other form of floc are OK - (floc "bug3"), tokens, within the
    same block, etc.
  Work around:  Pass the function name as a string:  (floc "bug3").
  9/92

- mm_ask() (mm.c) can overflow result[] and cause mm to dump core.
  mm_ask() calls MMask() and passes result[] to be filled in.  It has no
  clue how much will be put there.  Ran into this when yanking long
  (600+ character) X server compile lines into the minibuffer.  12/92

- MMload_code() (mm.c) should also print the file name when complaining.
  5/92

- In MMload_code() (mm.c) I don't check fread() for errors.  Could be a
  problem when reading bogus .mco files.  4/92


============== MM bugs ===========
* If you do a (floc (concat "foo")()) and foo doesn't exist, MM core
  dumps.  This is due to the op structure pointing to result so
  strcat(result,name) infinite loops in exetern().  Fix is to push name
  on val stack if it is in result (in PUSHRV).  This was also a bug
  because if result (RV) changed before the function was called, the
  wrong thing would be called.  4/16/91.
* Part of the above bug, modify pushpush() to gen a PUSH (instead of a
  SHOVE) if pushing a FCNPTR - otherwise the above fix won't get a
  chance to work.  4/16/91.
  This fix is AFU.  Can't push because it sets a stack frame - gotta
  shove.  The real fix is in MM.  In faddr, if if the routine name is in
  result, push it onto the val stack.  Right fix, wrong place.  9/13/91