6 ms·

> People don't like APIs that can randomly crash your program while there's no good technical reason for why they should. Why not fix the problem? I think you'

> People don't like APIs that can randomly crash your program while there's no good technical reason for why they should. Why not fix the problem? I think you're not seeing this from the right POV. People that consume POSIX API need to know POSIX API. https://pubs.opengroup.org/onlinepubs/009604499/functions/setenv.html https://pubs.opengroup.org/onlinepubs/009604499/functions/se... It says loud and clear "The setenv() function need not be reentrant. A function that is not required to be reentrant is not required to be thread-safe." > "The unpredictable crashes only happen very rarely" doesn't mean the crashes go away. If you get a crash over setenv() reading the manual page of setenv C call should be your first step. And the only step. The bigger issue is in design of application that has wrongly assumed setenv() is thread-safe. That requires a refactoring and is solely due to developer misunderstanding the API.

loup-vaillant 3y ago
You’re blaming the victim here. Not being re-entrant makes the user-facing API unnecessarily complicated. It creates an avoidable foot gun. It trips people up for no good reason. And unlike stuff like signed integer overflow, there doesn’t even seem to be a (dubious) performance argument to justify this insanity. The standard should be fixed and that’s the end of it.
tikhonj 3y ago
"RTFM" is not a coherent defense for awful API design and we shouldn't accept it as such.
- zare_st 3y ago
  Who is "we"? I'm a UNIX/C programmer for decades and I don't care about this. There is no such thing as beautiful API design. Every design is a compromise. If you think non-reentrant calls should be deprecated in POSIX take it to the committee. There is a myriad of non-reentrant code both in POSIX spec and in libc implemenations. You need to RTFM, I'm sorry. There is no "coherent API" as far as null termination goes too. Some library functions deal with it, some calls don't. You need to RTFM. I also want to know OP's reason to even use setenv() in a multithreaded piece of software. It's like an oxymoron. setenv and vars are useful to pass on data from parent process to forked children because they inherit the environment. If you use the threading model you don't need it. If your application is a single process setenv() is useless.
- usrbinbash 3y ago
  What should we accept? That every library is made under the assumption that it has to work as expected, even if people ignore the documentation? As someone who made and maintains multiple libraries: No. Not gonna happen.
- JohnFen 3y ago
  Putting aside whether or not the design is awful, the fact that it's standardized and documented is absolutely a valid argument. Changing it now would break backward compatibility. That should always be a showstopper. Programmers who are using any library code without reading and understanding the documentation are asking for trouble regardless of language. The correct solution to your objections is to create new functions that behave as you prefer.

loup-vaillant 3y ago

You’re blaming the victim here. Not being re-entrant makes the user-facing API unnecessarily complicated. It creates an avoidable foot gun. It trips people up for no good reason. And unlike stuff like signed integer overflow, there doesn’t even seem to be a (dubious) performance argument to justify this insanity. The standard should be fixed and that’s the end of it.

tikhonj 3y ago

"RTFM" is not a coherent defense for awful API design and we shouldn't accept it as such.

zare_st 3y ago
Who is "we"? I'm a UNIX/C programmer for decades and I don't care about this. There is no such thing as beautiful API design. Every design is a compromise. If you think non-reentrant calls should be deprecated in POSIX take it to the committee. There is a myriad of non-reentrant code both in POSIX spec and in libc implemenations. You need to RTFM, I'm sorry. There is no "coherent API" as far as null termination goes too. Some library functions deal with it, some calls don't. You need to RTFM. I also want to know OP's reason to even use setenv() in a multithreaded piece of software. It's like an oxymoron. setenv and vars are useful to pass on data from parent process to forked children because they inherit the environment. If you use the threading model you don't need it. If your application is a single process setenv() is useless.
usrbinbash 3y ago
What should we accept? That every library is made under the assumption that it has to work as expected, even if people ignore the documentation? As someone who made and maintains multiple libraries: No. Not gonna happen.
JohnFen 3y ago
Putting aside whether or not the design is awful, the fact that it's standardized and documented is absolutely a valid argument. Changing it now would break backward compatibility. That should always be a showstopper. Programmers who are using any library code without reading and understanding the documentation are asking for trouble regardless of language. The correct solution to your objections is to create new functions that behave as you prefer.