On Tue, Jun 18, 2024 at 08:02:16AM +0200, Stefano Brivio wrote:On Tue, 18 Jun 2024 10:46:36 +1000 David Gibson <david(a)gibson.dropbear.id.au> wrote:Eh, I mildly prefer the first variant. It is slightly longer, but makes it very clear where the strerror piece is going to appear in the context of the whole message. It's not a strong preference, though. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibsonOn Mon, Jun 17, 2024 at 02:03:17PM +0200, Stefano Brivio wrote:Okay, yes, it probably makes sense to have more descriptive messages as you suggest in the comment to 5/6, but even then, we still have a lot of cases like this one (from 6/6): - warn("lseek() failed on /proc/net file: %s", strerror(errno)); + warn_perror("lseek() failed on /proc/net file"); where these _perror() variants make for tidier code, I find, regardless of the error message itself.In many places, we have direct perror() calls, which completely bypass logging functions and log files. They are definitely convenient: offer similar convenience with _perror() logging variants, so that we can drop those direct perror() calls. Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com>Hm, for anything bigger than like a screenful of code, I generally find an explicit message with strerror(errno) more useful than perror() or equivalents, but I guess if you think these are useful.