[net.micro.amiga] Amigaterm the fix revisited

cem@intelca.UUCP (Chuck McManis) (02/18/86)

> From: DICKSON, JEFF S. <jdickson@jpl-milvax.arpa>
> 
> 
> 	I just purchased Lattice's latest C compiler - release 3.03. My only
> grief with it is that I cannot get Amigaterm to run correctly. 
> 
> 	When the program is invoked, the Amiga issues a "Software Error - Task
> Held" message. After you click the cancel box the guru meditation box appears
> atop the screen and the system hangs.
> 

Ok folks one more time, (forgive me if everyone jumps up and shouts the 
answer) The new Lattice compiler (version 3.03B) does not correctly compile
statements that mix pointer and array arithmetic. Thus, if you use a pointer
to an array of menu items (like AmigaTerm) and try to reference them
as &Arrayname[n + 1] to get a pointer to array element n+1, you will get 
incorrect code and a GMN (Guru Mediation Number.) AmigaTerm uses this type 
of syntax in two places, one in the initialization of the Baud rate menu 
list, and once in the initialization of the options list. It is being used 
to create a linked list of menu pointers in the menu strip. 

To fix it, read through the code and look for one statement in each
init routine that is of the form &variablename[n + 1]. This is supposed
to return a pointer to element n+1 or array variablename, it doesn't.
change those two statements to &variablename[n]+1, which looks totally
incorrect to programmers in any language other than C, however the compiler
generates 'pointer arithmetic' code such that the end result that is 
returned can be interpreted as "pointer to array element 'n' plus the length
of one element, which equals a pointer to element n+1." which is indeed 
what the original statement intended. I have heard from Lattice that this
has been fixed in V3.04. 

Is this clear? When I get diff ported I could post a diff output file, but
by that time to version on Fred's disk set will be fixed, right Fred ?

--Chuck
-- 
                                            - - - D I S C L A I M E R - - - 
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}

fnf@unisoft.UUCP (Fred Fish) (02/20/86)

In article <214@intelca.UUCP> cem@intelca.UUCP (Chuck McManis) writes:
>Is this clear? When I get diff ported I could post a diff output file, but
>by that time to version on Fred's disk set will be fixed, right Fred ?

Actually, I am considering a special "bug fix" disk, to contain versions
of previously released software with various bugs fixed, and bug
workarounds installed.  In order for this to be successful, I need
people to send me fixes they have found.  If I get enough, I will put
them together and add them to the library.  I do not think that making
the fixes directly to the working disk set is a good idea because that
just leads to total confusion when a version off an earlier release of
the same disk behaves differently.

The best way to send fixes is to mail me hardcopies of the fix in
"diff -c" format, if they are short.  Otherwise use email or send
a disk.

-Fred

===========================================================================
Fred Fish    UniSoft Systems Inc, 739 Allston Way, Berkeley, CA  94710  USA
{ucbvax,dual}!unisoft!fnf	(415) 644 1230 		TWX 11 910 366-2145
===========================================================================