> Because as anyone doing POSIX development across multiple OS learns, that is an implementation detail.

The problem is the interface is naturally unsafe. Much like e.g. strcpy, the interface means it's nigh impossible to use it safely.

Which is the reason that even if we would write an UNIX OS in something like Ada or Rust instead of C, we wouldn't get away from security exploits caused by the UNIX API.

Hence why in parallel with better systems languages, we really need tagged architectures for pointers, like what SPARC V8, Intel MPX, Cherry offer, to become widespread, for better security.

Upthread, I pointed out a sane and safe alternative to POSIX getenv interface, one that works fine with regular C, and here, you're claiming that we need exotic features to achieve safety? What?

Because you only focused on getenv.

I was replying about the whole UNIX API surface, regarding functions like strcpy.

You need exotic features to guarantee that the memory doesn't get corrupted.

The posix standard explicitly says setenv is not thread safe. This shouldn't be a mystery.

Isn't the issue here that setenv breaks getenv rather than setenv "not being thread-safe"?

The issue is that getenv's API is fundamentally unsafe. setenv is fine.

But it should be. And we can make it thread safe very easily. Why the hell should we be limited by POSIX? Why can't we provide features beyond it?

It's access to the environ global that's inherently unsafe. setenv and a modified getenv can be accommodated just fine.

Portability across UNIX platforms.

So portability to you, means that the platform can't add features? I reject portability then.

To me? No, to everyone.

Lets say GNU/Linux does that, what you would do for other UNIX flavours, #ifdef soup?

The goal of standards is exactly to minimize that.

Ifdefs would be required. Or some kind of wrapper in gnulib. Or, like systemd, just non-portability. Your philosophy means stagnation forever. I reject that. Programs that use getenv today will not break. Objection to the existence of a getenv_s is absurd.

The only way we move forward is by trying new things, and we can't possibly get everyone to try a new thing all at once. If the thing ends up being useful, we standardize it.

Back when I cared about POSIX (early 2000's) the difference between what POSIX stated and what UNIX systems offered wasn't always the same.

I guess the situation might have improved.

Actually, it says that it need not be thread-safe. It does not prohibit a good implementation from making it thread-safe anyway.