Question about os::getenv()

[David Holmes]

On 5/03/2015 11:12 AM, David Holmes wrote:
> On 5/03/2015 10:07 AM, Jeremy Manson wrote:
>> I'm happy to s/os::getenv/getenv/g if we know it works on Windows.  I
>> assumed that there was some safety / security reason for requiring the
>> copying - otherwise, why does this interface exist at all?
>
> I don't know. Someone else (perhaps on hotspot list rather than
> serviceability) may, but I'd have to do a bit of archaeology to find out.

Arguments::parse_options_environment_variable itself requires a copy as 
it rewrites the value of the variable in to the format needed.

I also checked back and in 1.3 we used getenv but then applied strdup 
(and win32 used getenv too). But when hotspot turned up in 1.4 it has 
the os::getenv copying into a supplied buffer.

Cheers,
David

>> If everyone's happy about this, I'll go ahead and file a bug / send in a
>> patch, with the understanding that someone else has to test on non-Linux
>> platforms...
>
> Sure. Do the patch and I'll run it through JPRT. If you need testing
> other than Solaris and Windows then others will need to step up. :)
>
> Cheers,
> David
>
>> Jeremy
>>
>> On Wed, Mar 4, 2015 at 3:45 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.com>> wrote:
>>
>>     Hi Jeremy,
>>
>>
>>     On 5/03/2015 6:14 AM, Jeremy Manson wrote:
>>
>>         Hey folks,
>>
>>         We had a request internally to make it so that JAVA_TOOL_OPTIONS
>>         could
>>         accept something longer than 1024 characters.  See:
>>
>>         Arguments::parse_options___environment_variable(const char* name,
>>         SysClassPath* scp_p, bool* scp_assembly_required_p)
>>
>>         in
>>
>>
>> http://hg.openjdk.java.net/__jdk9/jdk9/hotspot/file/__27f0413cbea3/src/share/vm/__runtime/arguments.cpp
>>
>>
>> <http://hg.openjdk.java.net/jdk9/jdk9/hotspot/file/27f0413cbea3/src/share/vm/runtime/arguments.cpp>
>>
>>
>>         Would you folks be amenable to a refactoring so that getenv
>>         returns a
>>         newly allocated array with the contents of the envvar, which the
>>         caller
>>         has to delete?
>>
>>
>>     I think this gets used too early in the VM startup to use the VM's
>>     allocation routines (ie with NMT support) - not 100% sure though.
>>
>>     But I think I have to agree with Martin and wonder why we have this
>>     copying interface around getenv, rather than using the result of
>>     getenv directly? Any code that really wants to modify the returned
>>     value can copy it for themselves. That would alleviate the hard
>>     wired limits.
>>
>>     getenv is available on Windows too.
>>
>>     David
>>
>>         Jeremy
>>
>>