Oliver Deakin wrote:
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
Do we really have a problem? Or is it something else?
Last night, Gregory tested his fix, and I've build snapshots (r486417)
on x86 linux/win and x86_64 linux and spot checked with apps and such,
and things seem to work.
I'n posting the snapshots now to ~geirm and will send a separate note
for people to evaluate.
Also catching up on mail. I suggested (on the other thread) that we
need to define the return result for undefined properties, answering
NULL seemed reasonable, but now I look at the vmiError enum in vmi.h it
appears that we have already defined:
"VMI_ERROR_NOT_FOUND -- The requested system property was not found"
This surprises me slightly - I would have imagined we would want to work
in a similar way
to the System.getSystem() method and return NULL in the case of a
non-existent property
being requested. However, it appears that GetSystemProperty() is
intended to return
VMI_ERROR_NOT_FOUND in this case.
I would say that since the function behaviour in this case has not yet
been clearly spec'ed
(and we have two VMs that behave differently) we should make a choice
now about which
return is correct and fix up the VMs. So, should we just return a NULL
property value and
no error code, or return VMI_ERROR_NOT_FOUND?
I think we have a freedom to change constants specification, and so we
can change the comment for VMI_ERROR_NOT_FOUND so that it doesn't
mention system properties. If we agree on this, I'll change VMI
implementation in drlvm and you'll commit your patch as well as Tim's
clarification for GetSystemProperty.
Does it sound good to you?
--
Gregory
