2006/12/14, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Alexey Varlamov wrote: > 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. So we have it now, and you want to take it away because of it's similarity to a Java API?
The point is not a similarity per se, but consistency of the Java system properties and underlying VM properties. I may miss the point behind the VMI facilities for system properties, but in my understanding they are intended to backup Java properties. So this is a standard Java<>native communication.
I'm not understanding yet what the harm is in having this facility. geir
