Re: [PHP-DEV] Reference handling change and PHP 4.4.0

Rasmus Lerdorf wrote: Once again, it is an E_NOTICE in 4.4. And yes, not displaying it makes it go away. Staying with 4.3 because of this is nuts. If you are seeing this notice under 4.4 that means you are most likely getting random memory corruption under 4.3. Move to 4.4 to fix the memory c

Re: [PHP-DEV] Reference handling change and PHP 4.4.0

Leigh Makewell wrote: > Pierre Joye wrote: > >> No, 4.3.x is a dead branche. But the problem is much more easier to >> fix in 4.4.0. Do what you always do in production servers, do not >> display errors/notices, especially as 4.4.0 raises only notices for >> the reference problem. >> >> Regards, >

Re: [PHP-DEV] Reference handling change and PHP 4.4.0

Pierre Joye wrote: No, 4.3.x is a dead branche. But the problem is much more easier to fix in 4.4.0. Do what you always do in production servers, do not display errors/notices, especially as 4.4.0 raises only notices for the reference problem. Regards, --Pierre Well that is exactly why this i

Re: [PHP-DEV] Zend resources

"Wez Furlong" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] The module whose resources you are accessing needs to export a function that will give you the list id, and also publish their structure layout in a header file. Just out of interest, what functions are in your extension?

Re: [PHP-DEV] Zend resources

Yep, that did work, thanks a lot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Reference handling change and PHP 4.4.0

Hi Rasmus, thanks for replying, I appreciate your feedback. Rasmus Lerdorf wrote: We have been looking to see if there is a way to fix the memory corruption issue in a way that has less of an impact on existing code. This doesn't change the fact that every error you get is actually an error in t

Re: [PHP-DEV] Reference handling change and PHP 4.4.0

On 9/14/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > but at the same time the breakage of existing apps has been > more widespread than I think anybody anticipated. Than "anybody" liked to anticipate could better said. > I'd still want to throw a notice to let people know they are doing someth

Re: [PHP-DEV] Reference handling change and PHP 4.4.0

Colin Tucker wrote: > I know this issue has most likely been discussed to death here so I > apologise in advance for starting a new thread about it. I just need to > get my head around the reasoning for introducing this change to PHP4 > (4.4 branch). I can understand making the change to PHP5, bu

Re: [PHP-DEV] Reference handling change and PHP 4.4.0

On 9/14/05, Colin Tucker <[EMAIL PROTECTED]> wrote: > Hi Jani, > > Yes, the increase in the middle digit. ;) > > Ok, so does this mean that the 4.3.x and 4.4.x branches will now be > updated separately? Say, if a serious vulnerability was detected in > 4.3.x an 4.4.x, and separate release would

Re: [PHP-DEV] Zend resources

wow thanks, I'm gonna go and try it out right now and tell you my results ""Sara Golemon"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > static int le_socket = -1; > > > Scratch that, those instances of -1 should have been 0 > (Which is what zend_fetch_list_dtor_id() returns a

Re: [PHP-DEV] Reference handling change and PHP 4.4.0

Hi Jani, Yes, the increase in the middle digit. ;) Ok, so does this mean that the 4.3.x and 4.4.x branches will now be updated separately? Say, if a serious vulnerability was detected in 4.3.x an 4.4.x, and separate release would be issued for both? Kind regards, Colin. Jani Taskinen wro

Re: [PHP-DEV] Reference handling change and PHP 4.4.0

You do understand the difference between 4.3.x and 4.4.x? :) (yes, this issue has been beaten to death already) --Jani On Wed, 14 Sep 2005, Colin Tucker wrote: Hello all, I know this issue has most likely been discussed to death here so I apologise in advance for starting a ne

[PHP-DEV] Reference handling change and PHP 4.4.0

Hello all, I know this issue has most likely been discussed to death here so I apologise in advance for starting a new thread about it. I just need to get my head around the reasoning for introducing this change to PHP4 (4.4 branch). I can understand making the change to PHP5, but can someo

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

Me too... At 09:16 AM 9/13/2005, Andrei Zmievski wrote: Yep, what Rasmus said. -Andrei On Sep 13, 2005, at 6:25 AM, Rasmus Lerdorf wrote: Ilia Alshanetsky wrote: Pierre Joye wrote: is not something I like to see. For language constructs, I would really like to have only ASCII support...

Re: [PHP-DEV] Subject and Observer Interfaces

Did I miss something? Where/when did Subject/Observer interfaces go into PHP 5.1? These are very generic names. Marcus, I checked PHP CVS and suddenly saw you commited something like this. I would question in general the direction you're going with Spl. But in any case, these if anything they sh

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

At 20:12 13/09/2005, Sebastian Nohn wrote: Rasmus Lerdorf wrote: This is a choice that should be up to the developer. If she wants to share his code with people who don't understand his language and/or character set, then she should use some common language/character set. But the language shou

Re: [PHP-DEV] ref fix revisited

