On Wed, 2015-04-01 at 20:27 +0200, Marc Bennewitz wrote:
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
No this is not a bug in this function and no not a security issue.
The user
On 04/01/2015 09:15 AM, Dan Ackroyd wrote:
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.
The short version of why we should do this is that setlocale
On 2 April 2015 at 12:24, Dan Ackroyd dan...@basereality.com wrote:
On 2 April 2015 at 16:01, Keyur Govande keyurgova...@gmail.com wrote:
To Rasmus's point, here's a PR for HHVM to provide a thread-safe setlocale
implementation: https://github.com/facebook/hhvm/pull/4736/files
It should be
On 04/02/2015 02:13 PM, Dan Ackroyd wrote:
Adam Harvey wrote:
What about just adding another function: setlocale_global(), or similar?
Do you mean setlocale would become the thread safe one, and
setlocale_global() would be the current behaviour? If so, that would
be a BC break for the small
On 2 April 2015 at 16:01, Keyur Govande keyurgova...@gmail.com wrote:
To Rasmus's point, here's a PR for HHVM to provide a thread-safe setlocale
implementation: https://github.com/facebook/hhvm/pull/4736/files
It should be fairly easy to refactor the thread-safe-setlocale.(h/cpp) files
for
On Thu, Apr 2, 2015 at 1:50 PM, Adam Harvey ahar...@php.net wrote:
On 2 April 2015 at 12:24, Dan Ackroyd dan...@basereality.com wrote:
On 2 April 2015 at 16:01, Keyur Govande keyurgova...@gmail.com wrote:
To Rasmus's point, here's a PR for HHVM to provide a thread-safe
setlocale
On Thu, Apr 2, 2015 at 3:55 PM, Ryan Pallas derokor...@gmail.com wrote:
On Thu, Apr 2, 2015 at 1:50 PM, Adam Harvey ahar...@php.net wrote:
On 2 April 2015 at 12:24, Dan Ackroyd dan...@basereality.com wrote:
On 2 April 2015 at 16:01, Keyur Govande keyurgova...@gmail.com wrote:
To
Adam Harvey wrote:
What about just adding another function: setlocale_global(), or similar?
Do you mean setlocale would become the thread safe one, and
setlocale_global() would be the current behaviour? If so, that would
be a BC break for the small number of people who are deliberately
using
On Thu, Apr 2, 2015 at 3:21 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 04/01/2015 09:15 AM, Dan Ackroyd wrote:
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
On 01 04 2015, at 18:15, Dan Ackroyd dan...@basereality.com wrote:
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.
The short version of why we should
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
On Wed, Apr 1, 2015 at 7:08 PM, Michael Wallner m...@php.net wrote:
On 01 04 2015, at 18:15, Dan Ackroyd dan...@basereality.com wrote:
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
Am 01.04.2015 um 20:58 schrieb Stanislav Malyshev:
Hi!
https://bugs.php.net/bug.php?id=67127 - breaks DateTime
This looks like misunderstanding how float-to-string works. If you asked
it to put commas as decimal separator, don't be surprised it puts commas
as decimal separator.
This should
On 1 April 2015 at 18:27, Marc Bennewitz dev@mabe.berlin wrote:
Functionality not related to locale should not be effected by this global
This is issue is that that the locale affects all of the C library
that use it, which includes printf();
- The following bug reports are valid bugs and
On 1 April 2015 at 18:58, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
Stanislav Malyshev wrote:
Library should not assume it runs in C locale,
Because it is not thread-safe, it is not safe for libraries to alter the locale.
I can't see any workaround to make this 'just work' - when
Hi!
This should be true for number formatting but it's not true for date
format.
Yes, date format is not internationalized. There are a lot of fixed
formats, so this should not be much of a surprise. One just has to know
which ones aren't. And yes, handling transition between fixed and
Hi!
For Imagick, the issue is that a SVG string was being generated with
something like:
sprintf(svg, pos: %f %f, x, y);
Yeah that is a problem... Two ways I see to fix it:
1. Reset the locale before it and restore afterwards (non-TS and in
general may be problematic)
2. Use other
Hi!
- make strtoupper/strtolower etc. to work with ascii only
This would be a bad idea, however much better idea is to make *system*
case folding (i.e. methods, classes, etc.) use ascii-only. Which we
already mostly do (see zend_operators.c it explains what's going on). Of
course, there
Hi
Am 01.04.2015 um 21:02 schrieb Stanislav Malyshev:
Hi!
- make strtoupper/strtolower etc. to work with ascii only
This would be a bad idea, however much better idea is to make *system*
case folding (i.e. methods, classes, etc.) use ascii-only. Which we
already mostly do (see
19 matches
Mail list logo
