On Thu, Jan 2, 2014 at 2:43 AM, Olivier Danet odanet@caramail.com wrote:
I may have found a bug in OpenBIOS.
An OS uses the "nextprop" iterator to scan device properties, and eventually asks about nonexistant properties. "const char *obp_nextprop(int node, const char *name)" (arch/sparc32/romvec.c) calls the "next-property" forth code, then pops the result. According to the standard, next-property should return 0 if the property selected is the last _OR_ if the property does not exist. The current code in forth/admin/devices.fs returns nothing when the property does not exit.
For example (SPARC 32) :
cd screen " name" ?active-package next-property drop cr type --> returns "device_type"
" interrupts" ?active-package next-property --> returns 0, this is the last property.
" bozo" ?active-package next-property --> returns nothing. Which, imho, is wrong.
Actually this matches pretty much with what OBP does:
ok showstack ok " model" current-device next-property fffe61e8 4 ffffffffffffffff ok drop type name ok " bozo" current-device next-property ok
Artyom
Here is a patch, I am not quite sure about it (debuting Forth) but it helps the target OS :
Index: forth/device/property.fs
--- forth/device/property.fs (révision 1246) +++ forth/device/property.fs (copie de travail) @@ -70,7 +70,7 @@ 2drop r> >dn.properties @ else r> find-property dup if @ then
- ?dup if >prop.next @ then
dup if >prop.next @ then then
?dup if
===================================================================
The standard asks for a pointer to a zero lenght string instead of zero, the C code obp_nextprop() expects a zero. I don't know if it makes a difference.
Olivier (Btw, the OS is NetBSD :-)
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you