On 7/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote:
The size of global structure is important only during allocation (in
main.c).
The offsets of all old elements of the structure are still the same, because
I added new element in the end.
Does that not produce warnings at runtime, like Symbol
On 03.07.2007 17:36, John Mertic wrote:
The zip build is php-5.2.x-win32.zip, you merge it with the PECL package
(pecl-5.2.x-win32.zip),
which I believe is supposed to be completely separate thing and that causes the
mess.
It's separate, but there is nothing telling the end user that some
Hi,
On 7/2/07, Antony Dovgal [EMAIL PROTECTED] wrote:
On 03.07.2007 00:50, John Mertic wrote:
If an author would like his extension in the Windows installer then they
could just ask, would prevent unmaintained and unstable extensions
included in the build.
But we are shipping them
I never heard about such warning. What system do you mean?
Dmitry.
-Original Message-
From: Pierre [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 5:27 PM
To: Dmitry Stogov
Cc: Ilia Alshanetsky; internals@lists.php.net; Stanislav Malyshev
Subject: Re: [PHP-DEV] Re:
On 7/3/07, Dmitry Stogov [EMAIL PROTECTED] wrote:
I never heard about such warning. What system do you mean?
For example, my ubuntu feisty does it when I use an exe with a
different .so (with php compiled from sources). It happens as well
between two libraries.
--Pierre
--
PHP Internals -
On 7/2/07, Sara Golemon [EMAIL PROTECTED] wrote:
Currently, an empty check like the following returns false because
SimpleXML only checks for node existence in has_property. I'd like to
propose the attached patch to change this to look at the node's children
and apply PHP's emptiness rules to
That is still a binary compatibility break. Binary compatibility isn't
just backwards, but also forwards within a major version. eg. if I
build an extension against PHP 5.2.3 I expect it to also work in PHP
5.2.1 and it won't in this case if the extension is accessing this added
element.
Btw I canot imagine extension that may use this new PG(in_user_include)
flag.
In any case the issue is not very critical and this patch may wait for 5.3.
Dmitry.
-Original Message-
From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 6:49 PM
To: Dmitry Stogov
Dmitry Stogov wrote:
Btw I canot imagine extension that may use this new PG(in_user_include)
flag.
In any case the issue is not very critical and this patch may wait for 5.3.
If there really is no reason for an extension to use this, then I am ok
with it. I was thinking an extension might be
hi guys,
On Tuesday 03 July 2007 16:48:44 Rasmus Lerdorf wrote:
That is still a binary compatibility break. Binary compatibility isn't
just backwards, but also forwards within a major version. eg. if I
build an extension against PHP 5.2.3 I expect it to also work in PHP
5.2.1 and it won't
It must not be a problem.
Any extension that compiled for php-5.2.* must work with new php-5.2.4.
In case of objections I won't apply patch before 5.3 and in case of any
claims before php-5.2.4 release I'll revert it.
Dmitry.
-Original Message-
From: sean finney [mailto:[EMAIL
hi,
On Tuesday 03 July 2007 17:36:07 Rasmus Lerdorf wrote:
Dmitry Stogov wrote:
Btw I canot imagine extension that may use this new PG(in_user_include)
flag.
In any case the issue is not very critical and this patch may wait for
5.3.
If there really is no reason for an extension to use
On 7/3/07, sean finney [EMAIL PROTECTED] wrote:
hrm.. then this could potentially be a problem for 3rd party packagers such
as debian or redhat.
well.. I can say is not a problem at least for openSUSE, as we dont
use the (IMHO) wrong way of rebuilding extensions based in the PHP API
number
13 matches
Mail list logo
