Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
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 try{}catch(){} would start failing.
Is this a show stopper? Or is restoring the "proper" execution path worth it?
>From what I can see in the few open source drivers I looked at, it
won't be an issue (Drupal, Doctrine, Zend, Lithium, etc)...
Thanks,
Anthony
On Thu, Jun 21, 2012 at 10:19 PM, Anthony Ferrara wrote:
> 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/pdo_mysql/tests/bug44327.phpt
>
> It runs the following code:
>
> $stmt = $db->prepare('foo');
> @$stmt->execute();
> $row = $stmt->fetch();
> var_dump($row->queryString);
>
> And expects:
>
> Notice: Trying to get property of non-object in %s on line %d
> NULL
>
> Whereas the proper behavior is for the syntax error to be thrown from
> `prepare`. PDO emulation doesn't do that, because it doesn't parse
> until `execute`, hence the error delays until that point.
>
> When I run it, I get:
>
> Warning: PDO::prepare(): SQLSTATE[42000]: Syntax error or access
> violation: 1064 You have an error in your SQL syntax; check the manual
> that corresponds to your MySQL server version for the right syntax to
> use near 'foo' at line 1 in %s on line %d
>
> Because it's sent back at prepare() instead of at execute (and prepare
> doesn't have an @).
>
> There are at least a few more failures of this nature.
>
> To fix this, is going to take some significant refactoring of a number
> of tests. Plus, without this patch, I'm still getting 2 warnings and 6
> failures:
>
> =
> Number of tests : 166 157
> Tests skipped : 9 ( 5.4%)
> Tests warned : 2 ( 1.2%) ( 1.3%)
> Tests failed : 6 ( 3.6%) ( 3.8%)
> Expected fail : 1 ( 0.6%) ( 0.6%)
> Tests passed : 148 ( 89.2%) ( 94.3%)
> -
> Time taken : 43 seconds
> =
>
> =
> EXPECTED FAILED TEST SUMMARY
> -
> PECL Bug #7976 (Calling stored procedure several times)
> [ext/pdo_mysql/tests/bug_pecl_7976.phpt] XFAIL REASON: Works with
> mysqlnd. It is not supported by libmysql. For libmysql is good enough
> to see no crash.
> =
>
> =
> FAILED TEST SUMMARY
> -
> Bug #39858 (Lost connection to MySQL server during query by a repeated
> call stored proced) [ext/pdo_mysql/tests/bug_39858.phpt]
> PDO MySQL Bug #41997 (stored procedure call returning single rowset
> blocks future queries) [ext/pdo_mysql/tests/bug_41997.phpt]
> MySQL PDO->__construct() - Generic + DSN
> [ext/pdo_mysql/tests/pdo_mysql___construct.phpt]
> MySQL PDO->exec(), affected rows
> [ext/pdo_mysql/tests/pdo_mysql_exec_load_data.phpt]
> MySQL PDOStatement->nextRowSet()
> [ext/pdo_mysql/tests/pdo_mysql_stmt_nextrowset.phpt]
> MySQL Prepared Statements and different column counts
> [ext/pdo_mysql/tests/pdo_mysql_stmt_variable_columncount.phpt]
> =
>
> =
> WARNED TEST SUMMARY
> -
> Bug #44454 (Unexpected exception thrown in foreach() statement)
> [ext/pdo_mysql/tests/bug_44454.phpt] (warn: XFAIL section but test
> passes)
> MySQL PDO->prepare(), emulated PS
> [ext/pdo_mysql/tests/pdo_mysql_prepare_emulated.phpt] (warn: XFAIL
> section but test passes)
> =
>
> Whereas with the patch, there are a few more failures:
>
> =
> Number of tests : 166 157
> Tests skipped : 9 ( 5.4%)
> Tests warned : 2 ( 1.2%) ( 1.3%)
> Tests failed : 18 ( 10.8%) ( 11.5%)
> Expected fail : 1 ( 0.6%) ( 0.6%)
> Tests passed : 136 ( 81.9%) ( 86.6%)
> -
> Time taken : 53 seconds
> =
>
>
> So to do th
Re: [PHP-DEV] [PATCH - PR] Disable ATTR_EMULATE_PREPARES by default for PDO_Mysql
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/pdo_mysql/tests/bug44327.phpt
It runs the following code:
$stmt = $db->prepare('foo');
@$stmt->execute();
$row = $stmt->fetch();
var_dump($row->queryString);
And expects:
Notice: Trying to get property of non-object in %s on line %d
NULL
Whereas the proper behavior is for the syntax error to be thrown from
`prepare`. PDO emulation doesn't do that, because it doesn't parse
until `execute`, hence the error delays until that point.
When I run it, I get:
Warning: PDO::prepare(): SQLSTATE[42000]: Syntax error or access
violation: 1064 You have an error in your SQL syntax; check the manual
that corresponds to your MySQL server version for the right syntax to
use near 'foo' at line 1 in %s on line %d
Because it's sent back at prepare() instead of at execute (and prepare
doesn't have an @).
There are at least a few more failures of this nature.
To fix this, is going to take some significant refactoring of a number
of tests. Plus, without this patch, I'm still getting 2 warnings and 6
failures:
=
Number of tests : 166 157
Tests skipped :9 ( 5.4%)
Tests warned:2 ( 1.2%) ( 1.3%)
Tests failed:6 ( 3.6%) ( 3.8%)
Expected fail :1 ( 0.6%) ( 0.6%)
Tests passed: 148 ( 89.2%) ( 94.3%)
-
Time taken : 43 seconds
=
=
EXPECTED FAILED TEST SUMMARY
-
PECL Bug #7976 (Calling stored procedure several times)
[ext/pdo_mysql/tests/bug_pecl_7976.phpt] XFAIL REASON: Works with
mysqlnd. It is not supported by libmysql. For libmysql is good enough
to see no crash.
=
=
FAILED TEST SUMMARY
-
Bug #39858 (Lost connection to MySQL server during query by a repeated
call stored proced) [ext/pdo_mysql/tests/bug_39858.phpt]
PDO MySQL Bug #41997 (stored procedure call returning single rowset
blocks future queries) [ext/pdo_mysql/tests/bug_41997.phpt]
MySQL PDO->__construct() - Generic + DSN
[ext/pdo_mysql/tests/pdo_mysql___construct.phpt]
MySQL PDO->exec(), affected rows
[ext/pdo_mysql/tests/pdo_mysql_exec_load_data.phpt]
MySQL PDOStatement->nextRowSet()
[ext/pdo_mysql/tests/pdo_mysql_stmt_nextrowset.phpt]
MySQL Prepared Statements and different column counts
[ext/pdo_mysql/tests/pdo_mysql_stmt_variable_columncount.phpt]
=
=
WARNED TEST SUMMARY
-
Bug #44454 (Unexpected exception thrown in foreach() statement)
[ext/pdo_mysql/tests/bug_44454.phpt] (warn: XFAIL section but test
passes)
MySQL PDO->prepare(), emulated PS
[ext/pdo_mysql/tests/pdo_mysql_prepare_emulated.phpt] (warn: XFAIL
section but test passes)
=
Whereas with the patch, there are a few more failures:
=
Number of tests : 166 157
Tests skipped :9 ( 5.4%)
Tests warned:2 ( 1.2%) ( 1.3%)
Tests failed: 18 ( 10.8%) ( 11.5%)
Expected fail :1 ( 0.6%) ( 0.6%)
Tests passed: 136 ( 81.9%) ( 86.6%)
-
Time taken : 53 seconds
=
So to do this, I'd need to fix those as well... (at least all but the XFAIL)
So I'm going to keep at it, but it's going to take a while (and would
like some insight into if this is the best approach to fixing the
tests)...
Thanks,
Anthony
On Thu, Jun 21, 2012 at 2:57 AM, Ulf Wendel wrote:
> Am 20.06.2012 08:39, schrieb Pierre Joye:
>
>> hi Chris,
>>
>> On Tue, Jun 19, 2012 at 11:45 PM, Christopher Jones
>> wrote:
>>
>>> We should take this offline - I can see cases where I'd strongly
>>> disagree.
>>
>>
>> I see no reason to move a discussion offline or off list, this is a
>> topic that interests many other readers or developers.
>
>
> Agreed. There was enough trouble around PDO and discussions going on in the
> hidden.
>
> However, this does not impact the original topic.
>
> Ulf
>
>
> --
> P
Re: [PHP-DEV] [DRAFT] RFC - array_column() function
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. > > https://wiki.php.net/rfc/array_column I like your proposal and code examples on the RFC, this function is useful and would save a foreach() to get the specified keys/indexes out of the array. - Paul. > > Thanks, > Ben > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [DRAFT] RFC - array_column() function
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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
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 and look for that warning to get a really good idea about the > server software being used. And yes, I know people should have > display_errors off in production, but this case is slightly different > because it is so universal. Other user-triggerable warnings are very > code-dependent and there is no universal trigger string you can send to > all PHP apps. Almost all PHP apps call htmlspecialchars() on user input > at some point. I have no problem to raise a warning here, but it must respect display_error. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] bug 54547
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 because of this please tell. "12345678901234567890" == "12345678901234567890.0" used to be true, is now false ... i'd still say that's ok though as it is a case of "never compare floats for equality" here, now that the decimal clearly says that at least the right side is supposed to be float, not integer ... In addition to == operator, >, <, >=, and <= operators are influenced. And, hexdecimal format for big number is now case-sensitive. http://www.mail-archive.com/internals@lists.php.net/msg58789.html Can you add some phpt tests for all the cases you've raised? Chris -- christopher.jo...@oracle.com http://twitter.com/#!/ghrd -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
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_errors is > off? And if display_errors is on, no warning is produced? damned :) I mean only display_errors is ON. obviously :) -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
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 warning is put into the error log? But only if display_errors is >> off? And if display_errors is on, no warning is produced? >> >> That's very counter-intuitive and un-PHP-like. Someone mentioned it's for >> security reasons. By that logic, we should get rid of all error >> messages because they all reveal some information that can be used by >> attackers. > > Yes, I agree with this, but other people thing differently about it ;) > > Personally I'd actually remove the warning completely with the return > false behavior. The return value makes clear that there was an error > and json_last_error() can be used to determine what exactly went > wrong. The warning seems redundant in this case and could actually > make the use more complicated. 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 and look for that warning to get a really good idea about the server software being used. And yes, I know people should have display_errors off in production, but this case is slightly different because it is so universal. Other user-triggerable warnings are very code-dependent and there is no universal trigger string you can send to all PHP apps. Almost all PHP apps call htmlspecialchars() on user input at some point. The call here was whether to throw a warning at all and the idea was that it was ok to do so as long as it didn't leak to the world for improperly configured servers that had display_errors on. I would be fine with removing the warning altogether since sanitizing the string is an inherent characteristic of the function now and throwing warnings about the normal operation of a function doesn't make much sense. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
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 >> >> 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? >> >> That's very counter-intuitive and un-PHP-like. Someone mentioned it's for >> security reasons. By that logic, we should get rid of all error >> messages because they all reveal some information that can be used by >> attackers. > > Yes, I agree with this, but other people thing differently about it ;) I think I must missed some infos, I though you was talking that you want to generate wanrings without regard of EG(display_errors). thanks > > Personally I'd actually remove the warning completely with the return > false behavior. The return value makes clear that there was an error > and json_last_error() can be used to determine what exactly went > wrong. The warning seems redundant in this case and could actually > make the use more complicated. > > Nikita > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
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_errors is > off? And if display_errors is on, no warning is produced? > > That's very counter-intuitive and un-PHP-like. Someone mentioned it's for > security reasons. By that logic, we should get rid of all error > messages because they all reveal some information that can be used by > attackers. Yes, I agree with this, but other people thing differently about it ;) Personally I'd actually remove the warning completely with the return false behavior. The return value makes clear that there was an error and json_last_error() can be used to determine what exactly went wrong. The warning seems redundant in this case and could actually make the use more complicated. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
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? That's very counter-intuitive and un-PHP-like. Someone mentioned it's for security reasons. By that logic, we should get rid of all error messages because they all reveal some information that can be used by attackers. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
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 well, partial encoding or magic replacements make no sense here. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Resume keyword
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->getCode() == E_NOTICE & E_STRICT) {
>> resume null;
>> }
>>
>> echo 'Dying now'; exit;
>> });
>>
>> throw new Exception('A test', E_NOTICE);
>>
>> echo "We didn't die";
>>
>> The code above when run would echo "A test. We didn't die.";
>>
>>
>>
> Whats about
>
> $user = $this->getUser(); // Throws exception
> echo $user->getName();
>
>
> Now the second one will fail too, but in reality it shouldn't even get
> executed...
>
> Regards,
> Sebastian
>
>
Then the error handler shouldn't have called resume. The error
handler should only call the keyword if its safe to do so. And now
that I think about it, not having the ability to return anything would
be for the best since it would keep the usefulness of this to a
minimum and avoid magic headaches.
Cause the last thing we need is for people to start using the
exception handling mechanism as additional control structure tree.
What about what I'd mentioned before that this would allow? With this
in place the existing PHP Errors could all be converted to Exceptions.
The default exception handler would resume after catching any low
level exceptions (E_NOTICE, E_WARNING, etc) but a custom one can be
free to do whatever.
Unifying the mechanisms also would allow for exceptions for other
fatal events. This would be highly useful.
try {
require( 'path/to/file.php' );
} catch ( PARSE_EXCEPTION $e ) {
// some logging then pretty death
}
Most of the time you'd never want to resume after such an
exception Most of the time.
In any event "resume" would allow PHP to get back to having only one
exception mechanism instead of two since the behavior of errors could
be emulated under exceptions. That is the principle boon of resume.
Does that balance the two drawbacks
1) It's a new keyword, so BC breaks occur with code that used it as a
function name.
2) The spaghetti possibilities increase.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add hash_pbkdf2 function
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 iterated stretching algorithms similar to PBKDF2? > > The algos recommended to use with PBKDF2. I just updated the RFC to include a description of the non-obvious parameters ($password isn't described). I also included a bit on algorithm selection in there. Take a peak and let me know if that satisfies what you were looking for, or if it needs to be expanded further. Thanks again, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Add hash_pbkdf2 function
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, I don't care for it. Basically,
the reason is that it limits the algorithms that can be called by
hash_password. Specifically scrypt would not be possible, because it
has more parameters than that.
> My point being that:
>
> $hash = hash_password('1234', 'my'. $password[1] .
> 'super-long-salt-secret');
>
> Gives good enough security 80% of use cases and is simpler then:
>
> $hash = hash_pbkdf2('sha1', '1234', 'my'. $password[1] .
> 'super-long-salt-secret', 1000);
>
> Developers will still use sha1 or md5 because they are so simple.
The goal of this API addition is not to simplify anything. It's to
provide a C implementation of the PBKDF2 algorithm. The other topic
about password hashing has the simplification goal.
Anthony
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Generators patch
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) "xx" and running that php file manually leads to crash and points me to the zend_execute.h at line 335. I didn't debug it in details but could do it later if you have no fail on nix. Cheers Anatoliy Am Mi, 20.06.2012, 21:36 schrieb Nikita Popov: > On Wed, Jun 20, 2012 at 5:25 PM, Anatoliy Belsky wrote: >> Hi Nikita, >> >> I've just tried to compile your generators branch on windows, the build >> is >> broken there. This are the relevant messages before the compilation >> bails >> out: >> >> c:\php-sdk\phpmaster\vc9\x86\nikic\zend\zend_execute.c(1543) : error >> C2065: 'tsrm_ls' : undeclared identifier >> c:\php-sdk\phpmaster\vc9\x86\nikic\zend\zend_execute.c(1543) : error >> C2065: 'tsrm_ls' : undeclared identifier >> c:\php-sdk\phpmaster\vc9\x86\nikic\zend\zend_execute.c(1550) : error >> C2065: 'tsrm_ls' : undeclared identifier >> NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio >> 9.0\VC\Bin\cl.exe"' : return code '0x2' >> Stop. > > Hey Anatoliy! > > Thanks for testing the patch :) > The errors aren't really Windows specific, they are there because I > forget to put a few TSRMLS_CC and TSRMLS_DC in the code ^^ (I usually > develop without --enable-maintainer-zts because it makes debugging > easier). > I now fixed the zts errors, so the build should work fine now :) > > Nikita > Those errors aren't Windows specific; they are there because I usually > develop without --enable-maintainer-zts > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() behavior for incorrectly encoded strings
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 discussion. > > Well, not sure we have to discuss why such thing is bad. > display_errors must be respected. This kind of very ugly error handling is currently used in several places. It is meant to protect server administrators that are running production servers with display_errors=On from leaking information about encoding issues (which could be valuable to attackers). So the error is only thrown if it isn't shown to the client but logged instead. Personally I really don't like this, but I agree with Stas that this is a security relevant issue and shouldn't be simply changed without further discussion. > 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? Thanks, Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Resume keyword
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 'Dying now'; exit;
> });
>
> throw new Exception('A test', E_NOTICE);
>
> echo "We didn't die";
>
> The code above when run would echo "A test. We didn't die.";
>
>
>
Whats about
$user = $this->getUser(); // Throws exception
echo $user->getName();
Now the second one will fail too, but in reality it shouldn't even get
executed...
Regards,
Sebastian
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
