Hi NRK, On Sun, Mar 10, 2024 at 06:01:14AM +0000, NRK wrote: > > What do you offer to use instead? snprintf(3) + perror(3) + exit(3)? > > No need to have an intermediate buffer with snprintf when you can just > use vfprintf directly. For an interface that prefixes the program name, I need to either call [v]fprintf(3) twice, or add locks; that is: lock() fprintf("%s: ", __progname); vfprintf(...); unlock(); or prepare the buffer and call it just once. Because I want to call it as foo("reason");, not having to use __progname all the time. > > > I suggest you remove err.h from libc, and let a standalone library to > > implement them separately, allowing to configure them. > > These are not mutually exclusive. You can have err.h in libc while also > having them as separate library. If I #include , glibc considers those as reserved names. | All other library names are reserved if your program explicitly | includes the header file that defines or declares them. I guess it would work, because of weak symbols, but the manual explicitly says don't do this. > And besides, these are not good interfaces anyways. Aside from what Rich > already said, you'll realize this soon when you need to use various > posix_* or pthread_* functions which don't set the errno and instead > return an error code. There's errc(3), and also warnc() (Guillem, libbsd is missing the link pages for warn*() variants!), to which you can pass an errno-like code. This isn't supported by glibc, but is available in libbsd (and of course, in the BSDs; at least I checked OpenBSD). And for the finctions that don't report an errno-like, like the gai_error(3) ones, you can use errx(3), and also warnx(3). These are supported in glibc. So these are actually quite well suited for different kinds of error- reporting functions. Regarding multi-threaded programs: If you're recommending writing a version because it's easy, but then you say it needs locking, well, I wouldn't say writing a locking version is easy. > > Also, I don't think your fear of "NIH bug" is well grounded. This is not > some highly complicated error-prone code, it's just simple logging > facility. locking code is error-prone, I'd say. > > I am aware that there exists certain programming cultures [*] where > having to write code instead of "import leftpad" is seen as taboo of the > highest order. But in this case you don't even *have to* write anything > when you can just copy err.c from musl and customize it. I think the BSD err.h functions are actually quite well designed for single-threaded programs (still the vast majority of software). And for multi-threaded versions, we just need to convince the BSD maintainers that they need to add locking. If glibc and musl don't consider these APIs as useless and legacy, and fix them, then maybe the BSDs follow. Again, is there anything better in glibc or musl? Something that prefixes "$progname: " and appends the errno message? Yeah, you could write fprintf("%s: ...", program_invocation_short_name, ...) all the time? or write a wrapper that calls fprintf("%s: ", program_invocation_short_name), but then you need to add locking? and then you need to set program_invocation_short_name = "su"? And then add *c() for functions that return an errno-like code? And then add *x() variants for functions that don't use errno-like codes? Oh well, you're basically writing the err.h interface. The interface is good. It's the implementation that has small problems, but I say let's fix them. This is certainly not what I want to be doing for every project. And as said above, having an overlay library that defines err.h is a violation of glibc's reserved names. Not too bad if done in a library, but certainly not that I'd do in every project. Have a lovely day! Alex > > (* Counterculture to this also exists, such as Go's "A little copying > is better than a little dependency" proverb for example.) > > - NRK --