Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ames!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.sources.d
Subject: Re: Obscure Not-Quite-Bug in Compress
Message-ID: <11982@mimsy.UUCP>
Date: 15 Jun 88 23:54:10 GMT
References: <51610@ti-csl.CSNET>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 43

In article <51610@ti-csl.CSNET> pf@csc.ti.com (Paul Fuqua) writes:
>	/* high order bits. */
>	code |= (*bp & rmask[bits]) << r_off;
>
>*bp reads the word just off the end of buf, but rmask[bits] is always 0
>in this case, so the word is unimportant and everything works.
>     This bit caused me trouble because Common Lisp bounds-checks array
>references .... My correction was to check for rmask[bits] == 0 before doing
>the above, so bp wouldn't reference off the end.  C, of course, doesn't
>bounds-check, especially not when using pointers, and this bit of code
>has been happily running on countless machines.
>     Is this a bug or a feature?  I have my own opinion.

It is a bug, and it is not a `feature of C'; any legal C compiler could
produce a runtime error message to the effect of `reference outside of
address space'.

I would handle this by making the buffer one larger, so that there
is always something to read, even if it is not used.  For instance,
in my `PK' font reading code:

			if (rowsize < wb) {	/* get more row space */
				if (row)
					free(row);
				/* keep a slop byte */
				row = malloc((unsigned) (wb + 1));
				if (row == NULL)
					return (-1);	/* ??? */
				rowsize = wb;
			}

			...
					/*
					 * Finally, begin a new byte, or
					 * add to the current byte, with
					 * j more bits.	 We know j <= 8-b.
					 * (If j==0, we may be writing on
					 * our slop byte, which is why we
					 * keep one around....)
					 */

-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris