Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.bugs.sys5
Subject: another 5620 DMD 2.0 "optim" bug
Message-ID: <6417@brl-smoke.ARPA>
Date: Fri, 11-Sep-87 22:11:07 EDT
Article-I.D.: brl-smok.6417
Posted: Fri Sep 11 22:11:07 1987
Date-Received: Sun, 13-Sep-87 09:38:08 EDT
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 22
Keywords: 5620 DMD SGS M32 optim

BUG FIX for 5620 DMD 2.0 $DMD/sgs/usr/src/cmd/sgs/optim/m32/func.c
and $DMD/sgs/usr/src/cmd/sgs/optim/common/optim.h,
probably also applies to /lib/optim in other M32 SGS releases.

The problem was that for a CALL op (at least), ops[4] was getting
stomped on (under the alias opm) and not cleaned up later, but only
a NULL ops[.] would be safely ignored later, not one containing a
(char *)4 for example.  (I'm tempted to comment on code that resorts
to kludges like the one that caused this bug, but I won't :-)

/* @(#) func.c: 1.5 7/31/84				*/
...
#define opm 	ops[MAXOPS+1]		/* DAG -- was MAXOPS */
...

/*	static char  ID[] = "@(#) optim.h: 1.7 1/20/84";	*/
...
typedef struct node {
...
	/* DAG -- following was MAXOPS+1, but func.c needs more room: */
	char *ops[MAXOPS + 2];	/* opcode or label and operand field strings */
...