java.library.path fix for MacOS X (7145798)

[Paul Hohensee]

I agree with your rationales.  You're good to go afaic.

Paul

On 2/17/12 5:34 PM, Daniel D. Daugherty wrote:
> On 2/17/12 3:27 PM, Paul Hohensee wrote:
>> Looks good.
>
> Thanks! And thanks for the fast review!!
>
>
>> A nit: you could use %s:%c in the sprintf format string, vis,
>>
>>     sprintf(ld_library_path, "%s:%c", t, '.');
>>
>> which would save allocating the "." string.
>
> I went back and forth on that... I decided it was better to match
> all the other code that assembles the ld_library_path in this
> function... all of those format string patterns are "%s:%s"...
>
>
>> Are there any security issues with using dot on a search path?
>
> I don't think so. We explicitly decided to keep "." in the
> java.library.path on Windows last year when we went through
> the whole LoadLibrary security fire drill... We did move it
> to the end of java.library.path though which is why I did
> the same on MacOS X.
>
> Also, having "." in the java.library.path is what Apple's Java6
> does so we want to ease transition there...
>
> Dan
>
>
>
>
>>
>> Paul
>>
>> On 2/17/12 5:06 PM, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> Apple's version of Java includes "." in the java.library.path
>>> at the beginning. OpenJDK includes "." at the end of
>>> java.library.path on Windows. On Linux and Solaris, "." is
>>> not included at all.
>>>
>>> In the MacOS X port project, the relevant code was copied from
>>> Linux so "." is not present in java.library.path. This should
>>> be changed to make the OpenJDK7 version on MacOS X behave
>>> similar to the Apple version of Java6.
>>>
>>> Here is the webrev URL:
>>>
>>> http://cr.openjdk.java.net/~dcubed/7145798-webrev/0/
>>>
>>> There more lines of comment in there than code...
>>>
>>> Thanks, in advance, for any feedback.
>>>
>>> Dan
>>>