Question about os::getenv()

[David Holmes]

On 6/03/2015 4:10 AM, Jeremy Manson wrote:
> 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).

Many of the win32 APIs we use in the VM are not available in WindowsRT. 
So I don't think that is an issue.

David
-----

> Jeremy
>
> On Wed, Mar 4, 2015 at 5:12 PM, David Holmes <david.holmes at oracle.com
> <mailto: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>
>         <mailto: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>
>
>         <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
>
>
>