C 哪些代码可能对环境（变量）敏感？

我这里有一些（遗留）代码，似乎在

LD_LIBRARY\u PATH

上调用

setenv

（编译时不知道该值，实际上它将从命令行获得），现在我必须将其移植到windows。我的怀疑是，

setenv

只是出于历史原因，它不再具有实际效果，我想证实这一点

因此，我的方法是审查环境的所有用途，看看是否有任何用途会受到

LD\u LIBRARY\u PATH

（或任何其他）的影响。因此，我认为除非调用

environ

变量或某些函数，否则代码将对环境不敏感（直接、间接或在后续代码中）

我（作为候选者）确定的职能包括：

• getenv

• exec*

• popen

• 系统

• dlopen

  和朋友
• 仅依赖于

  TZ

  变量的时间函数
• 依赖于区域设置且仅检索当前区域设置的函数

包含

getenv

的原因显而易见，因为后续代码可能取决于环境变量的值<代码>exec*，

popen

和

系统

被包括在内，因为首先（子）程序的链接可能会受到环境的影响，但（子）程序本身也可能依赖于环境，

dlopen

我认为会搜索

LD_LIBRARY_路径

（这里也有可能链接库本身在初始化期间或稍后访问环境）。其余的原因是我知道标准库中的很多地方都在使用

TZ

和locale

我是否错过了一些函数或代码可能依赖于环境的其他情况？当然，我意识到这受到加载的库的影响，但据我所见，只有“标准”库加载加上

libsqlite3

（加上

libpthread

，

libdl

和

libm

）。我猜SQLite3可能对某些环境变量很敏感，但

LD\u LIBRARY\u PATH

是其中之一吗

---

为了记录这一次，程序似乎没有包括

exec*

或

dlopen

，但我包括了它们，因为在另一种情况下它们可能会出现。

您应该检查每个函数的文档。这清楚地表明它使用

LD\u LIBRARY\u PATH

作为搜索列表来定位共享库

在任何情况下，当您可以指定路径作为

dlopen

的参数时，强制加载特定库似乎是一种相当笨拙的方法

---

除此之外，它是GNU链接器

ld

用来定位静态库的一个值。因此，您的应用程序使用它的可能性较小，但可能是因为它启动链接器或其他使用

dlopen

的进程，例如，它可以通过

exec

、

popen

或

system

来执行尽管您的代码具有所有这些功能，但很明显它正在启动一些外部进程。

dlopen让我怀疑您的应用程序特定库是否是从LD_LIBRARY_PATH打开的。我接下来要做的是查看安装并检查LD_LIBRARY_PATH中使用的路径。检查a指向的所有位置应用程序和库存在于其中。@Pradheep恐怕不可行。编译时，

LD\u LIBRARY\u PATH

设置为的值未知。为什么不将其打印到任何日志中，检查路径或在gdb中加载程序呢？gdb更容易，并且在设置数值格式依赖于l时检查值ocale。时间、日期、货币格式取决于区域设置。某些排序（排序）算法取决于区域设置。字符分类取决于区域设置（数字、上限、下限等）。标准C库涵盖了大部分内容（货币格式化没有用于任务的标准C函数，但必要的信息存储在区域设置信息中）@JonathanLeffler是的，这就是为什么我一般都包括它们。我希望这些函数也不依赖于

LD_LIBRARY_PATH

。当您想要强制加载特定的库时，LD_LIBRARY_PATH有很多有效的使用案例，例如，

dlopen

调用不在您的控制之下的任何时候，例如当它是我的时候在第三方库中或当它处于单独的过程中时。检查文档是一个好主意。我在手册页上运行了

zgrep

，还找到了

uselib

函数。但是它会错过案例

getenv

和启动其他程序的函数，这些都是依赖

LD\u LIB的潜在方法RARY_PATH

。我想你的问题已经得到了回答；你需要分析代码来确定它为什么这样做。在没有看到代码的情况下，我猜

getenv（）

用于获取当前的

LD_库路径

，它被挂起或附加了一些特定于应用程序的路径，然后用

setenv（）进行设置

在调用

dlopen（）

之前。我认为修改

LD\u LIBRARY\u PATH

的方式将提供信息。您似乎在系统级寻找一些东西，我认为这完全是特定于应用程序的。您选择不发布任何代码，因此我们只能猜测。