From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-20585-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,
	T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4
Received: from second.openwall.net (second.openwall.net [193.110.157.125])
	by inbox.vuxu.org (Postfix) with SMTP id 69D3C26556
	for <ml@inbox.vuxu.org>; Sun, 10 Mar 2024 20:39:52 +0100 (CET)
Received: (qmail 23754 invoked by uid 550); 10 Mar 2024 19:35:44 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 23724 invoked from network); 10 Mar 2024 19:35:43 -0000
Date: Sun, 10 Mar 2024 15:39:56 -0400
From: Rich Felker <dalias@libc.org>
To: NRK <nrk@disroot.org>
Cc: Alejandro Colomar <alx@kernel.org>, Guillem Jover <guillem@hadrons.org>,
	libc-alpha@sourceware.org, musl@lists.openwall.com,
	libbsd@lists.freedesktop.org, "Serge E. Hallyn" <serge@hallyn.com>,
	"Skyler Ferrante (RIT Student)" <sjf5462@rit.edu>,
	Iker Pedrosa <ipedrosa@redhat.com>,
	Christian Brauner <christian@brauner.io>
Message-ID: <20240310193956.GU4163@brightrain.aerifal.cx>
References: <Zeo-oJOyN9YQXVb1@debian>
 <ZepcO2pa0cwsqr3u@thunder.hadrons.org>
 <ZephTZUYSrv1TVkH@debian>
 <20240309150258.GS4163@brightrain.aerifal.cx>
 <ZeyFHOoY5gJWgc4X@debian>
 <vkjv3ntkak7egz6g7gpu7ojel6nvrjjcf4fq7iymatmn7qkoai@6onkgtmfjpgu>
 <Ze2y-UNcfLNZypYu@debian>
 <mr7ct4d47hn7bkhlj2ktcossu2q663pre6ggc5elkprveu4r3t@xowlfk5bccce>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <mr7ct4d47hn7bkhlj2ktcossu2q663pre6ggc5elkprveu4r3t@xowlfk5bccce>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] Re: Tweaking the program name for <err.h> functions

On Sun, Mar 10, 2024 at 02:01:18PM +0000, NRK wrote:
> >  or add locks; that is:
> > 
> > 	lock()
> > 	fprintf("%s: ", __progname);
> > 	vfprintf(...);
> > 	unlock();
> >
> > [...]
> >
> > locking code is error-prone, I'd say.
> 
> These interfaces do not guarantee the output to be atomic. If you were
> expecting it to be atomic then that's just *another* reason to roll it
> yourself because a good ton of existing implementation doesn't lock.

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. I really see no justifiable reason for people writing new
software to want to enhance the err.h functions rather than just
rolling a one-line macro that can be better tailored to their specific
needs.

Rich