Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!usc!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew From: aglew@oberon.csg.uiuc.edu (Andy Glew) Newsgroups: alt.sources Subject: Re: number recognition tools Message-ID: Date: 18 Jan 90 22:38:13 GMT References: Sender: news@ux1.cso.uiuc.edu (News) Distribution: comp Organization: University of Illinois, Computer Systems Group Lines: 43 In-Reply-To: aglew@oberon.csg.uiuc.edu's message of 15 Jan 90 11:53:0 Urghh... I like showing people my source code, but I *hate* it when they find embarassing errors (egoless programmer, I'm not). Swallowing foot, let me acknowledge Joseph Pepin's bug report (which he couldn't post) to the number recognition tools I posted recently. I will posted a cleaner version soon. Return-Path: Date: Thu, 18 Jan 90 15:26:53 EST From: jdp@tarpon.att.com (Joseph Pepin) To: aglew@oberon.csg.uiuc.edu Subject: Re: number recognition tools Newsgroups: alt.sources In-Reply-To: Organization: AT&T Bell Laboratories Two serious bugs: 1) The shar file is corrupt: the END-OF-FILE after each man page is preceeded by an "X", causing the next file not to be unshar'ed. Maybe the original files were not terminated by a NL. 2) Executing "getnumber -100e-2" dumps core on a 3B2 and a 6386WGS running SVR3.2. The problem is you don't malloc enough space for the right side of an infix expression: Line 218 of number.c: right = malloc ... InfixStrLen))); should be: right = malloc ... InfixStrLen))+1); I suspect that other systems treat malloc(0) as malloc(1). Please fix these bugs and/or post this message: my newsserver discourages postings. -- Andy Glew, aglew@uiuc.edu