RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]
david.dehaven at oracle.com
Fri Sep 13 17:36:20 UTC 2013
>> 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.
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:
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
> 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.
More information about the core-libs-dev