Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qGKrp-0006S1-FD for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Jul 2023 14:49:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qGKro-0001Oi-3S for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Jul 2023 14:49:28 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qGKrn-0001OZ-QO for pgsql-hackers@lists.postgresql.org; Mon, 03 Jul 2023 14:49:27 +0000 Received: from mail-oa1-x2c.google.com ([2001:4860:4864:20::2c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qGKrk-001yDu-RT for pgsql-hackers@postgresql.org; Mon, 03 Jul 2023 14:49:27 +0000 Received: by mail-oa1-x2c.google.com with SMTP id 586e51a60fabf-1b06a46e1a9so4059429fac.2 for ; Mon, 03 Jul 2023 07:49:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neon-tech.20221208.gappssmtp.com; s=20221208; t=1688395763; x=1690987763; 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=3afDK9Z/CHtOMq9lQtcoVJm2JbnnX+CEGIbHH4GlyXw=; b=VOVr9W6OEarb+krqAhyB8PCunzEgVWVOJeweMwtMVu/Jb4L0YFTWJvTe7iiARmiAVg 2s3RgT5ipj2V3AXE9SBCA28G/J8a78L8GWxUDPSXpWVmxHthg5ASJ3XL+unf0J5b3/6I 7aTYW+9zfD5Ms2slE6RTz3I0l2kfI74VaeAoWu/vWg2kqTiRTwS3mVvppQby4/h9HLps JFVH5HEBvb+crI9MIICvgX20Pa1dAne4ghMfnhHQETHuagnfDfozWz+w4VsZtPZgJSPT TtYEKcpSuFXi3q3WafhK3vpqa9MiAi6r+AZopgteKVhCCoeFepynpi+nLWoQhmbxyNBW 6yAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688395763; x=1690987763; 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=3afDK9Z/CHtOMq9lQtcoVJm2JbnnX+CEGIbHH4GlyXw=; b=X5Ojv4rPeMNdWkhqHeJ0YJzYW5HBrC5y9p69VdhF7RHL7ECiINNum8viSF0CbR7db+ voAgRqrjCsWWo7gcrwz33OrwggXL++DdA4yDTC22eH2bqijLJr5lx7FK0Vmuksn69db9 4Xb08BdabaGclNM4NO+iJhx/jMPMsb5WVDhK4bPhh2+cj1uMTwcJF8Cluki5Hf87PN6o BgQjZbqyWELQCb+rZpLEgsBkV3yJgOAc2xE1YkA5qDYdKBPy58iCr2QidV0UlYyQ8SUb WoTACwmo066nS5x7Yhy0Yr//xM8Z1Le9ZKFJQiudyfmE+Xo5OdjbpijBaV209QkofMgt OzKg== X-Gm-Message-State: ABy/qLaD+vgvL4cSOfCMHBQjFtPFKoBgK5OiyVg1+Qd1eehRQUSlpBfJ 3TQQyHVHEo4aCOFqKclEXKJONg== X-Google-Smtp-Source: APBJJlG+8olgpTkU6wxlbsb2CT6o6q87k/0DwiU9llZYoCvYf8qnZSFlyj20BSslk6eDdHBUT2+2XQ== X-Received: by 2002:a05:6871:438e:b0:1b0:21ef:6e1a with SMTP id lv14-20020a056871438e00b001b021ef6e1amr8340112oab.40.1688395763268; Mon, 03 Jul 2023 07:49:23 -0700 (PDT) Received: from localhost ([2607:fb90:f280:130d:3996:e070:71ee:42fb]) by smtp.gmail.com with ESMTPSA id eq28-20020a056870a91c00b001a2f7ca6183sm12519051oab.38.2023.07.03.07.49.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 Jul 2023 07:49:22 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Mon, 03 Jul 2023 09:49:21 -0500 Message-Id: Cc: Subject: Re: Make uselocale protection more consistent To: "Peter Eisentraut" , "Thomas Munro" From: "Tristan Partin" X-Mailer: aerc 0.15.2-76-g69094e332779 References: <14f5200e-388d-66ff-9deb-695d1fd40d68@eisentraut.org> In-Reply-To: <14f5200e-388d-66ff-9deb-695d1fd40d68@eisentraut.org> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon Jul 3, 2023 at 9:21 AM CDT, Peter Eisentraut wrote: > On 03.07.23 15:21, Tristan Partin wrote: > >>> I think it would be better to keep HAVE_LOCALE_T as encompassing any = of > >>> the various locale_t-using functions, rather than using HAVE_USELOCAL= E > >>> as a proxy for them. Otherwise you create weird situations like havi= ng > >>> #ifdef HAVE_WCSTOMBS_L inside #ifdef HAVE_USELOCALE, which doesn't ma= ke > >>> sense, I think. > >> I propose[1] that we get rid of HAVE_LOCALE_T completely and make > >> "libc" provider support unconditional. It's standardised, and every > >> target system has it, even Windows. But Windows doesn't have > >> uselocale(). > >> > >> [1]https://www.postgresql.org/message-id/flat/CA%2BhUKGL7CmmzeRhoirzjE= CmOdABVFTn8fo6gEOaFRF1Oxey6Hw%40mail.gmail.com#aef2f2274b28ff8a36f9b8a598e3= cec0 > > I think keeping HAVE_USELOCALE is important for the Windows case as > > mentioned. I need it for my localization work where I am ripping out > > setlocale() on non-Windows. > > The current code is structured > > #ifdef HAVE_LOCALE_T > #ifdef HAVE_WCSTOMBS_L > wcstombs_l(...); > #else > uselocale(...); > #endif > #else > elog(ERROR); > #endif > > If you just replace HAVE_LOCALE_T with HAVE_USELOCALE, then this would=20 > penalize a platform that has wcstombs_l(), but not uselocale(). I think= =20 > the correct structure would be > > #if defined(HAVE_WCSTOMBS_L) > wcstombs_l(...); > #elif defined(HAVE_USELOCALE) > uselocale(...); > #else > elog(ERROR); > #endif That makes sense to me. I gave it some more thought. Maybe it makes more sense to just completely drop HAVE_USELOCALE as mentioned, and protect calls to it with #ifdef WIN32 or whatever the macro is. HAVE_USELOCALE might be more descriptive, but I don't really care that much either way. --=20 Tristan Partin Neon (https://neon.tech)