Rejecting one hard problem and replacing it with another method that is officially documented to be worse isn't really a solution.

Note the standard:

https://pubs.opengroup.org/onlinepubs/009604499/functions/se...

> The setenv() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe.

With the increased use of PIE, thunks for both security and due to ARM + the difference between glibc and musl, plus busybox and you have a huge mess.

I would encourage you to play around with ghidra, just to see what return oriented programming and ARM limits does.

Compilers have been good at hiding those changes from us, but the non-reentrant nature will cause you issues even without threads.

Hint, these thunks can get inserted in the MI lowering stage or in the linker.

But setenv() is owned by posix, with only getenv() being differed to cppr.

Perhaps someone could submit a proposal on how to make it reentrant to the Open Group. But it wasn't really intended for maintaining mutable state so it may be a hard sell.

> replacing it with another method that is officially documented to be worse isn't really a solution

Agreed, 150%. My comment had more to do with rejecting files than it did with embracing environ as a suitable alternative.

SQLite is likely the most trouble-free option at the moment.

With that being said, it would be nice to see Android's sys/system_properties.h ported to GNU/Linux proper and, from there, other Unixen.

> I would encourage you to play around with ghidra, just to see what return oriented programming and ARM limits does.

Having worked professionally in reverse engineering at DoD, I can assure you that this is something I'm intimately familiar with.

Files and environ are bad.

That applies mostly to databases using the filesystem.

For configuration files, the write-fsync-move strategy works fine. Generally you don't need fsync, since most people don't use the file system settings that allow data writes to be reordered with the metadata rename.