[Webkit-unassigned] [Bug 192405] [WTF] Add environment variable helpers

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=192405

Fujii Hironori <Hironori.Fujii at sony.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Hironori.Fujii at sony.com

--- Comment #3 from Fujii Hironori <Hironori.Fujii at sony.com> ---
Accounting to the glibc document, it is safe to call getenv in multiple threads, but not safe with other libc.

https://www.gnu.org/software/libc/manual/html_node/Environment-Access.html

> This function returns a string that is the value of the
> environment variable name. You must not modify this string. In
> some non-Unix systems not using the GNU C Library, it might be
> overwritten by subsequent calls to getenv (but not by any other
> library function). If the environment variable name is not
> defined, the value is a null pointer.


glib document also mentions the next g_getenv call may overrite the previous buffer.

https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-getenv

> the value of the environment variable, or NULL if the environment
> variable is not found. The returned string may be overwritten by
> the next call to g_getenv(), g_setenv() or g_unsetenv().

Following links are also interesting.

0000188: thread-safe getenv() - Austin Group Defect Tracker
http://austingroupbugs.net/view.php?id=188

Bug 659326 – implement g_app_launch_context_get_environment for win32
https://bugzilla.gnome.org/show_bug.cgi?id=659326

I think we shouldn't assume glibc's behavior. 
We should avoid using getenv in WebKit.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20181206/a0897981/attachment.html>