Actually, the more I think about it, this would result in an
inadvertent API change. Right now, if you have a SQL syntax error, the
error would be thrown by ->execute(). But with this change, the error
would be thrown by ->prepare(). So code that currently wraps execute()
but not prepare() with a t
As it turns out, the testing of this is far more difficult than I
originally suspected. Not because it fails, but because emulated
queries were behaving badly to begin with, so a number of tests were
testing bad behavior. For example, bug 44327:
https://github.com/ircmaxell/php-src/blob/master/ext
On Thu, Jun 21, 2012 at 8:27 PM, Ben Ramsey wrote:
> Hi all,
>
> I've written a draft version of an RFC for pull request 56 (
> https://github.com/php/php-src/pull/56 ), to add array_column() to the core.
> Please take a look and provide feedback so that I can improve the
> patch/proposal.
>
> htt
Hi all,
I've written a draft version of an RFC for pull request 56 (
https://github.com/php/php-src/pull/56 ), to add array_column() to the
core. Please take a look and provide feedback so that I can improve the
patch/proposal.
https://wiki.php.net/rfc/array_column
Thanks,
Ben
--
PHP Inter
hi Rasmus,
On Thu, Jun 21, 2012 at 5:33 PM, Rasmus Lerdorf wrote:
> The problem with a warning here is that there is usually no way to
> prevent it short of using @ or preceding all calls to htmlspecialchars()
> with an iconv() call. A bad guy can simply send invalid UTF-8 bytes to a
> web app a
On 06/14/2012 10:42 PM, OISHI Kazuo wrote:
I know this was discussed a number of times here, but just to bring it
to a conclusion - I intend to apply patch in the bug report - which
removes conversion for strings that do not convert to integers - to 5.4.
If anybody sees anything that breaks bec
On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
wrote:
> Hi Nikita:
>
>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>> string is encountered:
>> * A warning is thrown, but only if display_errors=off
>
> So the warning is put into the error log? But only if display_e
On 06/21/2012 07:25 AM, Nikita Popov wrote:
> On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
> wrote:
>> Hi Nikita:
>>
>>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>>> string is encountered:
>>> * A warning is thrown, but only if display_errors=off
>>
>> So the wa
On Thu, Jun 21, 2012 at 10:25 PM, Nikita Popov
wrote:
> On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
> wrote:
>> Hi Nikita:
>>
>>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>>> string is encountered:
>>> * A warning is thrown, but only if display_errors=off
>>
>
On Thu, Jun 21, 2012 at 4:12 PM, Daniel Convissor
wrote:
> Hi Nikita:
>
>> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
>> string is encountered:
>> * A warning is thrown, but only if display_errors=off
>
> So the warning is put into the error log? But only if display_e
Hi Nikita:
> PHP <= 5.3.13, PHP 5.4, master behave as follows when an invalid UTF-8
> string is encountered:
> * A warning is thrown, but only if display_errors=off
So the warning is put into the error log? But only if display_errors is
off? And if display_errors is on, no warning is produced?
hi,
On Thu, Jun 21, 2012 at 11:21 AM, Nikita Popov
wrote:
>> 5.3 should be brought in line with 5.4.
> So you think that the corrected code should be backed out from PHP 5.3
> and the incorrect 5.4/master behavior be restored?
For the warning yes. For the rest, it should imo return false as wel
On Thu, Jun 21, 2012 at 2:59 AM, Sebastian Krebs
wrote:
> 2012/6/20 Michael Morris
>
>> [/snip]
>>
>> An example for additional clarity.
>>
>> set_exception_handler(function ($e) {
>> echo $e->getMessage();
>> // Don't know if this is correct - but should be able to illustrate here
>> if ($e->
Pierre,
>>> I would update the RFC with the current available algorithms or
>>> recommended to be used (depending on the usage or goal).
>>
>> When you say "currently available algorithms", are you talking about
>> the hash library as a whole? Or recommended for use with PBKDF2? Or
>> other iterat
Jonathan,
> I like this proposal, it could be useful to add a simpler api that has
> defaults matching the NIST recommendation:
> hash_password($password, $salt, $algo = 'sha1', $iterations = 1000);
Checkout the other thread about adding a simple password API.
As far as implementing that as well
Hi Nikita,
yep, once you see tsrm_ls it's clear. Just wanted to mention it was tested
on windows. ZTS is enabled by default there.
It compiles fine now :)
but Zend\tests\generators\clone_with_stack.phpt fails on both TS and ZTS
builds under win
the diff looks like
001+
001- string(10) "xxx
On Thu, Jun 21, 2012 at 8:47 AM, Pierre Joye wrote:
>> The reason for this situation is that a patch was applied for all
>> branches, and then reverted, because Stas didn't consider the change
>> towards always throwing a warning (even with display_errors=on)
>> appropriate without further discuss
2012/6/20 Michael Morris
> [/snip]
>
> An example for additional clarity.
>
> set_exception_handler(function ($e) {
> echo $e->getMessage();
> // Don't know if this is correct - but should be able to illustrate here
> if ($e->getCode() == E_NOTICE & E_STRICT) {
>resume null;
> }
>
> echo
18 matches
Mail list logo
