Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1frSQ7-00070b-Pa for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Aug 2018 18:27:24 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1frSQ5-0004Gm-1C for pgsql-hackers@arkaria.postgresql.org; Sun, 19 Aug 2018 18:27:21 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1frSQ4-0004Ge-3A for pgsql-hackers@lists.postgresql.org; Sun, 19 Aug 2018 18:27:20 +0000 Received: from smtp9.dreamhost.com ([64.90.62.178] helo=pdx1-sub0-mail-a1.g.dreamhost.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1frSPv-000194-Ha for pgsql-hackers@lists.postgresql.org; Sun, 19 Aug 2018 18:27:18 +0000 Received: from pdx1-sub0-mail-a1.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a1.g.dreamhost.com (Postfix) with ESMTP id 53A927E09C; Sun, 19 Aug 2018 11:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=wOZlQgzU2fsiQq 66HIPLtLarvOw=; b=UlIvq3CxBWGAwlhFR9G5nnxpMlvpR3++zDZl2DbCrMK+EV 4E/+IrNkF5H/XnisG9njuLo7cDEn46JsdW4sYajY9tHblWW9H6QN4b7RCQDlzuIQ sH8P1gaEBA2NBH8JFvZeMgt61Mj+W2yg7TeHhr6pcM3Fk78ROUdLIU8TeqoVg= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a1.g.dreamhost.com (Postfix) with ESMTPSA id AFFA97E096; Sun, 19 Aug 2018 11:27:08 -0700 (PDT) Date: Sun, 19 Aug 2018 13:27:05 -0500 From: Nico Williams To: Tom Lane Cc: Thomas Munro , Alvaro Herrera , PostgreSQL Hackers Subject: Re: Allowing printf("%m") only where it actually works Message-ID: <20180819182704.GC16780@localhost> References: <20180528150125.j2x3mp62ssbeg3h5@alvherre.pgsql> <2685.1527520461@sss.pgh.pa.us> <8770.1533931511@sss.pgh.pa.us> <16896.1533935042@sss.pgh.pa.us> <14925.1534040609@sss.pgh.pa.us> <1437.1534100930@sss.pgh.pa.us> <13183.1534624490@sss.pgh.pa.us> <20180819045050.GB16780@localhost> <25779.1534655758@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25779.1534655758@sss.pgh.pa.us> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Sun, Aug 19, 2018 at 01:15:58AM -0400, Tom Lane wrote: > Nico Williams writes: > > On Sat, Aug 18, 2018 at 04:34:50PM -0400, Tom Lane wrote: > >> So now I'm about ready to propose that we just *always* use > >> snprintf.c, and forget all of the related configure probing. > > > You'd also get to ensure that all uses from *die() are > > async-signal-safe. > > [ raised eyebrow... ] That seems like more than I care to promise > here. But even if snprintf itself were unconditionally safe, > there's plenty of other stuff in that code path that isn't. One step at a time, no? And there's the other benefits.