在静态初始化器中使用getenv（）是安全的，也就是说，在main（）之前？ [英] Is it safe to use getenv() in static initializers, that is, before main()?

问题描述

我看过 Stevens ，并在 Posix程序员指南，最好的可以找到

当进程开始时，称为 enviroment 的字符串数组可用。
此数组由外部变量 environ 指向，其定义为：

extern char ** environ;

变量让我犹豫。我想说

- 调用进程/ shell已经分配了空的已终止字符串块

getenv（）

时，'external'变量 environ 作为入口点。

- ipso facto 随时在静态初始化程序中调用 getenv（）。

找到任何保证 environ 的'静态初始化'先于所有其他静态初始化代码。

在 平台（AMD Opteron， ）上更新

< Redhat 4，GCC 3.2.3），设置 LD_DEBUG 表示在调用我的静态初始化器之前 设置 。这是一个很好的事情要知道;谢谢，@codelogic。

此外，虽然我直观地同意@ChrisW对C / C ++运行时库的行为，这只是我根据经验的直觉。所以任何人都可以管理一个权威的报价，保证 environ 在静态初始化被称为奖励点之前。

解决方案

我认为你可以运行你的程序与LD_DEBUG设置，看到确切的顺序：

  LD_DEBUG = all< myprogram> 
  

EDIT：
如果您查看源代码运行时连接器（glibc 2.7），特别是在文件中：

• sysdeps / unix / sysv / linux / init-first.c


• sysdeps / i386 / init-first.c


• csu / libc-start.c


• sysdeps / i386 / elf / start.S

您将看到argc，argv和environ（ __ environ）在调用任何全局构造函数（init函数）之前设置。您可以从_start开始执行开始，即实际进入点（start.S）。正如你所引用的Stevens 当进程开始时，可​​以使用名为环境的字符串数组，这表明环境赋值在进程初始化的开始时发生。在链接器代码的支持下，这样做会给你足够的安心： - ）

编辑2：是environ设置得足够早，即使运行时连接器可以查询它以确定是否输出详细（LD_DEBUG）。

I looked in Stevens, and in the Posix Programmer's Guide, and the best I can find is

An array of strings called the enviroment is made available when the process begins. This array is pointed to by the external variable environ, which is defined as:

extern char **environ;

It's that environ variable that has me hesitating. I want to say

-The calling process/shell has already allocated the block of null terminated strings

-the 'external' variable environ is used as the entry point by getenv().

-ipso facto feel free to call getenv() within a static initializer.

But I can't find any guarantee that the 'static initialization' of environ precedes all the other static initialization code. Am I overthinking this?

Update

On my platform (AMD Opteron, Redhat 4, GCC 3.2.3), setting LD_DEBUG shows that environ gets set before my static initializers are called. This is a nice thing to know; thanks, @codelogic. But it is not necessarily the result I'd get on all platforms.

Also, while I agree intuitively with @ChrisW on the behavior of the C/C++ runtime library, this is just my intuition based on experience. So anyone who can pipe up with a quote from someplace authoritative guaranteeing that environ is there before static initializers are called, bonus points!

解决方案

I think you can run your program with LD_DEBUG set to see the exact order:

LD_DEBUG=all <myprogram>

EDIT: If you look at the source code of the runtime linker (glibc 2.7), specifically in files:

• sysdeps/unix/sysv/linux/init-first.c
• sysdeps/i386/init-first.c
• csu/libc-start.c
• sysdeps/i386/elf/start.S

you will see that argc, argv and environ (alias for __environ) are set before any global constructors are called (the init functions). You can follow the execution starting right from _start, the actual entry point (start.S). As you've quoted Stevens "An array of strings called the enviroment is made available when the process begins", suggesting that environment assignment happens at the very beginning of the process initialization. This backed by the linker code, which does the same, should give you sufficient peace of mind :-)

EDIT 2: Also worth mentioning is that environ is set early enough that even the runtime linker can query it to determine whether or not to output verbosely (LD_DEBUG).

这篇关于在静态初始化器中使用getenv（）是安全的，也就是说，在main（）之前？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！