Question about os::getenv()

[Jeremy Manson]

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?

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

Jeremy

On Wed, Mar 4, 2015 at 3:45 PM, David Holmes <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
>>
>> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150304/803ce386/attachment-0001.html>