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.hol...@oracle.com
<mailto:david.hol...@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