At 21:22 13/09/2005, Rasmus Lerdorf wrote: Zeev Suraski wrote: >> But there are many other cases >> where a function legitimately takes a by-ref and doesn't necessarily >> write to it or the write is a secondary action not required for the code >> to work. Could we not catch this on the write

Re: [PHP-DEV] ref fix revisited

At 18:07 12/09/2005, Derick Rethans wrote: On Mon, 12 Sep 2005, Zeev Suraski wrote: > I don't really agree that it's out of whack, since you are passing a piece of > data by reference, which is an undefined behavior. I agree that it would have > been nice if we could allow for this and only c

Re: [PHP-DEV] ref fix revisited

Zeev Suraski wrote: >> But there are many other cases >> where a function legitimately takes a by-ref and doesn't necessarily >> write to it or the write is a secondary action not required for the code >> to work. Could we not catch this on the write instead of on the call? > > The problem is t

Re: [PHP-DEV] Re: 5.0.5

Any chance of getting these applied to 5.0.x and 5.1? Scott Scott MacVicar wrote: Path for 5.0.6, it would seem odd to have a different behavior on the 5.0.x branch. Scott Derick Rethans wrote: On Thu, 8 Sep 2005, Stanislav Malyshev wrote: DR>>But they can still do that.. With "shutdown fu

RE: [PHP-DEV] ref fix revisited

Hi, Rasmus Lerdorf wrote on Tuesday, September 13, 2005 3:08 PM: >> As it is too late now anyway, regain BC makes little sense. > > I don't agree. This is one of the main things stopping people from > migrating to PHP5 right now. If we can remove a bit of the migrati

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

> The language does put a limitation as it > does not provide a way to show the > identifiers in a neutral way. For example > ACI 4D (for those who knows it) did it > in the right way. All functions are localized, > I can choose the language I want I will be > able to read the identifiers. But I do

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

Rasmus Lerdorf wrote: This is a choice that should be up to the developer. If she wants to share his code with people who don't understand his language and/or character set, then she should use some common language/character set. But the language should not force this limitation on her. Why n

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

On 9/13/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > This is a choice that should be up to the developer. If she wants to > share his code with people who don't understand his language and/or > character set, then she should use some common language/character set. > But the language should not

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

Ilia Alshanetsky wrote: > Rasmus Lerdorf wrote: > >>What do you mean? Why wouldn't it be portable? > > > Well, for one thing code written to use unicode identifiers will > immediately be limited to running on PHP 6 installs. While code using > ASCII identifier with standard "compat" layer cou

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

Rasmus Lerdorf wrote: > What do you mean? Why wouldn't it be portable? Well, for one thing code written to use unicode identifiers will immediately be limited to running on PHP 6 installs. While code using ASCII identifier with standard "compat" layer could run just fine. Another reason to onl

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

Yep, what Rasmus said. -Andrei On Sep 13, 2005, at 6:25 AM, Rasmus Lerdorf wrote: Ilia Alshanetsky wrote: Pierre Joye wrote: is not something I like to see. For language constructs, I would really like to have only ASCII support... +1 IMHO language identifiers should be limited to ASCII.

[PHP-DEV] Re: [PHP-CVS] cvs: php-src / configure.in

WTF do you mean, optional? -Andrei On Sep 13, 2005, at 2:50 AM, Jani Taskinen wrote: sniper Tue Sep 13 05:50:59 2005 EDT Modified files: /php-srcconfigure.in Log: Cleanup the configure mess, preparing for making unicode OPTIONAL http://cvs.php.net/diff.php/php-src/conf

Re: [PHP-DEV] Subject and Observer Interfaces

