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 1rNExS-00ALSw-78 for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jan 2024 16:28:06 +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 1rNExR-00E5Mx-7S for pgsql-hackers@arkaria.postgresql.org; Tue, 09 Jan 2024 16:28:05 +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 1rNExQ-00E5Mp-TJ for pgsql-hackers@lists.postgresql.org; Tue, 09 Jan 2024 16:28:04 +0000 Received: from mail-oi1-x22a.google.com ([2607:f8b0:4864:20::22a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rNExJ-000g3u-NZ for pgsql-hackers@lists.postgresql.org; Tue, 09 Jan 2024 16:28:04 +0000 Received: by mail-oi1-x22a.google.com with SMTP id 5614622812f47-3bbd6ea06f5so1477354b6e.1 for ; Tue, 09 Jan 2024 08:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neon.tech; s=google; t=1704817675; x=1705422475; darn=lists.postgresql.org; h=in-reply-to:references:from:to:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OJPv8FC3szGBRkw4S22Ti5743CnuM/pbZJQBcJ1RmsI=; b=YJRk//xRrzyhD8aqSVhZBDiyWLlrKc0iTkXrsvO8WfK2lvOhyRUYE6SNebKDmte7cc VHjvbkE2b/jgAP1h8zi8kEBb8TvXcgv603zV1wnUIZlA1ENfJwh1iy6AWk/e6l4au1Gb AXliBDsWWf4m+ASvYFWAfntsjWR2MBqRxoGOw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704817675; x=1705422475; h=in-reply-to:references:from:to:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=OJPv8FC3szGBRkw4S22Ti5743CnuM/pbZJQBcJ1RmsI=; b=Djonhx7WZoZQCZYld7r+b7FFAipZZFm1L91TN06fb1HBNmMZxbZn7ypQ8r1wIfGsGK SEPOtjich41ORw4KfZSBTPGd9Tl1eW7/7xPNQNgXy0aFoQiRcWYYoNL0Yd66HsawKYz4 GR+yYhBxsLUXK6WuWnO4bOv7zZZgviqa0j9nS2QDAH0qiakZToydekWJPKdSvwO+6Zbj cb4Zs3DSZVNszA1vYt+3eLl2cbv7/8/JeN3n/JQM4FnsDUpDTDOdgUscXkPDYcAEFaCm OkIQcnxu4RPm9WU01si7Q1sHWOLGM5B1FHxNmdit9ORH2w7ZN8jva/D11sLY0zTqb+cg wWtg== X-Gm-Message-State: AOJu0Yx1GDLYq4acaoV8+sZJN+GM7pBranqYX92PyGZxE/pLSrhLOgPG IhZrIsnlT9YkqI2wahiwaS9fHuES5VDWmTef63v7tvvgwzw= X-Google-Smtp-Source: AGHT+IF+enX00cBl2R2nIhI8CafPSskVmHan04AnCRl7YTRA3O9tI3sLV5PHTxtV+b9gpg2j06YU9w== X-Received: by 2002:a05:6808:2115:b0:3bd:446f:73ba with SMTP id r21-20020a056808211500b003bd446f73bamr32939oiw.10.1704817675599; Tue, 09 Jan 2024 08:27:55 -0800 (PST) Received: from localhost ([2607:fb90:e683:8cf6:3996:e070:71ee:42fb]) by smtp.gmail.com with ESMTPSA id fa5-20020a0568082a4500b003bbc30937b2sm388467oib.4.2024.01.09.08.27.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Jan 2024 08:27:55 -0800 (PST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8; format=Flowed Date: Tue, 09 Jan 2024 10:27:54 -0600 Message-Id: Cc: Subject: Re: Make psql ignore trailing semicolons in \sf, \ef, etc To: "Tom Lane" From: "Tristan Partin" X-Mailer: aerc 0.16.0-127-gec0f4a50cf77 References: <2012251.1704746912@sss.pgh.pa.us> <2071227.1704758905@sss.pgh.pa.us> In-Reply-To: <2071227.1704758905@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon Jan 8, 2024 at 6:08 PM CST, Tom Lane wrote: > "Tristan Partin" writes: > > On Mon Jan 8, 2024 at 2:48 PM CST, Tom Lane wrote: > >> + (isascii((unsigned ch= ar) mybuf.data[mybuf.len - 1]) && > >> + isspace((unsigned ch= ar) mybuf.data[mybuf.len - 1])))) > > > Seems like if there was going to be any sort of casting, it would be to= =20 > > an int, which is what the man page says for these two function, though= =20 > > 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. Thanks for the explanation. > > 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? I'll leave it up to you. Patch looks good as-is. --=20 Tristan Partin Neon (https://neon.tech)