Hello!
The PHP development team announces the immediate availability of PHP
5.4.32.
16 bugs were fixed in this release, including the following
security-related issues:
CVE-2014-2497, CVE-2014-3538, CVE-2014-3587, CVE-2014-3597,
CVE-2014-4670, CVE-2014-4698, CVE-2014-5120.
All PHP 5.4 users are
zend_long/zend_ulong without renaming everything else would be a perfect
solution from my point of view.
Thanks. Dmitry.
On Fri, Aug 22, 2014 at 12:49 AM, Nikita Popov nikita@gmail.com wrote:
On Thu, Aug 21, 2014 at 7:23 PM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
Thanks to Anatol
On Fri, Aug 22, 2014 at 8:45 AM, Dmitry Stogov dmi...@zend.com wrote:
zend_long/zend_ulong without renaming everything else would be a perfect
solution from my point of view.
Again, no. long is the worst type ever, be as type or in names (ppl
then use this type to match the macro names).
If
On 21/08/2014 19:42, Andrea Faulds wrote:
* IS_LONG/long - 32-bit or 64-bit integer (machine-dependant)
* IS_BIGINT/bigint - arbitrary-size integer
* IS_BIGINT_OR_LONG/integer - either a long or a bigint (pseudo-type)
Replacing IS_LONG with IS_INT kinda ruins my naming scheme. The intention
Hello!
The PHP development team announces the immediate availability of PHP
5.5.16. This fixes some bugs against 5.5.15 and addresses five CVEs.
All PHP 5.5 users are encouraged to upgrade to this version.
For source downloads of PHP 5.5.16 please visit our
downloads page:
On 21/08/14 19:10, Andrea Faulds wrote:
I would instead to ask you to try to migrate a not so trivial extension :)
No, seriously. Why can’t a sed script be used to change a constant name? Can
you tell me why that wouldn’t work?
Compatibility across all builds?
Many of the times 'blanket'
Moin,
On Thu, August 21, 2014 19:23, Dmitry Stogov wrote:
Hi,
Thanks to Anatol and Pierre the 64-bit patch is ready
https://github.com/weltling/php-src
I made quick code review and don't see any technical problems now.
The performance and memory consumption difference is negligible.
Hi,
as there are many data type changes, here's an idea on how to simplify the
merges. Git supports custom merge drivers which attracted my attention, so
I've ended up with the following trick:
=== Add to .git/config ===
[merge 7]
name = Compatibility merge between PHP5 and PHP7
driver
On 21/08/14 19:17, Stas Malyshev wrote:
We have millions of people using PHP 5, and the goal is for
almost all of them to eventually use PHP 7, otherwise there's no point
in it. Each BC break creates another hurdle on the way to it. We should
take it seriously.
Currently we have millions
Hi,
I'm going to commit this on next week, if nobody cares.
MM is a self containing subsystem, and it must not affect anything else.
Thanks. Dmitry.
On Mon, Aug 18, 2014 at 10:07 PM, Levi Morrison le...@php.net wrote:
On Mon, Aug 18, 2014 at 12:04 PM, Nikita Popov nikita@gmail.com
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to revert all unnecessary
naming changes and instead use type
On Fri, 2014-08-22 at 13:16 +0200, Nikita Popov wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to
Am 22.8.2014 um 13:16 schrieb Nikita Popov nikita@gmail.com:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which
On Wed, 20 Aug 2014, Andrea Faulds wrote:
On 20 Aug 2014, at 03:53, Laruence larue...@php.net wrote:
On Wed, Aug 20, 2014 at 6:36 AM, Andrea Faulds a...@ajf.me wrote:
Good evening,
I have made an RFC which would make some small changes to how
integers are handled, targeted at PHP
On Fri, 22 Aug 2014, Anatol Belski wrote:
as there are many data type changes, here's an idea on how to simplify
the merges. Git supports custom merge drivers which attracted my
attention, so I've ended up with the following trick:
As there are that many differences, does it still make
On Wed, Aug 20, 2014 at 10:45 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Apparently the fix for #67724 [2] caused #67865 [1], but I already have
a fix for the fix (oh my) [3].
I've reverted it from 5.4.32, but please commit this fix in 5.4. As phar
is currently broken, fix for this
On Fri, 22 Aug 2014, Nikita Popov wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge,
a short proposal has been created, which aims to revert all
Hi Nikita,
On Fri, August 22, 2014 13:16, Nikita Popov wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which
On Fri, Aug 22, 2014 at 2:01 PM, Derick Rethans der...@php.net wrote:
On Mon, 18 Aug 2014, Anatol Belski wrote:
Commit:e49e163a9ed7d4e38f9ab724003c46c9f1ea2cb4
Author:Anatol Belski a...@php.net Mon, 18 Aug 2014 18:57:55
+0200
Parents:
On Fri, Aug 22, 2014 at 1:16 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been
On Fri, Aug 22, 2014 at 1:16 PM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
Today the int64 RFC has been merged, despite objections regarding the
naming changes it introduces.
As we were not given a chance to resolve this issue before the merge, a
short proposal has been
On Fri, Aug 22, 2014 at 1:28 PM, Bob Weinand bobw...@hotmail.com wrote:
Yes, please. We're all in favor of the 64 bit implementation, but definitely
not on
the naming. I think it was a big mistake to not separate the naming and
implementation votes initially.
I also would support a shorter
On Fri, August 22, 2014 14:15, Pierre Joye wrote:
On Fri, Aug 22, 2014 at 2:01 PM, Derick Rethans der...@php.net wrote:
On Mon, 18 Aug 2014, Anatol Belski wrote:
Commit:e49e163a9ed7d4e38f9ab724003c46c9f1ea2cb4
Author:Anatol Belski a...@php.net Mon, 18 Aug 2014
18:57:55
Pierre Joye in php.internals (Fri, 22 Aug 2014 14:17:04 +0200):
And I'd to remember that we suffer from double standards while you
guys do whatever you want with ng, and certainly with ast as well.
Just a side note: talking in you guys and we is not constructive. I
had the idea you had come a lot
On Fri, August 22, 2014 14:54, Derick Rethans wrote:
On Fri, 22 Aug 2014, Anatol Belski wrote:
On Fri, August 22, 2014 14:01, Derick Rethans wrote:
On Mon, 18 Aug 2014, Anatol Belski wrote:
Commit:e49e163a9ed7d4e38f9ab724003c46c9f1ea2cb4
Author:Anatol Belski a...@php.net
On 22 Aug 2014, at 08:10, Matteo Beccati p...@beccati.com wrote:
On 21/08/2014 19:42, Andrea Faulds wrote:
* IS_LONG/long - 32-bit or 64-bit integer (machine-dependant)
* IS_BIGINT/bigint - arbitrary-size integer
* IS_BIGINT_OR_LONG/integer - either a long or a bigint (pseudo-type)
On 8/22/14, 5:11 AM, Pierre Joye wrote:
On Fri, Aug 22, 2014 at 1:28 PM, Bob Weinand bobw...@hotmail.com wrote:
Yes, please. We're all in favor of the 64 bit implementation, but definitely
not on
the naming. I think it was a big mistake to not separate the naming and
implementation votes
On Fri, 22 Aug 2014, Anatol Belski wrote:
On Fri, August 22, 2014 14:54, Derick Rethans wrote:
Yeah, those datatypes should already be there. What needs fixing to
make it work?
I think now that it's unavoidable to create an arch dependent portable
type as timelib_sll is always 64
On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote:
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to revert all unnecessary
naming changes and instead use type names that are consistent with the
existing
Andrea Faulds in php.internals (Fri, 22 Aug 2014 16:32:51 +0100):
Im very much in favour of this RFC. It is not necessary to change
the type names after all; if people turn on compiler warnings, theyll
find out whats broken anyway.
'people'? Which people?
Will a normal user ever notice
On Fri, August 22, 2014 17:17, Derick Rethans wrote:
On Fri, 22 Aug 2014, Anatol Belski wrote:
On Fri, August 22, 2014 14:54, Derick Rethans wrote:
Yeah, those datatypes should already be there. What needs fixing to
make it work?
I think now that it's unavoidable to create an arch
On 22/08/14 13:56, Julien Pauli wrote:
On Wed, Aug 20, 2014 at 10:45 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
Apparently the fix for #67724 [2] caused #67865 [1], but I already have
a fix for the fix (oh my) [3].
I've reverted it from 5.4.32, but please commit this fix in 5.4.
On Fri, Aug 22, 2014 at 4:04 AM, Dmitry Stogov dmi...@zend.com wrote:
Hi,
I'm going to commit this on next week, if nobody cares.
MM is a self containing subsystem, and it must not affect anything else.
Thanks. Dmitry.
I compared this to master on a small PHP array vs SplFixedArray
2014.08.22. 17:56 ezt írta (Jan Ehrhardt php...@ehrhardt.nl):
Andrea Faulds in php.internals (Fri, 22 Aug 2014 16:32:51 +0100):
I’m very much in favour of this RFC. It is not necessary to change
the type names after all; if people turn on compiler warnings, they’ll
find out what’s broken
Ferenc Kovacs in php.internals (Fri, 22 Aug 2014 18:59:01 +0200):
People means ext devs here.
OK.
The concern raised here that if we delay the namechange then early
adopters(ext developers adding support for php7) have to update their code
twice.
Provided the name change (back!) is agreed upon.
On Aug 22, 2014 5:33 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote:
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to revert all unnecessary
naming changes and
On 18/08/2014 18:41, Nikita Popov wrote:
I've opened the vote on the Abstract Syntax Tree RFC:
https://wiki.php.net/rfc/abstract_syntax_tree#vote
After speaking with other members of AFUP (French UG) about this RFC, we
pretty much all agree that a cleaner compilation process is a nice
On Sun, Aug 17, 2014 at 11:25 AM, Ferenc Kovacs tyr...@gmail.com wrote:
Hi,
I'm planning to release 5.6.0 from RC4 if nothing serious comes up, so
this is just a heads-up: if you think that there is some fix, which should
make into the 5.6.0 final (which isn't in RC4) or if you think that
On 8/22/14, 11:38 AM, Pierre Joye wrote:
On Aug 22, 2014 5:33 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote:
As we were not given a chance to resolve this issue before the merge, a
short proposal has been created, which aims to revert
On 23 Aug 2014, at 03:05, Rasmus Lerdorf ras...@lerdorf.com wrote:
The end result here is likely that in order to write a portable
extension, extension authors will simply do:
#ifndef IS_LONG
# define IS_LONG IS_INT
# define Z_STRLEN Z_STRSIZE
# define RETURN_LONG RETURN_INT
# define
Hi Rowan,
On Mon, Aug 18, 2014 at 12:28 AM, Rowan Collins rowan.coll...@gmail.com
wrote:
On 15/08/2014 01:46, Yasuo Ohgaki wrote:
On Wed, Jul 30, 2014 at 9:35 PM, Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com wrote:
Making small changes, such as extra function
hi Rasmus,
On Sat, Aug 23, 2014 at 4:05 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
On 8/22/14, 11:38 AM, Pierre Joye wrote:
On Aug 22, 2014 5:33 PM, Andrea Faulds a...@ajf.me wrote:
On 22 Aug 2014, at 12:16, Nikita Popov nikita@gmail.com wrote:
As we were not given a chance to
42 matches
Mail list logo