Subject: Re: port-sparc/7409
To: Brad Spencer <brad@anduin.eldar.org>
From: Brian D Chase <bdc@world.std.com>
List: port-sparc
Date: 10/31/1999 20:15:27
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.