RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

[David DeHaven]

>> I don't know Cocoa memory management but from a quick look at the
>> NSAutoreleasePool docs then what you seems to be right. Folks on
>> macosx-port-dev would be better to comment on that.
> 
> Perhaps Dave could comment?

The use of NSAutoreleasePool is fine in this case.


>> I see that createUTF8CString doesn't handle malloc failing and it's
>> not clear how CFStringGetCString behaves when called with NULL. In
>> any case, this is all early startup and if we have malloc failing
>> this early then we aren't going to get very far.
> 
> Right.

CFStringGetCString does not handle NULL CFString, it will seg fault. We do a NULL check before calling it though so we're safe.


>> One comment on the error case (fallback to "?") as this is now
>> duplicated. It might be better to have this fallback in one place
>> (GetJavaProperties) as I'm pretty sure we'll need to re-examine it
>> at some point
> 
> Done, new webrev is here:
> 
> http://cr.openjdk.java.net/~bchristi/7199674/webrev.01/

Everything looks fine to me.



>> I am surprised that strdup isn't needed for the constant "?" string
>> but java_props_md.c seems to include other constant strings in sprops
>> so I will assume it is just never deallocated in the lifetime of the
>> JVM.
> 
> My understanding is that C string literals go into static storage, and live for the life of the program.

Yes, they end up in a read-only TEXT section of the executable, they cannot be deallocated without unloading the entire binary.

-DrD-