On Sep 13, 2005, at 1:37 AM, Marcus Boerger wrote: there is no way in implementing multi-whatever observer and subjects typesafe. Java does it. (However, I am most definitely NOT suggesting emulating java's solution in php.) The other thing you mentioned, sending information along, is n

Re: [PHP-DEV] Subject and Observer Interfaces

On Sep 13, 2005, at 1:35 AM, Sebastian Bergmann wrote: You can extend the interfaces ... and adapt them to your needs while retaining the possibility to use them with other code that only knows about the original Subject and Observer interfaces. Actually you can't and still be typesafe

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

Ilia Alshanetsky wrote: > Pierre Joye wrote: > >>is not something I like to see. For language constructs, I would >>really like to have only ASCII support... > > > +1 IMHO language identifiers should be limited to ASCII. Yes you can now > use language specific chars by changing the locale, so th

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

Pierre Joye wrote: > is not something I like to see. For language constructs, I would > really like to have only ASCII support... +1 IMHO language identifiers should be limited to ASCII. Yes you can now use language specific chars by changing the locale, so that ž, č, ÿ are taken, but that hardly

Re: [PHP-DEV] ref fix revisited

Pierre Joye wrote: > As it is too late now anyway, regain BC makes little sense. I don't agree. This is one of the main things stopping people from migrating to PHP5 right now. If we can remove a bit of the migration pain with some of clever temp var handling, I think it is worthwhile. -Rasmus

Re: [PHP-DEV] ref fix revisited

On 9/13/05, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote: > Just got back from Sri Lanka and am catching up on email. But in > general I don't agree with your statement that things that are quiet in > 5.0.4 must be quiet in 5.0.5. Quietly corrupting memory doesn't really > work. Sometimes we need to

Re: [PHP-DEV] ref fix revisited

Just got back from Sri Lanka and am catching up on email. But in general I don't agree with your statement that things that are quiet in 5.0.4 must be quiet in 5.0.5. Quietly corrupting memory doesn't really work. Sometimes we need to break things slightly to fix things. My message was more abo

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

Pierre Joye wrote: On 9/13/05, Ondrej Ivanič <[EMAIL PROTECTED]> wrote: IMHO, if someone need ... I know, that's why I say: PHP6. Another constraint? why? 1) It's a BC break (... which impact 1 or 2 users? :) ) 2) PHP can be scripting engine in learning programs for children ( like this:

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

On Tue, 13 Sep 2005, Pierre Joye wrote: Do we really want to support unicode for functions, classes, methods and variables names? No. I don't need unicode at all, but if I ever would need it, it would be enough if I can store it in variables. (which I can do already, without any f

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

On 9/13/05, Ondrej Ivanič <[EMAIL PROTECTED]> wrote: > Pierre Joye wrote: > > > > is not something I like to see. For language constructs, I would > > really like to have only ASCII support... > > This suff works in php4,5: > > > function zmaž($čozmazať) { > echo "mažem $čozmazať\n"; >

Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

Pierre Joye wrote: is not something I like to see. For language constructs, I would really like to have only ASCII support... This suff works in php4,5: IMHO, if someone need ... -- Ondrej Ivanič ([EMAIL PROTECTED]) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, v

[PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names

Hello, Do we really want to support unicode for functions, classes, methods and variables names? I really like to have unicode for comments (// /* */) and inside quotes. But having: is not something I like to see. For language constructs, I would really like to have only ASCII support... Rega

Re: [PHP-DEV] unserialize() & unicode issues

On 9/13/05, Antony Dovgal <[EMAIL PROTECTED]> wrote: > Yes, in this case there is no way to avoid converting (while doing > unserialize()), > but I don't see any point in creating Unicode strings when serializing with > unicode_semantics is Off. If I use serialized data on different hosts with

Re[2]: [PHP-DEV] unserialize() & unicode issues

Hello Antony, Tuesday, September 13, 2005, 12:42:57 PM, you wrote: AD> So you propose to store strings/hash keys/class names in Unicode AD> even if unicode_semantics is Off ? yes - those items that are encoded into unicode when unicode_semantics is on (afair, class names and property name

Re: [PHP-DEV] 5.0.5, BC break, fatal error

Hi Andi, On 9/13/05, Andi Gutmans <[EMAIL PROTECTED]> wrote: > Mini releases are not only for security fixes. We also do bug fixes, > and sometimes even minor functionality (like a new function) which > has very low risk of breaking anything. I don't think 5.0.5 is > different from that. As far

Re: [PHP-DEV] unserialize() & unicode issues

On 13.09.2005 13:52, Derick Rethans wrote: On Tue, 13 Sep 2005, Antony Dovgal wrote: On 13.09.2005 13:32, val khokhlov wrote: > Hello Antony, > > Tuesday, September 13, 2005, 11:21:21 AM, you wrote: > > AD> Even if the class name is in Unicode, we can try to convert it to ASCII > AD> and fai

Re: [PHP-DEV] unserialize() & unicode issues

On Tue, 13 Sep 2005, Antony Dovgal wrote: > On 13.09.2005 13:32, val khokhlov wrote: > > Hello Antony, > > > > Tuesday, September 13, 2005, 11:21:21 AM, you wrote: > > > > AD> Even if the class name is in Unicode, we can try to convert it to ASCII > > AD> and fail only in the case when we can't

Re: [PHP-DEV] unserialize() & unicode issues

On 13.09.2005 13:32, val khokhlov wrote: Hello Antony, Tuesday, September 13, 2005, 11:21:21 AM, you wrote: AD> Even if the class name is in Unicode, we can try to convert it to ASCII AD> and fail only in the case when we can't find its class entry in the list. I think, it's not the o

Re[2]: [PHP-DEV] unserialize() & unicode issues

Hello Antony, Tuesday, September 13, 2005, 11:21:21 AM, you wrote: AD> Even if the class name is in Unicode, we can try to convert it to ASCII AD> and fail only in the case when we can't find its class entry in the list. I think, it's not the only way. If we don't care about bein

Re: [PHP-DEV] unserialize() & unicode issues

Even if the class name is in Unicode, we can try to convert it to ASCII and fail only in the case when we can't find its class entry in the list. So, I don't see any need in markers and other fairly major changes. On 13.09.2005 04:54, Andi Gutmans wrote: Not coming with a solution, but I believ