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 1qGKQT-0004ob-16 for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Jul 2023 14:21:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qGKQR-00058k-Sr for pgsql-hackers@arkaria.postgresql.org; Mon, 03 Jul 2023 14:21:11 +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 1qGKQR-00058b-JP for pgsql-hackers@lists.postgresql.org; Mon, 03 Jul 2023 14:21:11 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qGKQO-001xuT-59 for pgsql-hackers@postgresql.org; Mon, 03 Jul 2023 14:21:11 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 48F0832009B4; Mon, 3 Jul 2023 10:21:06 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Mon, 03 Jul 2023 10:21:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eisentraut.org; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm1; t=1688394065; x=1688480465; bh=SJQwZ0X53+v3Eo4BrKGLEWFPh 8o3hbcC2ZL0jZW1I6Q=; b=AUbnvuePVnG9mgeDiYGF7f2ZUUC0OH689T5FQRae8 lE4FwjBB1JahUJGV15zE5s1UXE6NgUN4zb/08tS7i63nTSfHHfVzUEljJbDLCF+E jxR4kjnStMtyvIGu8VXBHTXYuv3wnEOJTat80J9SVN41UMgokCBKzUEliTpjnLFR QjNvuoJmHIwd+iEZ2lY+nX6PO/29+VlLOwwh6r3+ERTBfT9gnEiJpL+0xdkkJtYI Z8DSpoMCovvz1R+io0OShXFbg142XViEcNX/PtQ/kg6suTHSaTonlQuxzMxQZpJy Az6vt0GiHFUl3uQpMO6LhSeijj69j9u+mYuxFNumaJhyA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1688394065; x=1688480465; bh=SJQwZ0X53+v3Eo4BrKGLEWFPh8o3hbcC2ZL 0jZW1I6Q=; b=UcJRWA+duxekcIasGEdLnxTGO2h+xXE50WuA6AOjtpEXM5UT5Rv 08jD3EyMCoSbkN20rCQ3UzibwLq2CRAPjlEp0PCY8Rgllw/vcT8hKcBviw+/uYc0 EJyySQYhsim5gkfmacAWjBYnXYnGVIlc8sQjQJ+QWGn4GjGNbK5fKD7oaOo3JBdM mFfJG/zW9GgteYIqiQW+mih+iisbs0iJZSv8j8cERQf2rv0nKK3/bUkbc7VDOORS ELc1Y8dUqAXHwAsZxeGNM1cQludL207o8VTFLjUxBmaN2rHFnHUJAZTpikDtzjqP pPFqbTmPvx8KsMef6wQbEA4sTy8JsaDKm5w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddvgdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcugfhishgvnhhtrhgruhhtuceophgvthgvrhesvghishgvnhhtrhgruhhtrdhorhhgqe enucggtffrrghtthgvrhhnpeeuheetkeejveelvdffledvfffgheehffeftedtuddugfek vdekudetveevuedtteenucffohhmrghinhepphhoshhtghhrvghsqhhlrdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepphgvthgvrhes vghishgvnhhtrhgruhhtrdhorhhg X-ME-Proxy: Feedback-ID: ie0a040ee:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 3 Jul 2023 10:21:04 -0400 (EDT) Message-ID: <14f5200e-388d-66ff-9deb-695d1fd40d68@eisentraut.org> Date: Mon, 3 Jul 2023 16:21:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: Make uselocale protection more consistent Content-Language: en-US To: Tristan Partin , Thomas Munro Cc: pgsql-hackers@postgresql.org References: From: Peter Eisentraut In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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_USELOCALE >>> as a proxy for them. Otherwise you create weird situations like having >>> #ifdef HAVE_WCSTOMBS_L inside #ifdef HAVE_USELOCALE, which doesn't make >>> 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%2BhUKGL7CmmzeRhoirzjECmOdABVFTn8fo6gEOaFRF1Oxey6Hw%40mail.gmail.com#aef2f2274b28ff8a36f9b8a598e3cec0 > 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 penalize a platform that has wcstombs_l(), but not uselocale(). I think the correct structure would be #if defined(HAVE_WCSTOMBS_L) wcstombs_l(...); #elif defined(HAVE_USELOCALE) uselocale(...); #else elog(ERROR); #endif