setenv()与putenv()：跨平台环境变量编辑该选哪一个？

Let's cut through the confusion here—you're weighing two environment variable functions for a cross-platform scripting language, with concerns about compatibility, that old Stack Overflow take, and Windows' confusing deprecation note. Here's what you need to know to make the right call:

Core Differences That Matter #

First, forget the platform talk for a second—these functions behave very differently, and that's a bigger deal than cross-platform support:

• putenv(const char*): Takes a single KEY=VALUE string, and here's the trap: most implementations don't copy this string. They just store a pointer to it. So if you pass a stack-allocated string or a temp that gets freed later, you'll end up with dangling pointers and undefined behavior. You have to keep that string in memory for as long as the env var exists—total headache for a scripting language where vars might be added/removed dynamically.
• setenv(const char*, const char*): Takes separate key and value arguments, and internally copies both strings. No dangling pointer risk, plus it has an optional third parameter (usually 1 to overwrite existing vars) that makes its behavior clear and intentional. Way safer for most use cases.

Platform Support: The Real Story #

That Stack Overflow answer you relied on is probably outdated. Let's set the record straight:

• Unix-like systems: setenv is part of the POSIX.1-2001 standard (introduced in 2001), so it's supported by every modern Linux, BSD, and macOS system. putenv is actually an XSI extension (not core POSIX), so setenv is the more standard, portable choice here.
• Windows: You're right that Windows CRT supports setenv—but that deprecation note in VS2017's MSDN isn't as scary as it sounds. Microsoft marks POSIX-compatible functions like setenv as deprecated because they want you to use their "secure" CRT variants (like _setenv_s) which add extra error checking. But setenv still works perfectly in all recent VS versions, and was added around VS2015.

Backward Compatibility Checks #

If your scripting language needs to run on older systems:

• Legacy Unix-like systems: setenv has been around for 20+ years, so even systems from the early 2000s should have it. Only if you're targeting extremely ancient pre-2001 POSIX systems would you need a fallback to putenv—and that's a niche case these days.
• Pre-VS2015 Windows: setenv isn't available here. You'll need to fall back to putenv (or Windows' _putenv) but make sure to dynamically allocate the KEY=VALUE string (don't use stack memory) to avoid those dangling pointer bugs.

My Recommendation #

Here's a practical, safe approach for your project:

1. Make setenv your primary choice: It's safer, more explicit, and the standard for POSIX systems.
2. Add conditional compilation for Windows:
   • For VS2015 and newer: Stick with setenv (or switch to _setenv_s if you want to follow Microsoft's guidelines—just note this adds platform-specific code).
   • For older Windows versions: Fall back to putenv with heap-allocated KEY=VALUE strings, and make sure to manage that memory properly to avoid leaks or crashes.
3. Avoid putenv as your default: Its memory management gotchas are way too easy to mess up, especially in a scripting language where environment variables are likely to be modified frequently.

内容的提问来源于stack exchange，提问作者Ingwie Phoenix