harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@gmail.com>
Subject Re: [classlib][luni] update for bootstrapClassPath causes regression on DRL VM
Date Wed, 13 Dec 2006 13:11:10 GMT
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?


View raw message