Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » FW: [PHP-CVS] cvs: php-src /ext/standard basic_functions.c streamsfuncs.c streamsfuncs.h /ext/standard/tests/file include_userstream_001.phpt include_userstream_002.phpt /main main.c php_globals.h php_streams.h /main/streams streams.c userspa »

FW: [PHP-CVS] cvs: php-src /ext/standard basic_functions.c streamsfuncs.c streamsfuncs.h /ext/standard/tests/file include_userstream_001.phpt include_userstream_002.phpt /main main.c php_globals.h php_streams.h /main/streams streams.c userspa

php.internals

Dmitry Stogov

19 years ago
Hi, I am going to commit the same patch to PHP_5_2. It looks like it breaks binary compatibility but really it doesn't. Any objections? Thanks. Dmitry.

Ilia A.

19 years ago
You are changing a global struct and it does not break BC, how does that work? Ilia

Dmitry Stogov

19 years ago
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. Dmitry.

Pierre Joye

19 years ago
On 7/3/07, Dmitry Stogov <dmitry@zend.com> 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 `xxxxxx' has different size in shared object, consider re-linking"? --Pierre

Dmitry Stogov

19 years ago
I never heard about such warning. What system do you mean? Dmitry.

Pierre Joye

19 years ago
On 7/3/07, Dmitry Stogov <dmitry@zend.com> 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

Rasmus Lerdorf

19 years ago
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. -Rasmus Dmitry Stogov wrote:

Dmitry Stogov

19 years ago
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.

Rasmus Lerdorf

19 years ago
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 defining a stream and setting this. -Rasmus

sean finney

19 years ago
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 this, then I am ok > with it. I was thinking an extension might be defining a stream and > setting this.
i think the problematic scenario would be an extension that was previously compiled with (and allocated/initialized an instance of) the old smaller struct, which then passed said struct to a function from the newer core version, which would expect that it was a the new (larger) struct, and attempt to access memory outside the bound of the older struct. but i'm not familiar enough with the code in question to know how this struct used and passed around between extensions and the core. sean

Dmitry Stogov

19 years ago
The core_globals structure is allocated/initialized in PHP itself (main.c). No one extension does it. Thanks. Dmitry.

Ilia A.

19 years ago
Dmitry, From your explanation it sounds like there should be any issues with putting this patch into the next 5.2.X release. On 4-Jul-07, at 2:31 AM, Dmitry Stogov wrote:
> The core_globals structure is allocated/initialized in PHP itself > (main.c). > No one extension does it. > > Thanks. Dmitry. > >> -----Original Message----- >> From: sean finney [mailto:seanius@seanius.net] >> Sent: Tuesday, July 03, 2007 8:43 PM >> To: internals@lists.php.net >> Subject: Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src >> /ext/standard basic_functions.c streamsfuncs.c streamsfuncs.h >> /ext/standard/tests/file include_userstream_001.phpt >> include_userstream_002.phpt /main main.c php_globals.h >> php_streams.h /main/strea >> >> >> 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 this, >> then I am >>> ok with it. I was thinking an extension might be defining a stream >>> and setting this. >> >> i think the problematic scenario would be an extension that >> was previously >> compiled with (and allocated/initialized an instance of) the >> old smaller >> struct, which then passed said struct to a function from the >> newer core >> version, which would expect that it was a the new (larger) >> struct, and >> attempt to access memory outside the bound of the older struct. >> >> but i'm not familiar enough with the code in question to know >> how this struct >> used and passed around between extensions and the core. >> >> >> sean >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Ilia Alshanetsky

sean finney

19 years ago
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 in this case if the extension is accessing this added > element.
hrm.. then this could potentially be a problem for 3rd party packagers such as debian or redhat, where there are some php extensions which are not generated from the main php tarball but compiled externally, as well as any locally compiled/installed extensions? sean

Dmitry Stogov

19 years ago
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.

Cristian Rodriguez

19 years ago
On 7/3/07, sean finney <seanius@seanius.net> 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 that other distributions use :P everytime PHP changes (does not matter where, when or why) all extensions are rebuilt automatically , this rule is not specific to PHP but an overall [and sane] rule of the build system itself.