Question about os::getenv()

[Jeremy Manson]

Martin points out that getenv on Windows isn't portable (which is to say,
it doesn't work on WindowsRT).  Do we care?  If so, then I'll have
os::getenv do an allocation on Windows, and have it return a unique pointer
like thing.  (Of course, I have no way of testing that).

Jeremy

On Wed, Mar 4, 2015 at 5:12 PM, David Holmes <david.holmes at oracle.com>
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.
>
>  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
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20150305/4a0eb7db/attachment-0001.html>