🚀 go-pugleaf

In article <16534@sun.uucp>, tut%cairo@Sun.COM (Bill Tuthill) writes:
> Brian Kernighan's first
> ditroff worked without changes; DWB 1.0 ditroff (which was really
> Brian's ditroff with Makefiles changed to fubar.mk files) worked
> without changes.  This one core dumps.
> 
> This is the line that causes a segmentation violation (or memory
> fault) because i is way off the end of the array:
> 
>   if ((j = fitab[xfont][i] & BYTEMASK) == 0) { /* it's not on current font */

i had to install the original ditroff on a sun-3 here, and found that a
nearly identical line dumped core on the sun.  it worked okay on a vax under
bsd.  the rationale, as i got it from some of our kernel people, is that
memory location zero under bsd always contains a zero (for people who don't
check for null char *'s, i guess).  this isn't the case uner sun unix.
since fitab is init'ed to all zeroes, looking at a fitab entry that's
not loaded yet indirects through mem loc zero.  under sun unix, this
sort of indirect addressing is intergalactic.

xfont, in your example, is the number of the loaded font you're checking.
i is the character code.

i hacked in some bounds checking, so that i never looked at any fitab
entries i hadn't installed myself.  note that my problem, and its solution,
depended on the value of xfont -- not the value of i.

i could dig up the original code, and my fix, if you want it.  it's
probably simple enough to chase down on your own, though.  (given your
original diagnosis, it's not even clear that my changes would fix your
problem.  worth a look, though).

					mike olson
					britton lee, inc.