>> 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-
