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@gibson.dropbear.id.au> wrote:
> 
> > On Mon, Jun 17, 2024 at 02:03:17PM +0200, Stefano Brivio wrote:
> > > 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@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.
> 
> 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.

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/~dgibson