2006/12/13, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Gregory Shimansky wrote: > Alexey Varlamov wrote: >> 2006/12/13, Gregory Shimansky <[EMAIL PROTECTED]>: >>> Tim Ellison wrote: >>> > Alexey Varlamov wrote: >>> >> Is there any reason to distinguish these cases? I suppose no, then >>> >> returned NULL is fine. >>> > >>> > 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? >> >> Some properties may act as a flag, e.g. -Djava.lang.SecurityManager. >> However, they have empty value in RI (interestingly, DRLVM ignores >> such arguments - must be a bug). So NULL value is still enough to >> indicate no such property is set. > > I don't see how we can distinguish such properties in drlvm using just > one function get_property(const char*, PropertyTable). It either returns > a valid pointer to the property string value or NULL. > > Also empty value in my understanding is still a valid value "". yes, but NULL and "" are still two different things. I suspect that we should simply modify the API to have return code : int status = get_property(const char* key, const char **value, table) so you can see if the key exists if you care. You may not care. Or, add a new method int status = has_key(char *key); depending on whatever criterion we use for this API.
There is such API: VMEXPORT int is_property_set(const char* key, PropertyTable table_number); Actually, NULL property values are allowable in drlvm just historically, I see no strong reason to retain this.
geir >
