Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!gatech!hubcap!ncrcae!sauron!wescott
From: wescott@sauron.Columbia.NCR.COM (Mike Wescott)
Newsgroups: comp.bugs.misc
Subject: Re: Bug in dc? and another one?
Message-ID: <930@sauron.Columbia.NCR.COM>
Date: Wed, 7-Oct-87 15:40:31 EDT
Article-I.D.: sauron.930
Posted: Wed Oct  7 15:40:31 1987
Date-Received: Sat, 10-Oct-87 10:34:07 EDT
References: <1800@ncr-sd.SanDiego.NCR.COM>
Reply-To: wescott@sauron.Columbia.NCR.COM (Mike Wescott)
Organization: Entry Level Systems Development, NCR Corp., Columbia, SC
Lines: 40
Keywords: dc, segmentation error

In article <1800@ncr-sd.SanDiego.NCR.COM> randall@ncr-sd.SanDiego.NCR.COM (0000-Randall Rathbun) writes:
> Running the short dc routine below to find the gcd of two numbers
> appears to work for small numbers.
> 
> ........
> 
> When r & s are about 100 digits or so in length, an error message appears:
> %Segmentation fault (core dumped)
> 
> What is wrong?

Looks like an overflow of readstk.  readstk has a hard coded limit of 100
in the SysVr3 source that I have access to.  It's a bug in that the exceeding
the limit is not gracefully handled.

While tracking down this problem I came across some strange looking code:

   In readc():
		if((readptr != &readstk[0]) && (*readptr != 0)){
			.
			.
			.
		}
		.
		.
		if(readptr != &readptr[0]){	<===== ???????????
			readptr--;
			.
			.
			.

Surely the author meant  "if(readptr != &readstk[0]) ...

In anycase the whole if stmt gets optimized to nothing.  Looks like the
relics of an attempt to put a more general file reading mechanism into dc.

	-Mike Wescott
-- 
	-Mike Wescott
	 wescott@ncrcae.Columbia.NCR.COM