Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rMzfW-008Lld-Ae for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jan 2024 00:08:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rMzfU-008PMq-TB for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jan 2024 00:08:32 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rMzfU-008PMh-Ja for pgsql-hackers@lists.postgresql.org; Tue, 09 Jan 2024 00:08:32 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rMzfP-000YVv-Jh for pgsql-hackers@lists.postgresql.org; Tue, 09 Jan 2024 00:08:32 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 40908PfO2071228; Mon, 8 Jan 2024 19:08:26 -0500 From: Tom Lane To: "Tristan Partin" cc: pgsql-hackers@lists.postgresql.org Subject: Re: Make psql ignore trailing semicolons in \sf, \ef, etc In-reply-to: References: <2012251.1704746912@sss.pgh.pa.us> Comments: In-reply-to "Tristan Partin" message dated "Mon, 08 Jan 2024 17:31:37 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2071226.1704758905.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Mon, 08 Jan 2024 19:08:25 -0500 Message-ID: <2071227.1704758905@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk "Tristan Partin" writes: > On Mon Jan 8, 2024 at 2:48 PM CST, Tom Lane wrote: >> + (isascii((unsigned cha= r) mybuf.data[mybuf.len - 1]) && >> + isspace((unsigned cha= r) mybuf.data[mybuf.len - 1])))) > Seems like if there was going to be any sort of casting, it would be to = > an int, which is what the man page says for these two function, though = > isascii(3) explicitly mentions "unsigned char." Casting to unsigned char is our standard pattern for using these functions. If "char" is signed (which is the only case in which this changes anything) then casting to int would imply sign-extension of the char's high-order bit, which is exactly what must not happen in order to produce a legal value to be passed to these functions. POSIX says: The c argument is an int, the value of which the application shall ensure is a character representable as an unsigned char or equal to the value of the macro EOF. If the argument has any other value, the behavior is undefined. If we cast to unsigned char, then the subsequent implicit cast to int will do zero-extension which is what we need. > Small English nit-pick: I would drop the hyphen between semi and colons. Me too, except that it's spelled like that in nearby comments. Shall I change them all? regards, tom lane