mrr@amanpt1.zone1.com (Mark Rinfret) (06/10/88)
I fixed a bug in my copy of MG2a last night. This was revealed by the "task held" requester after selecting the "Set Mark" menu item (which tells you that I compiled in the MENU option). To be brief, in file sys/amiga/ttymenu.c, function amigamenu, there is a line: return (*(fp)(f,n)); which should really be: return ((*fp)(f,n)); The current code attempts to return the value _pointed to_ by the return value of the dispatched function. When one of these (such as setmark) returns a TRUE (1), an odd address exception is generated: move.w (a0),d0 fini -- < Mark R. Rinfret, mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr > < AMA / HyperView Systems Home: 401-846-7639 > < 28 Jacome Way Work: 401-849-9930 x301 > < Middletown, RI 02840 "If I just had a little more time...">
mic@ut-emx.UUCP (Mic (... K[a-z]+) Kaczmarczik) (06/12/88)
In article <474@amanpt1.zone1.com> mrr@amanpt1.zone1.com (Mark Rinfret) writes: >I fixed a bug in my copy of MG2a last night. This was revealed by the "task >held" requester after selecting the "Set Mark" menu item (which tells you >that I compiled in the MENU option). To be brief, in file >sys/amiga/ttymenu.c, function amigamenu, there is a line: > > return (*(fp)(f,n)); > >which should really be: > > return ((*fp)(f,n)); > Guilty as charged. One of the problems with all the compile-time configuration stuff in mg (and other programs in general) is that it's often difficult to test everything. When I rewrote the menu code to call the functions directly instead of using up more string space, I never tested the menu code without the Browser compiled in. A few lines further down, in the BROWSER + MENU code, there is a correct call via the function pointer. I'll send in a patch to mg-developers, so it'll be fixed in the next release. Sigh, --mic-- >< Mark R. Rinfret, mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr > >< AMA / HyperView Systems Home: 401-846-7639 > >< 28 Jacome Way Work: 401-849-9930 x301 > >< Middletown, RI 02840 "If I just had a little more time..."> -- Mic Kaczmarczik If you drink, don't drill. UT Austin Computation Center -- Matt Groening mic@emx.utexas.edu MIC@UTAIVC.BITNET
jw@obelisk.sics.se (Johan Widen) (06/20/88)
The lattice compiler complains about the following line in macro.c
int flag, num;
if(macrodef ||
! (macrocount >= MAXMACRO && macro[MAXMACRO].m_funct != finishmacro))
return FALSE;
if(macrocount == 0) return TRUE;
inmacro = TRUE;
The problem is that macro is that the last element of macro[] is
macro[MAXMACRO - 1]
I'm not sure what the correct fix is. I just changed the line to read
int flag, num;
if(macrodef ||
! (macrocount >= MAXMACRO &&
! macro[MAXMACRO - 1].m_funct != finishmacro))
return FALSE;
if(macrocount == 0) return TRUE;
inmacro = TRUE;
but this may be an incorrect fix.
--
Johan Widen
SICS, PO Box 1263, S-164 28 KISTA, SWEDEN
Tel: +46 8 752 15 32 Ttx: 812 61 54 SICS S Fax: +46 8 751 72 30
Internet: jw@sics.se or {mcvax,munnari,ukc,unido}!enea!sics.se!jw