Hi Rich,

On Sun, Mar 10, 2024 at 03:39:56PM -0400, Rich Felker wrote:
> Also, the whole reason this comes up is gratuitous impedance mismatch
> bringing in the need for a separate fprintf call to do the prefix (and
> possibly newline suffix, if you want that). They could have been
> designed to be one-line macros, ala...
> 
> #define warn(f,...) fprintf(stderr, "%s: " f, __progname, __VA_ARGS__)
> 
> or similar.

Hmmm, it's an interesting definition.  That's actually warnx(3), but you
can write the others in terms of that:


#define setprogname(n)    do { program_invocation_short_name = n; } while (0)
#define getprogname()     (program_invocation_short_name)

#define warnx(f, ...)     fprintf(stderr, "%s: " f "\n", getprogname(), ##__VA_ARGS__)
#define warnc(c, f, ...)  warnx(f ": %s", ##__VA_ARGS__, strerror(c))
#define warn(f, ...)      warnc(errno, f, ##__VA_ARGS__)

#define errx(x, ...)      do { warnx(__VA_ARGS__); exit(x); } while (0)
#define errc(x, ...)      do { warnc(__VA_ARGS__); exit(x); } while (0)
#define err(x, ...)       do { warn(__VA_ARGS__);  exit(x); } while (0)


The main problem is still portability.  But I guess with some cpp(1)
I can get it to work in the systems I care about.

libc couldn't implement it this way, because complex things like "%2ms"
wouldn't work.  But it could be interesting in a multi-threaded program,
where such complex conversion specifications don't occur.

Still, that's not my case.  I guess I'll do this:

	#if (!WITH_LIBBSD)
	inline void
	setprogname(const char *progname)
	{
		program_invocation_short_name = Basename(name);
	}

	inline const char *
	getprogname(void)
	{
		return program_invocation_short_name;
	}
	#endif

> I really see no justifiable reason for people writing new
> software to want to enhance the err.h functions rather than just

I don't really need to enhance them.  Just a statement that the current
behavior will hold would be good enough.  I would need to know that
setting 'program_invocation_short_name' will set the prefix of these
functions.  That's already the current behavior, and I guess that you'll
keep it, even if just for backwards compatibility; more so, considering
your aversion to fix or break these APIs, or to change them at all.

> rolling a one-line macro that can be better tailored to their specific
> needs.
> 
> Rich

Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>