Hi Alex, At 2023-05-07T20:13:54+0200, Alejandro Colomar wrote: > On 5/7/23 04:20, G. Branden Robinson wrote: > > I'm following the GNU Coding Standards here. > > > > https://www.gnu.org/prep/standards/standards.html#Errors > > Oh yeah, those. I guess I can't argue much against that practice > then. I still haven't burnt a copy of them yet. :D
This aspect of them seems pretty reasonable to me. The first space character separates source and location information (what is complaining, and about what) from the content of the complaint. > Heh, I was talking a bit from memory, and I forgot that perror(3) is > so basic. In fact, I normally use the err(3) and warn(3) family of > functions, which are similar to perror, but accept a printf-like > format string. err(3) also has exit(3) functionality. > > For some reason I wrongly remembered that perror prefixed the output > with program_invocation_short_name(3), which the BSD functions do. These aren't standardized so I haven't paid much attention to them. [snip] > Maybe the functions shown above can be used to appease your wrath? On other projects, perhaps. groff provides a sufficiently rich set[1] that, apart from adding a "debug()" variant[2], I've found little to complain about. (On the other hand, I've found a _lot_ to complain about with respect to the _content_ of groff's diagnostic messages and the reliability of its line number counting in source files; groff didn't used to report those as often, and once this information was exposed, it often proved inaccurate.) Regards, Branden [1] https://git.savannah.gnu.org/cgit/groff.git/tree/src/libs/libgroff/error.cpp?h=1.23.0.rc4 [2] https://git.savannah.gnu.org/cgit/groff.git/commit/?id=93ffeffd21868f64af7302cb9574240c8354c60a
signature.asc
Description: PGP signature
