Don't setenv in multi-threaded code on glibc

Re:Don't setenv in multi-threaded code on glibc by quotemstr on Tuesday January 31, 2017 @01:12PM (#13533406)

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.

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by pjmlp on Tuesday January 31, 2017 @03:09PM (#13534720)

Portability across UNIX platforms.

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by quotemstr on Tuesday January 31, 2017 @03:36PM (#13534946)

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

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by pjmlp on Tuesday January 31, 2017 @05:05PM (#13535715)

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.

[ Parent | on HN ]

Re:Don't setenv in multi-threaded code on glibc by quotemstr on Tuesday January 31, 2017 @05:25PM (#13535901)

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.

[ Parent | on HN ]