On Sun, 31 Oct 1999, Brad Spencer 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.
> 
> I am the one who wrote the original PR and can confirm the above
> behavior.  The buffer returned is junk.
> 
> The problem almost seems to be prom version dependent, as it does not
> appear to exist on any of my other Suns [if I recall correctly], only on
> my SS2.  I would also state that the eeprom command says that input-device
> and output-device are set to ttya.

FWIW, the prom version on my SS2 is 2.2.

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.

-brian.
--- Brian Chase | bdc@world.std.com | http://world.std.com/~bdc/ -----
All math equations have a fistfight on at least one side.  -- K.