7 ms·
"RTFM" is not a coherent defense for awful API design and we shouldn't accept it as such.
by tikhonj 3y ago
"RTFM" is not a coherent defense for awful API design and we shouldn't accept it as such.
- zare_st 3y agoWho 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 agoWhat 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 agoPutting 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.