Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:85646
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.167 cause and error)
Message-ID: <551C3876.5000004@mabe.berlin>
Date: Wed, 01 Apr 2015 20:27:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <CA+kxMuSvxRq-AvjQSBUc-FiYdTrD_1X2SuQtjWRjTwAbcwWRoA@mail.gmail.com>
In-Reply-To: <CA+kxMuSvxRq-AvjQSBUc-FiYdTrD_1X2SuQtjWRjTwAbcwWRoA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Deprecate setlocale?
From: dev@mabe.berlin (Marc Bennewitz)



Am 01.04.2015 um 18:15 schrieb Dan Ackroyd:
> Hi,
>
> 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.
What if the system is configured with a different locale?
OK we could change the locale on startup to "C" but this could break 
embedded behaviour and doesn't solve the issue at all.

There are some cases where we don't have a good alternative like fgetcsv 
/ fputcsv.

> 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.
 From my perspective

Functionality not related to locale should not be effected by this global
    -> The following bug reports are valid bugs and should be resolved
         https://bugs.php.net/bug.php?id=59571 - breaks Imagick
         https://bugs.php.net/bug.php?id=69348 - breaks MySQL
    -> If it's part of the wrapped library it's a bug of this library 
and should be fixed there

Basic PHP functions should be possible to be TS and therefore should 
ignoring such global configuration else it's impossible to have a TS 
version of PHP
    -> if there is no alternative functionality we should add one
    -> Non-TS functions should be moved into an extension and don't 
allow to enable on TS build
    -> Non-TS functions not movable to an extension should be rethink like:
        - removing the locale based conversion on simple float to string 
casts
        - make strtoupper/strtolower etc. to work with ascii only

Is't there a very similar issue with fs operations and umask?
-> Is it possible to have fs operations not related on this non-TS 
global configuration?

> https://bugs.php.net/bug.php?id=59571 - breaks Imagick
-> It's a real bug and should be fixed (not locale based functionality)

> https://bugs.php.net/bug.php?id=54538 - breaks NumberFormatter
-> It's a real bug and should be fixed (based on a different "safe" locale)
> https://bugs.php.net/bug.php?id=66108 - breaks constants
-> see comment above about strtoupper

> https://bugs.php.net/bug.php?id=67127 - breaks DateTime
-> It's a bug and should be fixed (not locale based functionality)
> https://bugs.php.net/bug.php?id=69348 - breaks MySQL
-> It's a bug and should be fixed (non locale based functionality)
-> Couldn't this one be a security issue
>
> And there are quite a few other bug reports where setlocale is doing
> exactly what it is meant to do, but the unexpected side-effects are
> catching people out.
>
> We have libraries that ship with PHP for formatting dates, numbers etc
> that actually work, and don't break other libraries.
>
> So two questions:
>
> i) Are there any reasons why we couldn't or shouldn't plan for
> removing setlocale at some point in the future? i.e. does it do
> something that isn't supported by other libraries in PHP?
>
> ii) If it's not possible (or desirable) to remove it, how could we
> increase the warning level against using it?
>
> cheers
> Dan
>
Marc