Michael Wallner [Fri, 6 Dec 2013 09:29:24 +0000 (10:29 +0100)]
Fixed bug #61645 (fopen and O_NONBLOCK)
if a mode like "rn" was passed to fopen(), then
php_stream_parse_fopen_modes() would assign O_WRONLY to
flags, because O_NONBLOCK tainted flags for the r/w/+ check
Adam Harvey [Tue, 3 Dec 2013 22:46:15 +0000 (14:46 -0800)]
Remove 128.0.0.0/16 and 191.255.0.0/16 from the reserved list.
These were returned to the general allocation pool by RFC 3330, and hence
shouldn't cause an IP address validation failure due to being reserved. At
least 128.0.0.0/16 is in use on the public Internet today.
Fixes bug #66229 (128.0.0.0/16 isn't reserved any longer).
Michael Wallner [Mon, 2 Dec 2013 15:58:34 +0000 (16:58 +0100)]
Fix bug #65196
Passing DOMDocumentFragment to DOMDocument::saveHTML()
produces invalid markup, because a DocumentFragment is just a container
for child nodes and not a real node itself.
Nikita Popov [Sun, 1 Dec 2013 12:37:56 +0000 (13:37 +0100)]
Fix bug #65764
I'm not exactly sure whether this is the right way to fix it. The
question is whether Generator::throw() on a newborn generator (i.e.
a generator that is not yet at yield expression) should first advance to
the first yield and throw the exception there or whether it should
instead throw the exception in the caller's context.
The old behavior was to throw it at the start of the function (i.e.
the very first opcode), which causes issues like the one in #65764.
Effectively it's impossible to properly handle the exceptions in this
case.
For now I choose the variant where the generator advances to the
first yield before throwing, as that's consistent with how all other
methods on the Generator object currently behave. This does not
necessarily match the behavior in other languages, e.g. Python would throw
the exception in the caller's context. But then our send() method already
has this kind of deviation, so it stays internally consistent at least.
Nikita Popov [Sat, 30 Nov 2013 12:35:33 +0000 (13:35 +0100)]
Cleanup generator closing code a bit
All code dealing with unfinished execution cleanup is now in a separate
function (previously most of it was run even when execution was properly
finished.
Furthermore some code dealing with unclean shutdowns has been removed,
which is no longer necessary, because we no longer try to clean up in
this case.
nikita2206 [Tue, 29 Oct 2013 15:40:17 +0000 (19:40 +0400)]
Fixed bug #65768: DateTimeImmutable::diff does not work
This commit also prevents user classes from directly implementing
DateTimeInterface, because ext/date relies on classes implementing
it to support certain internal structures.
Dmitry Stogov [Thu, 28 Nov 2013 21:00:14 +0000 (01:00 +0400)]
Merge branch 'PHP-5.6' of git.php.net:php-src into PHP-5.6
* 'PHP-5.6' of git.php.net:php-src:
Fixed bug #65199 (Wrong Day of Week) and fixed bug #63391 (Incorrect/inconsistent day of week prior to the year 1600)
Marking those two as XFAIL for now.
Fixed a few DST changeover issues.
Move add/sub to timelib.
Fix backwards transition diffs.
Split up tests into their different categories.
Group those tests a bit better, as some of the bd ones wanted a "ST" feature that doesn't exist yet.
Fixed forward transitions in diffs.
Always reset those parameters.
Fixed "Forward Transition" construction of DateTime objects.
Dmitry Stogov [Thu, 28 Nov 2013 13:04:54 +0000 (17:04 +0400)]
Merge branch 'PHP-5.6' of git.php.net:php-src into PHP-5.6
* 'PHP-5.6' of git.php.net:php-src:
Updated NEWS for Constant Scalar Exprs RFC
Moved arrays again to "static_scalar:" & little cleanup
Renaming
Constant expressions refactoring
Removed operations on constant arrays. They make no sense as constants are not allowed to be arrays. And as just properties are allowed to; no problem, we still don't need operations on any constant array.
Added a few more operators
Whitespace fix
converted several switches to ifs and made more opcache friendly
Fatal error about self referencing constants fixed
Fixed mem leaks, added tests and ternary operator
Working commit for constant scalar expressions (with constants). Tests will follow.
Derick Rethans [Sun, 31 Mar 2013 17:11:35 +0000 (18:11 +0100)]
Fixed "Forward Transition" construction of DateTime objects.
This fixes the issue in
https://wiki.php.net/rfc/datetime_and_daylight_saving_time#forward_transitions
There is a period during transition to DST where a time (such as 02:30) does
not exist. PHP already calculated the correct timestamp for this, but failed to
"rounded forward" to the existing correct hour value.
projects / php / log