Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:85683 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39587 invoked from network); 2 Apr 2015 07:21:35 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Apr 2015 07:21:35 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain lerdorf.com designates 209.85.220.48 as permitted sender) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.220.48 mail-pa0-f48.google.com Received: from [209.85.220.48] ([209.85.220.48:34323] helo=mail-pa0-f48.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F4/C3-07407-CFDEC155 for ; Thu, 02 Apr 2015 02:21:34 -0500 Received: by pactp5 with SMTP id tp5so76115579pac.1 for ; Thu, 02 Apr 2015 00:21:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=3qYmmH0BZZ9AziBLrwuRppQMZF8Q4ksw8DIoGYHFEv8=; b=jBTt186PbUiRcXi4eI1NrCQHcAA+fV7DaBhM38C0vhE9J14XHEu8MBgGLvj6QgIaas DzSf1wPmmPp7vpRyhYlvKdX+spuO23llA0K3WY5cKrDsmY5ZzIx2NqcRKOSsUYVbo+F7 sbnio0y3eRMA9TLhgZIunnFVuxb02A6J+WZEVjVs5jhvlWc72eKpkGZOfmcIQ5EvqG4B YH3AQNSV/GDreOXKXMZPpPCP3gI/lTIPAcHCCqL0lA8F2ru6ZcI6u3z2NYwC9K87bPWE 7erD2aMuItWQ5o7kp/LpsoVBY4WaseZZ5v+sWOUiHVeXDxm6eYO8gwEErJYLF25uisvU /8KQ== X-Gm-Message-State: ALoCoQnniHJ4w/qx1PQg+DqZNuipsojJ5wtgrbMV6w4QmhlFGq48Uo1ntlX4ktgnubkca87wl4Oi X-Received: by 10.68.57.132 with SMTP id i4mr12019813pbq.138.1427959289275; Thu, 02 Apr 2015 00:21:29 -0700 (PDT) Received: from [192.168.200.14] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPSA id dc5sm4186074pbc.53.2015.04.02.00.21.27 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Apr 2015 00:21:27 -0700 (PDT) Message-ID: <551CEDF6.7090408@lerdorf.com> Date: Thu, 02 Apr 2015 00:21:26 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dan Ackroyd , "internals@lists.php.net" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftHSrmGJWLpLeqFqecTQ4SMQ6PUSwLqlt" Subject: Re: [PHP-DEV] Deprecate setlocale? From: rasmus@lerdorf.com (Rasmus Lerdorf) --ftHSrmGJWLpLeqFqecTQ4SMQ6PUSwLqlt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 04/01/2015 09:15 AM, Dan Ackroyd wrote: > Hi, >=20 > I'd like to get people's feedback for the idea of making setlocale be > either deprecated and to be removed eventually or just increasing the > warning level against people using it. >=20 > The short version of why we should do this is that setlocale breaks > things. It is a process wide operation, that is not thread safe on > most platforms. Although people use it to alter the way strings are > output, it also breaks libraries that are assuming that they are > running in a "C" locale. The PHP setlocale() wrapper can be made threadsafe in a portable manner via newlocale()/uselocale(), so that part isn't an issue. Someone just needs to write the code for the threaded SAPIs. It hasn't been a high priority due to how few people use non-Windows ZTS mode so far. Obviously within the same process there may be issues with changing a locale to something unexpected by subsequent code, but that is really a bug in that code then. If some library function expects and only works in the "C" locale, it should make sure it is in that locale before doing anything and then restoring the locale back appropriately. And with a bit of symbol trickery libraries that do actually call setlocale to change it and restore it can be made to use our newlocale/uselocale thread-local locale mechanism. setlocale() is used quite a bit and for non-threaded, which is the bulk of php usage, it tends to work quite well. It is annoying that it is process-wide and as you noted that can cause issues, sure, and that the current implementation isn't threadsafe, but it isn't something that is technically unsolvable. Rather than throwing our hands in the air and just pulling the rug out from under people using it, we should take a look at fixing the problems associated with it instead. -Rasmus --ftHSrmGJWLpLeqFqecTQ4SMQ6PUSwLqlt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlUc7fYACgkQlxayKTuqOuBlWQCffq9TXWYsHmKFVPz+1pwkmI5g RdEAnj18w2SFcMGXxU8J6WfLi1jIdsYG =6Dtu -----END PGP SIGNATURE----- --ftHSrmGJWLpLeqFqecTQ4SMQ6PUSwLqlt--