2006/12/14, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Tim Ellison wrote: > Gregory Shimansky wrote: >> Tim Ellison wrote: >>> Gregory Shimansky wrote: >>>> Tim Ellison wrote: >>>>> Maybe we do, i.e. where there is no value "-Dfoobar". So perhaps we >>>>> need to say that GetSystemProperty returns VMI_ERROR_NONE and sets the >>>>> the *valuePtr to NULL if there is no value; and returns a >>>>> VMI_ERROR_NOT_FOUND if the property is undefined. >>>> Now I am confused. What is the difference between a property which has >>>> no value and an undefined property? >>> Sorry, I meant a property whose value is NULL. So the three cases are: >>> >>> 1) key = "foo", value = "bar" >>> 2) key = "foo", value = NULL >>> 3) no key called "foo" >>> >>> If (2) is disallowed then we should document that in SetSystemProperty(). >> I would prefer to have (2) to be illegal. Can we document this please? > > No objection here. So to attempt a new clarification ... > > GetSystemProperty will return VMI_ERROR_NONE and a string value for > existing properties, or NULL value for a non-existent property. > > We then rename VMI_ERROR_NOT_FOUND to VMI_ERROR_ILLEGAL_ARG and > SetSystemProperty will return VMI_ERROR_NONE for setting an existing > property to a string value, or VMI_ILLEGAL_ARG if there is an attempt to > set the property value to NULL. > > How does that sound? Why again do we want 2 to be illegal? (Sorry, was out of pocket for a while there yesterday...)
This is aligned with the API specification for j.l.System.[s|g]etProperty(), which explicitly disallowes NULLs for both keys and values.
geir
