É seguro o uso getenv () em inicializadores estáticos, isto é, antes de main ()?

Question

Eu olhei em Stevens , e na Guia do Posix programador , eo melhor que posso encontrar é

Uma matriz de strings chamado ambiente é disponibilizado quando o processo começa. Esta matriz é apontada pelo environ variável externa, a qual é definida como:

extern char **environ;

É que environ variável que tem me hesitar. Eu quero dizer

-O chamando processo / shell já alocou o bloco de terminação nula cordas

-a 'externo' environ variável é usada como ponto de entrada pela getenv () .

-. ipso facto não hesite em chamar getenv () dentro de um inicializador estático

Mas eu não posso encontrar qualquer garantia de que o 'inicialização estática' de environ precede todos os outros código de inicialização estática. Am I cismar isso?

Atualização

Em minha plataforma (AMD Opteron, Redhat 4, GCC 3.2.3), estabelecendo LD_DEBUG mostra que environ é definido antes meus inicializadores estáticos são chamados. Isso é uma coisa agradável saber; graças, @codelogic. Mas não é necessariamente o resultado que eu ia ficar em todas as plataformas.

Além disso, enquanto eu concordo intuitivamente com @ChrisW sobre o comportamento do C ++ runtime biblioteca / C, esta é apenas a minha intuição baseada na experiência. Então, quem pode canalizar-se com uma citação de um lugar de autoridade garantindo que environ é lá antes inicializadores estáticos são chamados, pontos de bónus!

Answer 1

Eu acho que você pode executar o programa com o conjunto LD_DEBUG para ver a ordem exata:

LD_DEBUG=all <myprogram>

EDIT: Se você olhar para o código-fonte do vinculador em tempo de execução (glibc 2.7), especificamente em arquivos:

• sysdeps / unix / sysv / linux / init-first.c
• sysdeps / i386 / init-first.c
• CSU / libc-start.c
• sysdeps / i386 / Elf / start.S

Você vai ver que argc, argv e environ (alias para __environ) são definidas antes de qualquer construtores globais são chamados (as funções de inicialização). Você pode acompanhar a execução começando desde _start, o ponto de entrada real (start.S). Como você citou Stevens "Uma matriz de strings chamado o ambiente é disponibilizado quando o processo começa" , sugerindo que a atribuição ambiente acontece no início do processo de inicialização. Isto apoiado pelo código vinculador, que faz o mesmo, deve dar-lhe a paz suficiente de mente: -)

EDIT 2: Também vale a pena mencionar é que environ é definida com antecedência suficiente que mesmo o vinculador tempo de execução pode consultá-lo para determinar se deve ou não saída verbosely (LD_DEBUG)

.

Answer 2

Tendo em conta que tanto a configuração do ambiente e a invocação dos inicializadores estáticos são funções que a linguagem tempo de execução tem de realizar antes main () é invocado, não estou certo que você encontrará uma garantia aqui. Ou seja, eu não tenho conhecimento de um requisito específico aqui que este tem para o trabalho e que a ordem é garantida antes do main () em, por exemplo, a linguagem ANSI e especificações de biblioteca ou qualquer coisa ... .mas eu não verificar para se certificar de qualquer um.

Ao mesmo tempo, eu não tenho conhecimento de um requisito específico que restringe quais funções de biblioteca de tempo de execução pode ser chamado de um inicializador estático. E, mais ao ponto, ele se sentiria como um erro de tempo de execução (para mim) se você não poderia acessar o ambiente de um.

Nesta base, eu voto que eu esperaria que isso funcione, é uma suposição segura, e pontos de dados atuais parecem apoiar esta linha de raciocínio.

Answer 3

Em minha experiência, a biblioteca de tempo de execução C é inicializado antes que os invoca em tempo de execução dos inicializadores de suas variáveis ??estáticas (e para que seus initializers pode chamar funções de biblioteca de tempo de execução C).