On Sun, 31 Oct 1999, Brian D Chase wrote:

> >    I've done some poking around with the driver and found that the line
> > 
> >      cp = getpropstringA(node, prop, buffer, sizeof buffer);
> > 
> >    returns a null string to cp.  When I examined the full length of buffer[]
> >    I found that it was just full of garbage.  I'm still digging my way
> >    through function calls to figure out where things are breaking down.
> > 

	Have you tried reverting the 1.65-1.66 patch, as in
http://cvsweb.netbsd.org/cgi-bin/cvsweb.cgi/syssrc/sys/arch/sparc/dev/zs.c.diff?r1=1.65&r2=1.66&f=u
	(selecting unidiff should make it usable as a patch :)

> I'd also point out that the following code fragment from the zs.c file has
> a certain amount of *badness* inherent to it.  The author makes the
> assumption that they'd be dealing with a string of at least 2
> data characters and one trailing null character.  
> 
>         /*
>          * At this point we assume the device path is in the form
>          *   ....device@x,y:a for ttya and ...device@x,y:b for ttyb, etc.
>          */
>         while (*cp != 0)
>                 cp++;
>         cp -= 2;
> 
> In cases where we've got a string of length 1 or 0, then following the
> decrement by 2, we're pointing at a memory location which isn't part of
> the allocated buffer.  Yech.

	Indeed - its making an assumption that the prom is returning
	a valid entry. I'd agree an extra test is probably worthwhile
	there :)

		David/absolute