[PHP-DEV] Message (Your message dated Wed, 14 Sep 2005 09:09:39...)
Your message dated Wed, 14 Sep 2005 09:09:39 +0200 with subject Test has been submitted to the moderator of the SMRF list: Dave Bott alternate [EMAIL PROTECTED]. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP6, Unicode for language functions, classes,methods, vars names
+١ (Arabic 1) Many people that program do not speak english and have difficulty distinguishing, typing, and working with english letters and digits. English terms and english transliterations of their native language do not work well for them There is no reason to restrict identifiers to English letters and digits, just because they are handy and meaningful to you. For readability and maintainability of code, it is important to allow people to use meaningful terms. The code in question may never be distributed worldwide, and in fact may only be used by people that know the author's native language. And fwiw, it reduces the cost of programmers, since hiring someone who knows PHP and can work with English requires more skills than someone who knows PHP and works in the native language. For those of you that love PHP and want to see it remain successful and utilized, localized identifiers makes it more competitive and productive. My last trip to Asia, in both Korea and Taiwan, I saw translations of books on PHP, so they do learn about PHP in their native language. Imagine implementing some complicated workflow or other process or algorithm, where each step has a name in the local language, and as a programmer, you have to come up with a meaningless (to you) string to represent it, and having to support that code... Tex Texin Internationalization Architect, Yahoo! Inc. -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 13, 2005 3:28 PM To: Andrei Zmievski; Rasmus Lerdorf Cc: Ilia Alshanetsky; [EMAIL PROTECTED]; internals Subject: 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... +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 makes for portable code. What do you mean? Why wouldn't it be portable? Because you can't read it? It will still run. Limiting identifiers to ASCII is an artificial limitation as far as I am concerned. I see no reason for it. It's not as if people are going to suddenly write code for distribution with all sorts of weird unicode identifiers. We support high-ascii today and you never see those in public code. Java has had unicode identifiers forever as well, and it doesn't seem to be a problem for them. For people writing localized code it is very nice to be able to use descriptive identifiers in their own character set. It makes it much easier to understand the code for them. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6, Unicode for language functions, classes,methods, vars names
On 9/14/05, Tex Texin [EMAIL PROTECTED] wrote: Imagine implementing some complicated workflow or other process or algorithm, where each step has a name in the local language, and as a programmer, you have to come up with a meaningless (to you) string to represent it, and having to support that code... We do that here as we are not native english speakers. I do that since the 1st day I used a computer, I do that since every songs on the local radio is in english and I do that.. oh sorry, off topic. Well, english is the language of choice for programming because everyone understands very basic english words. In a world where a lot of people from many countries have to work together (even in small local companies) then yes, english is the choice. You have documentation and inline docs to document them in your native language, like the books available in korean, french or russian. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP6, Unicode for language functions, classes,methods, vars names
Pierre, I am glad it is acceptable to you. What you say does not apply to everyone. Well, english is the language of choice for programming because everyone understands very basic english words. This is just not true. It is true for you, because you make it a requirement and then you only hire or are satisfied with people that understand english. But you turn away people that may in fact be better more skilled programmers because you require english skills. In a world where a lot of people from many countries have to work together (even in small local companies) then yes, english is the choice. Also, not true. Many environments where countries work together choose french because that is common language to them. The French also dominated parts of the world, and for those areas French is the best alternative. (Africa, middle east...) It is selfish and imperialist to insist things must only be done the one way that english speakers are comfortable with. PHP can be flexible while companies can insist on only English in their domain if they so choose. There is no reason to impose that restriction on others. Other programming languages have already gone this route. If one day we want to call from PHP to a program that made use of such identifiers, it would be a shame to not be able to, only because of an unwarranted restriction on the design. Tex Texin Internationalization Architect, Yahoo! Inc. -Original Message- From: Pierre Joye [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 14, 2005 1:38 AM To: Tex Texin Cc: Andi Gutmans; Andrei Zmievski; Rasmus Lerdorf; Ilia Alshanetsky; internals Subject: Re: [PHP-DEV] PHP6, Unicode for language functions, classes,methods, vars names On 9/14/05, Tex Texin [EMAIL PROTECTED] wrote: Imagine implementing some complicated workflow or other process or algorithm, where each step has a name in the local language, and as a programmer, you have to come up with a meaningless (to you) string to represent it, and having to support that code... We do that here as we are not native english speakers. I do that since the 1st day I used a computer, I do that since every songs on the local radio is in english and I do that.. oh sorry, off topic. Well, english is the language of choice for programming because everyone understands very basic english words. In a world where a lot of people from many countries have to work together (even in small local companies) then yes, english is the choice. You have documentation and inline docs to document them in your native language, like the books available in korean, french or russian. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] ord() on binary strings
I am with Andrei on this. Ord doesn't make strict sense, but may also be confusing when all of its functionality is taken into account. As a function that returns an int representing the first byte of a string of bytes it has limited value. Indexing that byte or using substring would be more generic and accomplish pretty much the same. There is some benefit in having ord() be available to binary for similarity, but it can also hurt you because someone might think that if their byte data represents utf-16, that ord will return the first 16 bit char. Further, (I forget) does ord do a conversion from the unicode string encoding to the runtime encoding? Wouldn't some conversion be implied for binary data then also? ugh. Tex Texin Internationalization Architect, Yahoo! Inc. -Original Message- From: Dmitry Stogov [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 7:37 AM To: 'Andrei Zmievski'; 'Derick Rethans' Cc: 'Andi Gutmans'; 'PHP Developers Mailing List' Subject: RE: [PHP-DEV] ord() on binary strings I don't see any problems with ord() for binary data. String consist from characters and ord() returns the number of character. Binary string consist from bytes and ord() returns value of byte. Dmitry. -Original Message- From: Andrei Zmievski [mailto:[EMAIL PROTECTED] Sent: Friday, September 09, 2005 5:42 PM To: Derick Rethans Cc: Andi Gutmans; PHP Developers Mailing List Subject: Re: [PHP-DEV] ord() on binary strings My argument was that ord() semantics and docs say that it works on _characters_ and this simply does not make sense for the binary strings. If we really want ord() to work on binary type, fine, but we'd better have docs that make sense then. -Andrei On Sep 9, 2005, at 12:09 AM, Derick Rethans wrote: On Thu, 8 Sep 2005, Andi Gutmans wrote: Did Andrei have a reason besides the docs? Even without IS_UNICODE/ IS_BINARY it sounds like the docs could use tuning anyway, no? Andrei: The docs say Return ASCII value of character, which doesn't make sense for binary. You can use bin2hex(), bin2hex() == ord() for binary. (Which is not true, as it doesn't return the ordinal value, just a two digit hex string) Derick: anyway, ord() always worked on string like this, seems strange to break it (and yes, it already did) Andrei: you had binary strings before? Derick: normal strings of course, but it came from a file, so it turned binary and ord() started failing Andrei: Then you should fix your code and convert that binary to something sensible if you are reading text Derick: it's not text, it's binary Andrei: if it's binary, why do you need to know the ascii value Derick: Because I'm converting a binary file to a C file (for the timezone database) Then he continues saying that it's Ok to break BC in unicode mode. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] unserialize() unicode issues
Bear with me, I don't know about how PHP uses the serialized info, but if your goal is to minimize the overhead for unicode data when unicode_semantics is off, or simply generally, and this is for a transfer file format, or storage format, then you might consider using utf-8. Since the majority of the info is ascii, it will be efficient (ascii in utf-8 is ascii). For other unicode data it will expand as needed. For file formats it is handy as many editors will read utf-8 (if the rest of the data is put into test format). You can continue to use this when unicode_semantics is on, so it is one format for all modes. Conversion between utf-8 and utf-16 is very fast and likely wont be noticed given the other tasks of I/O and packing or unpacking the remaining data. Also, utf-8 doesnt have any endian issues, as utf-16 does. hth Tex Texin Internationalization Architect, Yahoo! Inc. -Original Message- From: Pierre Joye [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 13, 2005 3:44 AM To: Antony Dovgal Cc: Derick Rethans; val khokhlov; internals@lists.php.net Subject: 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 different php, I can see a need of having unicode strings in serialize even if unicode_semantics is off. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.1.0RC2
Any last minute additions to 5.1.0RC2 or can we roll it? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.1.0RC2
On 9/14/05, Zeev Suraski [EMAIL PROTECTED] wrote: Any last minute additions to 5.1.0RC2 or can we roll it? cd php-src/pear wget http://pear.php.net/install-pear.phar for both sources and win32 releases. As a little reminder :) --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6, Unicode for language functions, classes,methods, vars names
In addition to the ongoing discussion I like to ask, how far you would like to go? If you like unicode support for functions, classes and variable names, are you willing to do the same for all the php specific function names and php language specific words? Will function and class or return (and so on) be translated / available to/in hebrew or russian only because I/somebody can not speak english? I doubt you will do that!? The arguments of those people who like to have the support for variable names should be the same for these words and function names. Why the arguments do not apply here? The whole discussion sounds really weird to me because it is focused on only a very specific part of the language construct... all arguments I have seen can be summarized as I do not understand english (well) and thats why i would like to use my language for variable and function names. But having support for unicode variable names does not make anybody be able to program like hell without knowing and understanding the language specific function names (which I assume will ever be in english) and identifiers. I do not think that it is neccessary / important to support unicode here. mike Jani Taskinen wrote: On Wed, 14 Sep 2005, Tex Texin wrote: ok, so you shouldn't program in french. For others it is fine and works better than english. Show me one such person please. One that does this using PHP. :) One that really NEEDS this to be possible.. I'm with Pierre on this, and I'm not native english speaker either. --Jani -- mike peter bretzmetropolis ag / entwicklung email: [EMAIL PROTECTED]heinestraße 72 phone: +49-7121-348-120d-72762 reutlingen fax:+49-7121-348-111http://www.metropolis-ag.de/ metropolis ag. creating social internetworks. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
The wishlist on PHP6 has grown a lot last weeks. Here is what I have missed so far: switchable behaviours in php.ini file: - enforced variable initialisation (throw E_ERROR where today E_NOTICE is triggered) - strict variable typing (This can be done with SetType already, but a nicer language construct as in other languages (I do not say C or java ;) would be nice) - automatic type conversions on|off And also I would like to see type checking on function parameters for simple types as integer, string etc... Only having this for classes is not strict enough. Also an useful feature would be const on function parameters. just my €0.01 mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP6, Unicode for language functions, classes,methods, vars names
-Original Message- From: Jani Taskinen [mailto:[EMAIL PROTECTED] On Wed, 14 Sep 2005, Tex Texin wrote: ok, so you shouldn't program in french. For others it is fine and works better than english. Show me one such person please. One that does this using PHP. :) One that really NEEDS this to be possible.. I'm with Pierre on this, and I'm not native english speaker either. --Jani I don't know that many PHP programmers... However, I have worked on programs in Finnish, and Japanese in other programming languages. As for NEEDS this to be possible, it is a usability thing. For that matter you don't need English. It used to be that identifiers in Fortran were limited to 5 characters. There is a reason the limit was lifted, so people could make more meaningful identifiers. It is fine you don't want or intend to take advantage of it. (Personally, I think more than 5 characters in an identifier is too much to type.) But why do you want to not let others use it if they so desire? As for why they don't speak up? Well this is an english speaking list... Make it available and they will come... ;-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.0.5, BC break, fatal error
On Mon, 12 Sep 2005, Pierre Joye wrote: On 9/12/05, Zeev Suraski [EMAIL PROTECTED] wrote: I don't think you're going to get a very good answer here. It boils down to what you already know - it's a bug which results in corruption, and that's the only way to fix it. The common decision was that it's more important to fix this bug than to maintain compatibility, and this even resulted in a new PHP 'family' (4.4). It's one of those cases where there's no good solution, only a choice of bad solutions. 4.4.0, correct and I do accept that. but not in 5.0.5. Derick applied the patch to 5.1 not to 5.0.5. We did agree to apply it there and not in bug fix releases (and not in security release). Or can you point me to the common decision? ;) I didn't even apply it to 5.1, otherwise it would have been a notice there too. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.0.5
On Tue, 13 Sep 2005, Scott MacVicar wrote: Any chance of getting these applied to 5.0.x and 5.1? Yes, it's on my todo list - will do that when I get back home. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ref fix revisited
On Tue, 13 Sep 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 instead of on the call? The problem is that there's no way to tell that element apart at that time. It's too late. As soon as we treat a read-only zval as if it's read/write (take a ** instead of a *), it's too late, since we can't really detect later on where it came from. Since we can detect a ref to a temp var at call time now, how about making a local copy in the function and effectively treat it as a by-value arg and also issue an E_NOTICE or an E_STRICT? I think that would solve the corruption problem without breaking BC. That's exactly what we do in 4.4. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- 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
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 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 someone bring me up to speed as to why it was done to PHP4? As I'm sure you're aware, it breaks heaps and heaps of existing code out there. It already broke heaps of code - and this problems *was* affecting application with hard to find crashes. So yes, it is worth it. We found this out the hard way yesterday when our server administrator upgraded our production server to PHP 4.4.0 (even though the Debian package description said it was a PHP 4.3.x release). We ended up with hundreds of errors and many, many vhosts stopped working correctly due to variable references should be returned by reference problems, both in my code and in third-party code, such as PHPBB instances. Uhm, they're only notices - they shouldn't show up at the website in production, now should they? And now I read that this will not be fixed in future PHP4 releases due to breaking backwards compatibility? I just don't understand... a change that breaks backwards compatibility in a large portion of the existing PHP4 code base will not be fixed because it breaks backwards compatibility? It's doing my head in, please can someone explain? PHP 4 is not going to change the behavior anymore. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: ref fix revisited
Rasmus Lerdorf wrote:
SquirrelMail has code like this all over the place:
$value = strtolower(array_shift(split('/\w/',trim($value;
Here array_shift() does of course change the arg, so that is a potential
problem. And yes, that's a dumb way to do this, but people write code
like this. In some of these array manipulation calls, which seems to
account for a number of the BC problems we are having, we could check
for a non-ref and behave slightly differently. In the case of
array_shift() we could return the first arg and throw a notice. Same
would go for reset(), end(), next(), prev() and probably a few others.
I noticed the same problem with array_pop(). I'm happy with the new
fatal error for user-space functions. But nobody - at least non-devs -
knows that functions like array_pop() may not be used the way you
described here anymore. It's not documented somewhere and it's hard to
understand why. Many PHP programmers put more than one function in a row
(I know it's bad style), so there a lot of such code out there.
Would be great if that behaviour could be fixed.
What I don't understand - upgrading from 5.0.4 to 5.0.5 broke by far
more applications on my servers, than upgrading from 4.x to 5.x! And
there was no information in the News/ChangeLog.
For an admin it looked like a small, non-BC-braking security update
which should be installed as soon as possible, without any risk to break
scripts working with PHP 5.0.4.
And in 5.0.5 it's fatal error, not only notice.
best regards
Andreas
--
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
On Wed, 14 Sep 2005, Leigh Makewell wrote: However, breaking BC between 4.3 and 4.4 when 4.3 is a dead branch causes can cause some problems for system admins. What happens if the software being used is never updated to 4.4? There are important security updates that need to be applied, but they can't apply them because all of their websites will stop working. I doubt any application would really stopped working - except for a friendly notice when people wrote bad code. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unserialize() unicode issues
On Tue, 13 Sep 2005, Antony Dovgal wrote: But needed, as even with the semantics off, you can get unicode strings. Which can end up as array keys. 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. Why not? An array can have a unicode string element, you want to properly serialize that, as you can't always downconvert. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ref fix revisited
At 15:36 14/09/2005, Derick Rethans wrote: On Tue, 13 Sep 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 instead of on the call? The problem is that there's no way to tell that element apart at that time. It's too late. As soon as we treat a read-only zval as if it's read/write (take a ** instead of a *), it's too late, since we can't really detect later on where it came from. Since we can detect a ref to a temp var at call time now, how about making a local copy in the function and effectively treat it as a by-value arg and also issue an E_NOTICE or an E_STRICT? I think that would solve the corruption problem without breaking BC. That's exactly what we do in 4.4. Except it is reported to break BC still.. (beyond the notices)? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names
On Tue, 13 Sep 2005, Ondrej Ivanič wrote: 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? :) ) Actually, I saw this in use in a couple of generic apps, where the french coders thought it was nice to use the � (in utf8) in their function names. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ref fix revisited
Zeev Suraski wrote: At 15:36 14/09/2005, Derick Rethans wrote: On Tue, 13 Sep 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 instead of on the call? The problem is that there's no way to tell that element apart at that time. It's too late. As soon as we treat a read-only zval as if it's read/write (take a ** instead of a *), it's too late, since we can't really detect later on where it came from. Since we can detect a ref to a temp var at call time now, how about making a local copy in the function and effectively treat it as a by-value arg and also issue an E_NOTICE or an E_STRICT? I think that would solve the corruption problem without breaking BC. That's exactly what we do in 4.4. Except it is reported to break BC still.. (beyond the notices)? The biggest BC break occured in 5.0.4-5.0.5 where some of these referrence issues cause a fatal error, not a mere notice. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6, Unicode for language functions, classes, methods, vars names
On Tue, 13 Sep 2005, 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 could run just fine. I don't see why this is a problem... Another reason to only allow ASCII is that now code can be read by anyone rather then just the people who are familiar with the particular language user. Heck, some editors do not even allow utf-8 or properly render some high-ascii chars making those scripts difficult if not impossible to edit. Again, I don't see why this support would be a problem for *you*... if other people want to use it, let them. It doesn't hurt anybody who really doesn't use it. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ref fix revisited
At 15:54 14/09/2005, Edin Kadribasic wrote: Zeev Suraski wrote: At 15:36 14/09/2005, Derick Rethans wrote: On Tue, 13 Sep 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 instead of on the call? The problem is that there's no way to tell that element apart at that time. It's too late. As soon as we treat a read-only zval as if it's read/write (take a ** instead of a *), it's too late, since we can't really detect later on where it came from. Since we can detect a ref to a temp var at call time now, how about making a local copy in the function and effectively treat it as a by-value arg and also issue an E_NOTICE or an E_STRICT? I think that would solve the corruption problem without breaking BC. That's exactly what we do in 4.4. Except it is reported to break BC still.. (beyond the notices)? The biggest BC break occured in 5.0.4-5.0.5 where some of these referrence issues cause a fatal error, not a mere notice. I think it's probably equally big, but it's besides the point. I'm trying to understand what we can do (in 5.0.6 or whatever) that will really solve the problem. The 4.4 approach at this point doesn't appear to be any better since regardless of error messages, it makes PHP behave differently than it did before. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ref fix revisited
On Wed, 14 Sep 2005, Andreas Ahlenstorf wrote:
Am 14.09.2005 um 14:36 schrieb Derick Rethans:
Since we can detect a ref to a temp var at call time now, how about
making a local copy in the function and effectively treat it as a
by-value arg and also issue an E_NOTICE or an E_STRICT? I think that
would solve the corruption problem without breaking BC.
That's exactly what we do in 4.4.
array_pop(explode('.', $name))); raises Fatal Error in PHP 4.4.0 on FreeBSD =
App broken.
Of course it does, you have a ) too much. Besides this, the following
script does not make a fatal error:
?php
$name = derick;
array_pop(explode('.', $name));
?
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ref fix revisited
Am 14.09.2005 um 15:10 schrieb Derick Rethans:
Of course it does, you have a ) too much. Besides this, the following
I should drink more coffee...
script does not make a fatal error:
?php
$name = derick;
array_pop(explode('.', $name));
?
Fatal error: Only variables can be passed by reference in /home/www/
core/media.class.php on line 221
Line 221 is this one:
$filename = sprintf('%s.%s', md5(uniqid(rand(), true)), array_pop
(explode('.', $name)));
This replacement fixes the error:
$_explode_tmp_result = explode('.', $name);
$filename = sprintf('%s.%s', md5(uniqid(rand(), true)), array_pop
($_explode_tmp_result));
A.
--
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
Derick Rethans wrote: I doubt any application would really stopped working - except for a friendly notice when people wrote bad code. Derick Except if you had read Colin's messages you would see that his code *had* stopped working. Leigh :) -- 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
On Wed, 14 Sep 2005, Leigh Makewell wrote: Derick Rethans wrote: I doubt any application would really stopped working - except for a friendly notice when people wrote bad code. Except if you had read Colin's messages you would see that his code *had* stopped working. But it just could as well have been because he was relying on the memory corruptions. Hard to tell without code. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ref fix revisited
Am 14.09.2005 um 15:40 schrieb Derick Rethans:
?php
$filename = sprintf('%s.%s', md5(uniqid(rand(), true)), array_pop
(explode('.', $name)));
echo $filename;
D'oh - I see it. My ISP changed the PHP version once again. It's now
PHP 5.0.5. I'm very very sorry for the confusion.
A.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re[2]: [PHP-DEV] unserialize() unicode issues
Hello Tex, Wednesday, September 14, 2005, 1:07:26 PM, you wrote: TT Bear with me, I don't know about how PHP uses the serialized info, but if TT your goal is to minimize the overhead for unicode data when no, now we're discussing the following issues: 1) should serialize format be portable between unicode and non-uniocde modes (Andrei says that no, for example)? 2) if yes, should it contain data in the fixed encoding (unicode), so that serialize() in non-unicode mode will do conversion, or in the script encoding (so, no conversion in serialize() is required, but we need to specify data encoding somehow)? now we have following ways of implementing serialize() in php6: 1) non-portable way: no conversion at all; serialize data created in unicode mode won't be unserialized in non-unicode mode and vice versa 2) quasi-portable way: no conversion at all; we will just unserialize what we get; but if we unserialize data in a script with different encoding, it can malfunction 3) unicode way: store all encoding-specific data in unicode (so, convert them if serialize() is called in non-unicode way); downconvert to script encoding in unserialize() is called in non-unicode way (so, you can see a double conversion in this particular case) 4) varying encoding way: store all data as-is, but also store script encoding; if we call unserialize() in a script with different encoding, convert them (double conversion can still occur, but not so often) ps: sorry for mistakes, i'm writing in a hurry -- Best regards, valmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
No NEW problems on Solaris 9, only with latest 5.1 snapshot: * make test still does not work * make install fails because some PEAR components are missing (see mail of Pierre) * configure prints out a lot of garbage when testing for bison (which is missing on my solaris machine) Uwe At 13:20 14.09.2005, Zeev Suraski wrote: Any last minute additions to 5.1.0RC2 or can we roll it? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ref fix revisited
Hello Rasmus,
my solution was (and i proposed a patch for it here) that we have a way
to allow function signatures that pass variables as const just like c++
allows. This i did because first it is faster and second it applies to
most pass by ref signatures. Or in other words we could get rid of most
pass by ref sigs. And just to note, it was declined because it would
increase complexity a tight bit.
best regards
marcus
Monday, September 12, 2005, 9:57:24 AM, you wrote:
Guys, could we take a look at making the ref to temp var fix a bit
narrower? Currently we try to catch it at call-time. This means that
something like:
current(explode(' ','a b'))
as per bug #34468 doesn't work. Now, I think there is a secondary bug
here. I see no reason for current() to take a by-ref, so this
particular one could be easily fixed. 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 memory problem happens on the write. Or perhaps better, an E_NOTICE
or E_STRICT on the call and an E_FATAL on the write. The current
E_FATAL on the call seems out of whack.
Gallery, for example, broke in a rather subtle way in their
gallery_remote2.php script which meant the various client-side tools
like iphototogallery and others got a cryptic no album at URL error
message. I had to break out ethereal to track it down to a couple of
functions where read-only function args were marked as by-ref. So they
didn't actually have a memory corruption problem yet the E_FATAL killed
them.
SquirrelMail has code like this all over the place:
$value = strtolower(array_shift(split('/\w/',trim($value;
Here array_shift() does of course change the arg, so that is a potential
problem. And yes, that's a dumb way to do this, but people write code
like this. In some of these array manipulation calls, which seems to
account for a number of the BC problems we are having, we could check
for a non-ref and behave slightly differently. In the case of
array_shift() we could return the first arg and throw a notice. Same
would go for reset(), end(), next(), prev() and probably a few others.
-Rasmus
Best regards,
Marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: crc32
Hello Sara, nice and helpfull idea best regards marcus Tuesday, September 6, 2005, 3:57:38 PM, you wrote: I'd suggest a set of filters as an add-on to the mhash extension: mhash.crc32 mhash.md5 mhash.sha1 mhash.sha256 etc -Sara - Original Message - From: Ron Korving [EMAIL PROTECTED] Newsgroups: php.internals To: internals@lists.php.net Sent: Tuesday, September 06, 2005 4:48 AM Subject: Re: crc32 With a crc function the way you propose it, such a filter could be effectively made in userspace, but you could of course also implement such a filter in the core of php which could do the same trick. Maybe both would be nice. Ron Wojtek Meler [EMAIL PROTECTED] schreef in bericht news:[EMAIL PROTECTED] Ron Korving wrote: Wouldn't it be more practical to implement these as stream filters? Sure - I was not aware PHP5 streams - I'm still using PHP4 string.base64 is good choice. But I'm not sure if crc fit to streams. You can always implement fast userland filter with such function ;) . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] pdo_sqlite error 5.1
Hello Kevin, interface traversable is only a tag. And as such it can only be implemented by either interfaces Iterator and Aggregate or by internal classes. That said there is either something wrong with the check for implementers being internal classes or PDO classes aren't internal classes when traversable gets implemented. best regards marcus Monday, September 12, 2005, 2:03:53 AM, you wrote: This one time, at band camp, Wez Furlong [EMAIL PROTECTED] wrote: Looks like implementing traversable also requires implementing some other interfaces. I've removed this line from the code in CVS, so that people can actually use the snapshots; they're currently all hard-broken with this error when a class implements traversable. I was un-aware you could directly implement traversable. My understanding was that you needed to Implement Iterator. Kevin -- Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unserialize() unicode issues
Hello Antony, why can't we put a marker there? shouldn't we be able to add a flag and allow that flag in older php versions disallowing to load those serialized data in case it shows unicode semantics? Right now we'd simply fail in case of unicode usage in any serialized data with old php versions. Adding those types now would at least to show a more specific and thus helpful error message. On te other hand havin the semantics flag being optional would allow HEAD to unserialize data from older version without any problem. regards marcus Friday, September 9, 2005, 3:58:15 PM, you wrote: On 09.09.2005 17:44, Andrei Zmievski wrote: Yes, serialization is a problem. I would actually advocate putting a marker in the serialized file that indicates what the value of unicode_semantics switch was during the serialization, and if the value is different during deserialization, refuse to load it or start a new session. One really should not be changing that switch on a whim in-between sessions. Why? It loads/works perfectly fine except for the problems I've mentioned. Also, you can't put any markers to the serialized _text_ (at least it sounds very bad to me), so it won't help you in this case. Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ref fix revisited
Zeev Suraski wrote: At 15:36 14/09/2005, Derick Rethans wrote: On Tue, 13 Sep 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 instead of on the call? The problem is that there's no way to tell that element apart at that time. It's too late. As soon as we treat a read-only zval as if it's read/write (take a ** instead of a *), it's too late, since we can't really detect later on where it came from. Since we can detect a ref to a temp var at call time now, how about making a local copy in the function and effectively treat it as a by-value arg and also issue an E_NOTICE or an E_STRICT? I think that would solve the corruption problem without breaking BC. That's exactly what we do in 4.4. Except it is reported to break BC still.. (beyond the notices)? But do we have an example of this breakage? If there is real breakage, we need to address that. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
On Wed, 14 Sep 2005, Uwe Schindler wrote: * make test still does not work Like..how? * configure prints out a lot of garbage when testing for bison (which is missing on my solaris machine) And the garbage is..? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
Yep, Observer and friends should be renamed to Spl*. At 04:20 AM 9/14/2005, Zeev Suraski wrote: Any last minute additions to 5.1.0RC2 or can we roll it? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
Hello Zeev, i tried to get any feedback from You or andi regarding SPL but none of you replied so far. Question is whether i should rename some of the new interfaces and classes to be prefixed by 'Spl'. Also should i drop all constants in SPL and instead provide class constants whcih we can do right now? Yes i know that might be BC issue but i'd say it is worth the little break and i am quite sure we shouldn't do it after 5.1 is out. And Last but not least i'd like to MFH two of the new classes if you don#t mind. marcus Wednesday, September 14, 2005, 1:20:21 PM, you wrote: Any last minute additions to 5.1.0RC2 or can we roll it? Zeev Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
At 17:39 14/09/2005, Marcus Boerger wrote: Hello Zeev, i tried to get any feedback from You or andi regarding SPL but none of you replied so far. Question is whether i should rename some of the new interfaces and classes to be prefixed by 'Spl'. Also should i drop all constants in SPL and instead provide class constants whcih we can do right now? Yes i know that might be BC issue but i'd say it is worth the little break and i am quite sure we shouldn't do it after 5.1 is out. Yes, we should do the renaming and rescoping. Can you do it today so that we can roll RC2 tomorrow? And Last but not least i'd like to MFH two of the new classes if you don#t mind. I personally don't mind. Make sure they're prefixed :) Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
At 16:18 14.09.2005, you wrote: On Wed, 14 Sep 2005, Uwe Schindler wrote: * make test still does not work Like..how? I posted this one month ago (other thread). It fails when calling test with an empty expression: [EMAIL PROTECTED]:~/install/php5-200509141230$ gmake test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). /bin/sh: test: argument expected gmake: [test] Error 1 (ignored) [EMAIL PROTECTED]:~/install/php5-200509141230$ 4.3 and 5.0 worked in the past. * configure prints out a lot of garbage when testing for bison (which is missing on my solaris machine) And the garbage is..? checking whether ln -s works... yes checking if compiler supports -R... yes checking for re2c... no configure: warning: You will need re2c 0.98 or later if you want to regenerate PHP parsers. checking for gawk... gawk checking for bison... no checking for byacc... no checking for bison version... ./configure: bison: not found AWK=gawk CC=gcc CFLAGS=-g -O2 CONFIGURE_COMMAND= './configure' '--prefix=/pangaea/gnu' '--enable-cli' '--with-nsapi=/pangaea/webserver61' '--with-sybase-ct=/opt/csw' '--with-mysql=/opt/csw/mysql4' '--enable-ftp' '--enable-versioning' '--enable-session' '--enable-trans-sid' '--with-zlib=/opt/csw' '--enable-mbstring=all' '--with-openssl=/opt/csw' '--with-gd' '--with-png-dir=/opt/csw' '--with-jpeg-dir=/opt/csw' '--with-ttf=/opt/csw' '--with-libxml-dir=/opt/csw' '--with-iconv=/opt/csw' '--with-iconv-dir=/opt/csw' '--with-xsl=/opt/csw' '--enable-soap' '--without-sqlite' '--enable-exif' '--with-curl=/opt/csw' '--with-curlwrappers' '--with-pdo-mysql=/opt/csw/mysql4' '--with-xmlrpc' '--without-pdo-sqlite' '--with-pdo-dblib=/opt/csw' CONFIG_SITE=/pangaea/gnu/share/config.site /pangaea/gnu/etc/config.site CPP=gcc -E CYGWIN= ECHO=/usr/ucb/echo EGREP=egrep EXTRA_VERSION=RC2-dev GCC=yes HOME=/pangaea HOSTNAME=pans1 HOSTTYPE=sparc ... and more crap then: with_xsl=/opt/csw with_zlib=/opt/csw x_includes=NONE x_libraries=NONE invalid configure: warning: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 (found: dummy.byacc). checking for flex... lex checking for yywrap in -ll... yes checking lex output file root... lex.yy checking whether yytext is a pointer... no checking for working const... yes checking for flex version... invalid configure: warning: flex versions supported for regeneration of the Zend/PHP parsers: 2.5.4 (found: ). checking whether to force non-PIC code in shared modules... no checking for pthreads_cflags... ^C But configure works. Greetings, Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
Marcus Boerger wrote: Hello Zeev, i tried to get any feedback from You or andi regarding SPL but none of you replied so far. Question is whether i should rename some of the new interfaces and classes to be prefixed by 'Spl'. Also should i drop all constants in SPL and instead provide class constants whcih we can do right now? Yes i know that might be BC issue but i'd say it is worth the little break and i am quite sure we shouldn't do it after 5.1 is out. And Last but not least i'd like to MFH two of the new classes if you don#t mind. Hm, prefixing new interfaces and classes with Spl is the worst thing one could do IMHO. Wouldn't it be the best to prefix *all* Spl interfaces and classes? Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
Hello Zeev, phew i take a deep breathe and give my best marcus Wednesday, September 14, 2005, 4:45:32 PM, you wrote: At 17:39 14/09/2005, Marcus Boerger wrote: Hello Zeev, i tried to get any feedback from You or andi regarding SPL but none of you replied so far. Question is whether i should rename some of the new interfaces and classes to be prefixed by 'Spl'. Also should i drop all constants in SPL and instead provide class constants whcih we can do right now? Yes i know that might be BC issue but i'd say it is worth the little break and i am quite sure we shouldn't do it after 5.1 is out. Yes, we should do the renaming and rescoping. Can you do it today so that we can roll RC2 tomorrow? And Last but not least i'd like to MFH two of the new classes if you don#t mind. I personally don't mind. Make sure they're prefixed :) Zeev Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: 5.1.0RC2
Pierre-Alain Joye wrote: On 9/14/05, Zeev Suraski [EMAIL PROTECTED] wrote: Any last minute additions to 5.1.0RC2 or can we roll it? cd php-src/pear wget http://pear.php.net/install-pear.phar for both sources and win32 releases. As a little reminder :) Quick note: windows needs go-pear.phar, I will try to take care of this and also a little php script that will grab install-pear.phar if it isn't there, so that there is no need to wget install-pear.phar for the bundler, and the end-user can always grab the latest .phar. This way, there is no wget dependency, since Andi reports that it may not be available on all systems, and no hassle for the person installing. The script will not attempt to do proxying, people with complex internet connections will just have to download it themselves. Objections? Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.1.0RC2
Greg Beaver wrote: Pierre-Alain Joye wrote: On 9/14/05, Zeev Suraski [EMAIL PROTECTED] wrote: Any last minute additions to 5.1.0RC2 or can we roll it? cd php-src/pear wget http://pear.php.net/install-pear.phar for both sources and win32 releases. As a little reminder :) Quick note: windows needs go-pear.phar, I will try to take care of this and also a little php script that will grab install-pear.phar if it isn't there, so that there is no need to wget install-pear.phar for the bundler, and the end-user can always grab the latest .phar. This way, there is no wget dependency, since Andi reports that it may not be available on all systems, and no hassle for the person installing. The script will not attempt to do proxying, people with complex internet connections will just have to download it themselves. Objections? Here! :) I have modified the build system for windows already using Pierre's suggestion (install-peaer.phar). Please check the latest 5.1 snap: http://snaps.php.net/win32/php5.1-win32-200509141430.zip Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
I agree with Edin. To be consistent, either all interfaces and classes should be prefixed or none should be prefixed. On the other hand, prefixing all the old classes/interfaces will cause BC breaks. shameless-plug This is one case where namespaces are useful. With my namespace patch, all that would have to be done is to name the class as SPL:Observer. Users can either implement SPL:Observer or first import SPL:Observer; and then implement Observer. /shameless-plug Regards, Jessie Edin Kadribasic [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Marcus Boerger wrote: Hello Zeev, i tried to get any feedback from You or andi regarding SPL but none of you replied so far. Question is whether i should rename some of the new interfaces and classes to be prefixed by 'Spl'. Also should i drop all constants in SPL and instead provide class constants whcih we can do right now? Yes i know that might be BC issue but i'd say it is worth the little break and i am quite sure we shouldn't do it after 5.1 is out. And Last but not least i'd like to MFH two of the new classes if you don#t mind. Hm, prefixing new interfaces and classes with Spl is the worst thing one could do IMHO. Wouldn't it be the best to prefix *all* Spl interfaces and classes? Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] open_basedir Issue
Hello, Can someone tell me what I'm doing wrong here? I'm using PHP 4.3.11 on Red Hat 5.0 (Cobalt). /home/sites/www.harvardchemclub.org is a symbolic link that points to /home/sites/site66. I've tried this with and without trailing slashes. I added a comment to a similar bug report years ago, which I believe has gone largely ignored, and now my comment seems to have disappeared. Anyway, here's the error: --- Warning: fopen(): open_basedir restriction in effect. File(/home/sites/www.harvardchemclub.org/web/index.html) is not within the allowed path(s): (/home/sites/site66:/home/sites/www.harvardchemclub.org:/home/think/lampshade:/home/think/whiteboard:/home/think/mail:/home/think/phpmyadmin) in /home/think/whiteboard/shared/shared.inc.php on line 565 --- Thanks, Aaron Aaron Greenspan President CEO Think Computer Corporation http://www.thinkcomputer.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
On Wed, 14 Sep 2005, Uwe Schindler wrote: At 16:18 14.09.2005, you wrote: /bin/sh: test: argument expected gmake: [test] Error 1 (ignored) [EMAIL PROTECTED]:~/install/php5-200509141230$ Do you know why this happens? :) (in Makefile, remove the -@ from the line below test:) * configure prints out a lot of garbage when testing for bison (which is missing on my solaris machine) Fixed in CVS. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] namespaces (Re: [PHP-DEV] 5.1.0RC2)
Jessie Hernandez wrote: shameless-plug This is one case where namespaces are useful. With my namespace patch, all that would have to be done is to name the class as SPL:Observer. Users can either implement SPL:Observer or first import SPL:Observer; and then implement Observer. /shameless-plug Yes, this is a right task for a namespaces. What is current status of a patch? It will be included? -- Ondrej Ivanič ([EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] namespaces (Re: [PHP-DEV] 5.1.0RC2)
What is current status of a patch? It will be included? I really hope so (for PHP6, that is). Andi said he'd have a look at the patch some time ago. I'd love to know what he and the others in charge think about this matter. - David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
Hello Jessie, well the best solution would be to drop the 'Spl' prefix for 5.1 and wait for namespaces since they are imo the only solution. marcus Wednesday, September 14, 2005, 5:34:45 PM, you wrote: I agree with Edin. To be consistent, either all interfaces and classes should be prefixed or none should be prefixed. On the other hand, prefixing all the old classes/interfaces will cause BC breaks. shameless-plug This is one case where namespaces are useful. With my namespace patch, all that would have to be done is to name the class as SPL:Observer. Users can either implement SPL:Observer or first import SPL:Observer; and then implement Observer. /shameless-plug Regards, Jessie Edin Kadribasic [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Marcus Boerger wrote: Hello Zeev, i tried to get any feedback from You or andi regarding SPL but none of you replied so far. Question is whether i should rename some of the new interfaces and classes to be prefixed by 'Spl'. Also should i drop all constants in SPL and instead provide class constants whcih we can do right now? Yes i know that might be BC issue but i'd say it is worth the little break and i am quite sure we shouldn't do it after 5.1 is out. And Last but not least i'd like to MFH two of the new classes if you don#t mind. Hm, prefixing new interfaces and classes with Spl is the worst thing one could do IMHO. Wouldn't it be the best to prefix *all* Spl interfaces and classes? Edin Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6, Unicode for language functions, classes,methods, vars names
Tex Texin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -Original Message- It is fine you don't want or intend to take advantage of it. (Personally, I think more than 5 characters in an identifier is too much to type.) But why do you want to not let others use it if they so desire? Tex, this is the one thing i dont understand about people who oppose it. if they had offered technical arguments ( a valid one maybe performance, for example), then we could have a rational discussion of pros and cons. i for one only use English identifiers (though i do speak French), but if i someone can get a Japanese source-code contract which specifies identifiers must be Katakana, then more power to us all if PHP is the language chosen to implement it. l0t3k -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: open_basedir Issue
Can someone tell me what I'm doing wrong here? I'm using PHP 4.3.11 on
Red Hat 5.0 (Cobalt). /home/sites/www.harvardchemclub.org is a symbolic
link that points to /home/sites/site66. I've tried this with and without
trailing slashes. I added a comment to a similar bug report years ago,
which I believe has gone largely ignored, and now my comment seems to
have disappeared.
What is the output of:
?php
echo realpath('/home/sites/www.harvardchemclub.org/web/index.html');
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.1.0RC2
Edin Kadribasic wrote: Greg Beaver wrote: Pierre-Alain Joye wrote: On 9/14/05, Zeev Suraski [EMAIL PROTECTED] wrote: Any last minute additions to 5.1.0RC2 or can we roll it? cd php-src/pear wget http://pear.php.net/install-pear.phar for both sources and win32 releases. As a little reminder :) Quick note: windows needs go-pear.phar, I will try to take care of this and also a little php script that will grab install-pear.phar if it isn't there, so that there is no need to wget install-pear.phar for the bundler, and the end-user can always grab the latest .phar. This way, there is no wget dependency, since Andi reports that it may not be available on all systems, and no hassle for the person installing. The script will not attempt to do proxying, people with complex internet connections will just have to download it themselves. Objections? Here! :) I have modified the build system for windows already using Pierre's suggestion (install-peaer.phar). Please check the latest 5.1 snap: http://snaps.php.net/win32/php5.1-win32-200509141430.zip Great! There is only one issue with this, which is that install-pear.phar simply uses the default installation location. This means that since this is C:\php5, PEAR will be simply be installed there without any user input. If you simply switch out install-pear.phar for go-pear.phar, it will allow users to configure this completely. go-pear.phar is at: http://pear.php.net/go-pear.phar Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
All fixed now. --Jani On Wed, 14 Sep 2005, Uwe Schindler wrote: At 16:18 14.09.2005, you wrote: On Wed, 14 Sep 2005, Uwe Schindler wrote: * make test still does not work Like..how? I posted this one month ago (other thread). It fails when calling test with an empty expression: [EMAIL PROTECTED]:~/install/php5-200509141230$ gmake test Build complete. (It is safe to ignore warnings about tempnam and tmpnam). /bin/sh: test: argument expected gmake: [test] Error 1 (ignored) [EMAIL PROTECTED]:~/install/php5-200509141230$ 4.3 and 5.0 worked in the past. * configure prints out a lot of garbage when testing for bison (which is missing on my solaris machine) And the garbage is..? checking whether ln -s works... yes checking if compiler supports -R... yes checking for re2c... no configure: warning: You will need re2c 0.98 or later if you want to regenerate PHP parsers. checking for gawk... gawk checking for bison... no checking for byacc... no checking for bison version... ./configure: bison: not found AWK=gawk CC=gcc CFLAGS=-g -O2 CONFIGURE_COMMAND= './configure' '--prefix=/pangaea/gnu' '--enable-cli' '--with-nsapi=/pangaea/webserver61' '--with-sybase-ct=/opt/csw' '--with-mysql=/opt/csw/mysql4' '--enable-ftp' '--enable-versioning' '--enable-session' '--enable-trans-sid' '--with-zlib=/opt/csw' '--enable-mbstring=all' '--with-openssl=/opt/csw' '--with-gd' '--with-png-dir=/opt/csw' '--with-jpeg-dir=/opt/csw' '--with-ttf=/opt/csw' '--with-libxml-dir=/opt/csw' '--with-iconv=/opt/csw' '--with-iconv-dir=/opt/csw' '--with-xsl=/opt/csw' '--enable-soap' '--without-sqlite' '--enable-exif' '--with-curl=/opt/csw' '--with-curlwrappers' '--with-pdo-mysql=/opt/csw/mysql4' '--with-xmlrpc' '--without-pdo-sqlite' '--with-pdo-dblib=/opt/csw' CONFIG_SITE=/pangaea/gnu/share/config.site /pangaea/gnu/etc/config.site CPP=gcc -E CYGWIN= ECHO=/usr/ucb/echo EGREP=egrep EXTRA_VERSION=RC2-dev GCC=yes HOME=/pangaea HOSTNAME=pans1 HOSTTYPE=sparc ... and more crap then: with_xsl=/opt/csw with_zlib=/opt/csw x_includes=NONE x_libraries=NONE invalid configure: warning: bison versions supported for regeneration of the Zend/PHP parsers: 1.28 1.35 1.75 1.875 2.0 (found: dummy.byacc). checking for flex... lex checking for yywrap in -ll... yes checking lex output file root... lex.yy checking whether yytext is a pointer... no checking for working const... yes checking for flex version... invalid configure: warning: flex versions supported for regeneration of the Zend/PHP parsers: 2.5.4 (found: ). checking whether to force non-PIC code in shared modules... no checking for pthreads_cflags... ^C But configure works. Greetings, Uwe - Uwe Schindler [EMAIL PROTECTED] - http://www.php.net NSAPI SAPI developer Bremen, Germany -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: open_basedir Issue
Sara, The output is: /home/sites/site66/web/index.html Thanks, Aaron Aaron Greenspan President CEO Think Computer Corporation http://www.thinkcomputer.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unserialize() unicode issues
On 14.09.2005 18:02, Marcus Boerger wrote: Hello Antony, why can't we put a marker there? shouldn't we be able to add a flag and allow that flag in older php versions disallowing to load those serialized data in case it shows unicode semantics? You mean adding a marker to be able to fail with a nice error msg? I don't think the marker is needed for that (see below). Right now we'd simply fail in case of unicode usage in any serialized data with old php versions. Yes. And I think it's reasonable as nobody told that the old versions will be forward compatible. Adding those types now would at least to show a more specific and thus helpful error message. I suppose it's better to change 4.4.1/5.0.6/5.1 to fail gracefully when they find an unknown prefix (U:). On te other hand havin the semantics flag being optional would allow HEAD to unserialize data from older version without any problem. Didn't get that paragraph... =| Do we have any problems with serialized data from older versions? I don't see any of them. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: open_basedir Issue
On 14.09.2005 22:37, Aaron Greenspan wrote: Sara, The output is: /home/sites/site66/web/index.html I guess this is the answer: All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink. (c) http://www.php.net/manual/en/features.safe-mode.php#ini.open-basedir -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: open_basedir Issue
Antony, I'm not trying to avoid the restriction by using a symbolic link. I'm trying to enforce it, yet regardless of whether I put any of the following in my allowed path: /home/sites/site66 /home/sites/site66/ /home/sites/site66/web /home/sites/site66/web/ /home/sites/www.harvardchemclub.org /home/sites/www.harvardchemclub.org/ /home/sites/www.harvardchemclub.org/web /home/sites/www.harvardchemclub.org/web/ ...or any combination thereof, I am disallowed access to my files with the aforementioned error. I think this is a bug. Aaron Aaron Greenspan President CEO Think Computer Corporation http://www.thinkcomputer.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] open_basedir Issue
Hi, Can someone tell me what I'm doing wrong here? I'm using PHP 4.3.11 on Red Hat 5.0 (Cobalt). /home/sites/www.harvardchemclub.org is a symbolic link that points to /home/sites/site66. [...] [Reformatted for readability:] Warning: fopen(): open_basedir restriction in effect. File(/home/sites/www.harvardchemclub.org/web/index.html) is not within the allowed path(s): /home/sites/site66 /home/sites/www.harvardchemclub.org /home/think/lampshade /home/think/whiteboard /home/think/mail /home/think/phpmyadmin in /home/think/whiteboard/shared/shared.inc.php on line 565 With the information you have given I think this *should* work. This is a VERY old platform to run on. Any chance you can try this on more recent OS release? - Sander. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] open_basedir Issue
Sander, Unfortunately, I can't switch the OS, and frankly, I shouldn't have to. This is a Cobalt RaQ 4i. Love them or hate them, there are thousands of these machines out there--and they're all running PHP. If this is an OS problem, and it doesn't work for me, then it's unlikely to work for anyone (which is a lot of people). I may be mistaken about the precise version number from my previous post. Here's the output of uname -a: [root web]# uname -a Linux kermit.thinkcomputer.com 2.2.16C37_III #1 Sat Apr 12 14:54:32 PDT 2003 i586 unknown ...and the first line of /var/log/dmesg: Linux version 2.2.16C37_III ([EMAIL PROTECTED]) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Sat Apr 12 14:54:32 PDT 2003 Thanks for your help, Aaron Aaron Greenspan President CEO Think Computer Corporation http://www.thinkcomputer.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
I am sure I answered but I see Zeev has now (pretty much what I answered too :) At 07:39 AM 9/14/2005, Marcus Boerger wrote: Hello Zeev, i tried to get any feedback from You or andi regarding SPL but none of you replied so far. Question is whether i should rename some of the new interfaces and classes to be prefixed by 'Spl'. Also should i drop all constants in SPL and instead provide class constants whcih we can do right now? Yes i know that might be BC issue but i'd say it is worth the little break and i am quite sure we shouldn't do it after 5.1 is out. And Last but not least i'd like to MFH two of the new classes if you don#t mind. marcus Wednesday, September 14, 2005, 1:20:21 PM, you wrote: Any last minute additions to 5.1.0RC2 or can we roll it? Zeev Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.0.5
On Thu, 8 Sep 2005, Scott MacVicar wrote: Path for 5.0.6, it would seem odd to have a different behavior on the 5.0.x branch. Committed. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unserialize() unicode issues
Hello Antony, Wednesday, September 14, 2005, 8:58:31 PM, you wrote: On 14.09.2005 18:02, Marcus Boerger wrote: Hello Antony, why can't we put a marker there? shouldn't we be able to add a flag and allow that flag in older php versions disallowing to load those serialized data in case it shows unicode semantics? You mean adding a marker to be able to fail with a nice error msg? I don't think the marker is needed for that (see below). Right now we'd simply fail in case of unicode usage in any serialized data with old php versions. Yes. And I think it's reasonable as nobody told that the old versions will be forward compatible. Adding those types now would at least to show a more specific and thus helpful error message. I suppose it's better to change 4.4.1/5.0.6/5.1 to fail gracefully when they find an unknown prefix (U:). On te other hand havin the semantics flag being optional would allow HEAD to unserialize data from older version without any problem. Didn't get that paragraph... =| Do we have any problems with serialized data from older versions? I don't see any of them. Well right now we don't fail gracefully and i don't think we should unless we are dealing with something introduced in later versions that doesn't hurt or to generate helpfull error messages that explicitly tell you what new stuff the serialized data contains the old version being runned cannot deal with (e.g. Unicode data). Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
Hello Andi, ok, i am on it right now (the one answer was from today, i received it while i was typing the other). regards marcus Wednesday, September 14, 2005, 9:55:32 PM, you wrote: I am sure I answered but I see Zeev has now (pretty much what I answered too :) At 07:39 AM 9/14/2005, Marcus Boerger wrote: Hello Zeev, i tried to get any feedback from You or andi regarding SPL but none of you replied so far. Question is whether i should rename some of the new interfaces and classes to be prefixed by 'Spl'. Also should i drop all constants in SPL and instead provide class constants whcih we can do right now? Yes i know that might be BC issue but i'd say it is worth the little break and i am quite sure we shouldn't do it after 5.1 is out. And Last but not least i'd like to MFH two of the new classes if you don#t mind. marcus Wednesday, September 14, 2005, 1:20:21 PM, you wrote: Any last minute additions to 5.1.0RC2 or can we roll it? Zeev Best regards, Marcus Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] unserialize() unicode issues
On 15.09.2005 00:12, Marcus Boerger wrote: Well right now we don't fail gracefully Right, but it could be done easily. and i don't think we should unless we are dealing with something introduced in later versions that doesn't hurt or to generate helpfull error messages that explicitly tell you what new stuff the serialized data contains the old version being runned cannot deal with (e.g. Unicode data). Yes, that's exactly what I'm talking about. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.1.0RC2
Greg Beaver wrote: Great! There is only one issue with this, which is that install-pear.phar simply uses the default installation location. This means that since this is C:\php5, PEAR will be simply be installed there without any user input. If you simply switch out install-pear.phar for go-pear.phar, it will allow users to configure this completely. go-pear.phar is at: http://pear.php.net/go-pear.phar Ok. Please check out the next snap (in two hours or so). Edin -- 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
On 9/14/05, Derick Rethans [EMAIL PROTECTED] wrote: I doubt any application would really stopped working - except for a friendly notice when people wrote bad code. Derick, I do not know if you ever learn but... Stop saying that people wrote bad codes and this is why they code could break. This is nothing else than _wrong_ and respectless. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ref fix revisited
On 9/14/05, Zeev Suraski [EMAIL PROTECTED] wrote: I think it's probably equally big, but it's besides the point. I'm trying to understand what we can do (in 5.0.6 or whatever) that will really solve the problem. The 4.4 approach at this point doesn't appear to be any better since regardless of error messages, it makes PHP behave differently than it did before. I'm not sure what we should do, a 5.0.6 without the fix at all is not acceptable for many people, I can live without though. A 5.0.6 with the fixes (ref and sec) but only notices. For 5.1.0, if we really communicate about the breaks, I see no problem to leave it as it is now. There is many new things and some other fixes can introduce bugs as well (is_a, but well fixed by instanceof). And I do not want to wait one more week to get 5.1.0 :) --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.1.0RC2
On 9/14/05, Greg Beaver [EMAIL PROTECTED] wrote: http://pear.php.net/go-pear.phar For the distros, let use the same system. If one would like to customize, he is free to use go.pear.phar at a later point. Regards, --PIerre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6, Unicode for language functions, classes,methods, vars names
On 9/14/05, Tex Texin [EMAIL PROTECTED] wrote: Pierre, I am glad it is acceptable to you. What you say does not apply to everyone. Well, english is the language of choice for programming because everyone understands very basic english words. This is just not true. It is true for you, because you make it a requirement and then you only hire or are satisfied with people that understand english. But you turn away people that may in fact be better more skilled programmers because you require english skills. In a world where a lot of people from many countries have to work together (even in small local companies) then yes, english is the choice. Also, not true. Many environments where countries work together choose french because that is common language to them. The French also dominated parts of the world, and for those areas French is the best alternative. (Africa, middle east...) It is selfish and imperialist to insist things must only be done the one way that english speakers are comfortable with. PHP can be flexible while companies can insist on only English in their domain if they so choose. There is no reason to impose that restriction on others. Other programming languages have already gone this route. If one day we want to call from PHP to a program that made use of such identifiers, it would be a shame to not be able to, only because of an unwarranted restriction on the design. Check the history, every language developement tools which tried to do it do not support it anymore. Why? For the exact same reasons listed in this thread. I'm no pollitician or geostrategy expert, but I do see that english in a _programming language_ is a good thing. Now, whether people does speak english or not is not the problem and is not our problem. I can speak german, french or english while explaining code writing source codes using english identifiers. And it's the same for many asian or russian friends with their respective languages. But the only time I tried to write code in french and I have had to explain it in another language, it does not work out and it does not work out for the other with other languages (was german and russian). I think you are just mixing end user applications requirement (i18n) and programming language requirements. Regards, --Pierre Tex Texin Internationalization Architect, Yahoo! Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
Hello Edin, well imho it makes no sense to prefix all the iterators with Spl and also most of them are released already with 5.0. Changing those is to big of a BC issue isn't it? I mean it is different from changing a few consts very rarely used to class consts. marcus Wednesday, September 14, 2005, 4:56:38 PM, you wrote: Marcus Boerger wrote: Hello Zeev, i tried to get any feedback from You or andi regarding SPL but none of you replied so far. Question is whether i should rename some of the new interfaces and classes to be prefixed by 'Spl'. Also should i drop all constants in SPL and instead provide class constants whcih we can do right now? Yes i know that might be BC issue but i'd say it is worth the little break and i am quite sure we shouldn't do it after 5.1 is out. And Last but not least i'd like to MFH two of the new classes if you don#t mind. Hm, prefixing new interfaces and classes with Spl is the worst thing one could do IMHO. Wouldn't it be the best to prefix *all* Spl interfaces and classes? Edin Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
On 9/14/05, Uwe Schindler [EMAIL PROTECTED] wrote: No NEW problems on Solaris 9, only with latest 5.1 snapshot: * make test still does not work * make install fails because some PEAR components are missing (see mail of Pierre) Uwe, _you_ have to do it while testing from CVS :) See pear/install-pear.txt. --Pierre -- 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
Derick Rethans wrote: We found this out the hard way yesterday when our server administrator upgraded our production server to PHP 4.4.0 (even though the Debian package description said it was a PHP 4.3.x release). We ended up with hundreds of errors and many, many vhosts stopped working correctly due to variable references should be returned by reference problems, both in my code and in third-party code, such as PHPBB instances. Uhm, they're only notices - they shouldn't show up at the website in production, now should they? Derick, can you show me where I said that they showed up on the website? And now I read that this will not be fixed in future PHP4 releases due to breaking backwards compatibility? I just don't understand... a change that breaks backwards compatibility in a large portion of the existing PHP4 code base will not be fixed because it breaks backwards compatibility? It's doing my head in, please can someone explain? PHP 4 is not going to change the behavior anymore. Sorry, but that doesn't really answer my question. Regards, Colin. -- 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
Derick Rethans wrote: But it just could as well have been because he was relying on the memory corruptions. Hard to tell without code. Derick As I mentioned in my reply to Rasmus above, the problem seems to be stemming from a class that acts like a map of objects. Most of my PHP4 code would pass objects around by reference to ensure operations were working on the original object, thus avoiding the creation of copies. After the upgrade to 4.4.0, the map lost integrity in that returning any object within the map by key would return the object last added to the map. I may not have provided any code, but this problem description was enough for Todd Ruth to send me a very helpful and informative e-mail on the matter (i.e. everything the same as the last added bugs), which shall help me greatly in tracking it down (thanks again, Todd!). Regards, Colin. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.1.0RC2
On 14.09.2005 15:20, Zeev Suraski wrote: Any last minute additions to 5.1.0RC2 or can we roll it? If it's not too late I'd like to fix http://bugs.php.net/bug.php?id=34505 before RC2. It'll require addition of zend_unmangle_property_name_ex() and changing several files to use it instead of zend_unmangle_property_name() (nothing serious though), as the latter may lead to segfaults etc. I'll post the patch in the morning. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Segfault
This is quite unusual, for some reason PHP segfaults after I call my function. The function deals with Resources from another module, it works, that's not the problem. The functions works exactly as anticipated, however if I call that function again or if I call die or exit PHP segfaults. Any ideas on what might be wrong? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Reference handling change and PHP 4.4.0
For the record, I have no idea how the 4.3 - 4.4 change could trigger
such a bug. I just pointed out that we've hit the symptom Colin
described many times in our company with code (yes, bad code) of
the form:
?php
function f($y) { return $y; }
$x = array('a','b','c');
foreach ($x as $y) {
// The following line is a bad use of . It doesn't
// do any good and ends up causing all the members of $z
// to be references to eachother.
$z[] = f($y);
}
var_dump($x);
var_dump($z);
?
I've played with many flavors of this user-bug, adding and
subtracting s, but have been unable to get different
behavior between 4.3 and 4.4. Colin, when you find the code
that went wild in the switch to 4.4, please post it. I'm
sure there are others that are as curious as I am. (There
may even be someone nice enough to fix the BC break if
it doesn't mean reintroducing memory corruptions.)
As long as I'm posting, I might as well put in a thank you
note for the notices. I know they're generating a lot of
heat, but it's made it s much easier to fix all of the
novice uses of s in our code.
Thanks,
Todd
... I may not have provided any code, but this problem description was
enough for Todd Ruth to send me a very helpful and informative e-mail on
the matter (i.e. everything the same as the last added bugs), which
shall help me greatly in tracking it down (thanks again, Todd!).
Regards,
Colin.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6, Unicode for language functions, classes,methods, vars names
Jani Taskinen wrote: Show me one such person please. One that does this using PHP. :) One that really NEEDS this to be possible.. It's impossible to find one as PHP doesn't support it today. Think of defining a class which encapsulates a database table, and the table name and column names are in native languages. If PHP restricts the class and function names to ascii characters, programmers need to maintain the mapping from the table name to the class name, and the column name to the set/get function name. Can you guess how painfull it would be? Think of a code generator which generates classes from database tables. What kind of class/function names the code generator could automatically generate if the programming language restricts the identifiers to ascii characters? Makoto -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6, Unicode for language functions, classes,methods, vars names
Makoto Tozawa wrote: Jani Taskinen wrote: Show me one such person please. One that does this using PHP. :) One that really NEEDS this to be possible.. It's impossible to find one as PHP doesn't support it today. Think of defining a class which encapsulates a database table, and the table name and column names are in native languages. If PHP restricts the class and function names to ascii characters, programmers need to maintain the mapping from the table name to the class name, and the column name to the set/get function name. Can you guess how painfull it would be? Think of a code generator which generates classes from database tables. What kind of class/function names the code generator could automatically generate if the programming language restricts the identifiers to ascii characters? Same goes for SOAP, COM and Java integration. All of these potentially need to map to unicode identifiers and trying to work around this would be annoying. -Rasmus -- 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
Derick Rethans wrote:
On Wed, 14 Sep 2005, Leigh Makewell wrote:
Derick Rethans wrote:
I doubt any application would really stopped working - except for a friendly
notice when people wrote bad code.
Except if you had read Colin's messages you would see that his code *had*
stopped working.
But it just could as well have been because he was relying on the memory
corruptions. Hard to tell without code.
I would like to start by apologising for this message. It's long, it's a
rant, and I know this is probably not the place, but I can't let this
slide. This sort of comment really annoys me.
Zip it up Derick! Who do you think you are to dictate whether Colin's
code is good or bad?
You are very quickly starting to annoy a lot of PHP programmers. A quick
search on this topic will find quite a few news posts, and forum threads
discussing this issue, and I have seen you posting on a lot of them. You
seem to have a So What attitude and are very quick to tell all these
people that they are writing bad code and it's not your problem. We
don't appreciate being told that we write bad code. We don't appreciate
being treated as second rate programmers. We don't like being told that
a perfectly legal statement like this $x = current(explode(' ','a b'));
is wrong and bad programming!
Who are we? We are the top 10% of PHP programmers. We are the PHP coders
who take your language and manipulate it, coerce it, and gently push it
into doing things you never imagined it for. We are the few people who
actually use 100% of PHP's abilities. We are the ones who will notice
*every* time you make a change like this. Do you want PHP to be taken
seriously and used professionaly? Well *we* are the ones who decide that
PHP is ready for the big time, and if we believe that the floor is
constantly shifting under us and making our job harder then we will
leave. If we leave PHP will be nothing but a toy box language suitable
for nothing but basic little guestbook scripts coded by school children.
I have enjoyed using PHP since the first script I wrote with it. But I
am quickly losing that enjoyment, and not because of anything that has
happened to the language. I am losing it because I feel like the PHP
community does not respect it's users. As someone who works for a
company that specialises in creating, building, and maintaining online
communities I know how important good PR is. Like it or not PHP *is* an
online community and it can be made or broken by it's people. Letting
people like Derick here mouth off is not a good way to keep your
community happy.
Leigh.
--
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
Leigh Makewell wrote:
a perfectly legal statement like this $x = current(explode(' ','a b'));
In this particular case, current() did not need to take a reference
since it doesn't modify anything. This has been fixed in CVS. That's
still not how I'd write that though. I would write:
list($x) = explode(' ','a b');
Another way to write this:
$x = array_shift(explode(' ','a b'));
This is where it gets tricky. Is this legal code? We are modifying the
argument and immediately discarding the modification. The user might
want to know about that, so to me it makes sense that this throws a
NOTICE. I do agree with folks who don't like this being a fatal error.
I don't think it should be either and this is what we have been
discussing. That doesn't change the fact that a lot of these examples
are not optimal coding examples. There are usually more direct ways
that doesn't involve a useless operation that ends up getting discarded
right away. So while the tone of some of these messages may not be
great, often the suggestion that the code in question isn't very good is
accurate.
-Rasmus
--
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
Rasmus Lerdorf wrote: This is where it gets tricky. Is this legal code? Yes it is legal because it worked. Whether it is strictly correct or not is another argument. People write bad code all the time, but it doesn't make it any less legal. In minor version changes BC is not a secondary priority. It *must* be the first, even if that means allowing things that are not strictly correct. If this isn't done then PHP will never be taken seriously. However, this is completely not the point. My rant was more about attitude than anything else. You yourself just admitted that this has been fixed in CVS. If that is so, then why was the relevant bug marked Bogus? http://bugs.php.net/bug.php?id=34468 with a wonderfully insightful comment courtesy of Derick Feel free to fix the whole engine though with a patch I don't know if you realise this or not, but PHP is very quickly becoming a joke. People critisise and joke about PHP's automatic Bogus bot that just trolls through the database and marks any submitted bugs as Bogus. What is the point of making the bug database public? Read Marcus's comment on here in response to the ever eloquent Derick again: I will no longer report bugs to php.net and you can leave all your breakages in (actually they are always marked as bogus even when they result in repeatable server crashes, so I'd given up anyway). http://phplens.com/phpeverywhere/?q=node/view/214 That is just one example. PHP is famous for it's arrogance, and this just highlights it. Why should we bother to continue to support the community when the community doesn't support us? We owe PHP nothing. There are plenty of alternatives out there. Now don't get me wrong. This is not aimed at everyone. I believe you Rasmus has tried to be diplomatic about everything, but understand that in these situations people don't look at individuals, so when a few individuals act badly people will project that onto the entity as a whole. Leigh. -- 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
Rasmus Lerdorf wrote:
So while the tone of some of these messages may not be great,
often the suggestion that the code in question isn't very good is
accurate.
Rasmus, I think where some of the concern and confusion lies is with
those of us who have been doing, or at least attempting, some heavy
OOP with PHP4. Now, PHP4 may not be the most ideal platform for OOP
(hence the changes PHP5 brings), but nevertheless it *is* there, it is
available to use, and despite it's shortcomings, use it we did.
Many of us who did some crazy OOP in PHP4 have used references heavily
because, like in PHP5, we wanted to avoid making copies of objects
everywhere. Hence, a lot of code returns by reference and assigns by
reference. At the time, I certainly didn't think I was writing bad
code - it seemed to make sense, and PHP4 happily ran it as expected
without error or complaint. Code like this, for example:
function getProcessor()
{
return $this-processor-getInstance();
}
...where the processor attribute is a dynamically-configured object
which may generate a different object instance (from getInstance() call)
depending on it's configuration. Now in 4.4, this of course generates a
notice, and has to be changed to:
function getProcessor()
{
$instance = $this-processor-getInstance();
return $instance;
}
...which to me just seems like a waste of space. This raises other
questions, for example, what if we're trying to return something by
reference and encounter a problem with returning that something? For
example, take some sort of collection or list class:
function at($index=NULL)
{
if ($this-hasIndex($index))
{
return $this-elements[$index];
}
return NULL;
}
...you want to grab an element at the specified index by reference if
it's an object. The above code used to work fine, but now of course it
generates a notice, and needs to be changed to something like:
function at($index=NULL)
{
$element = NULL;
if ($this-hasIndex($index))
{
$element = $this-elements[$index];
}
return $element;
}
These things by themselves are not a big deal, but many of us have these
little issues happening throughout our code, resulting in hundreds
upon hundreds of notices per page request. Perhaps according to the
true nature of references these examples were not the ideal way to code,
but I don't consider it bad code, and it was certainly legal and
fully-functional code for some time now. Call it awful if you like, but
it certainly made sense to me at the time.
Regards,
Colin.
--
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
Leigh Makewell wrote: Rasmus Lerdorf wrote: This is where it gets tricky. Is this legal code? Yes it is legal because it worked. Well, that is the point, it didn't actually work. Code similar to this caused memory corruption. So while you may not have seen an instant crash, over time and in certain conditions you would get unexplained crashes. In order to fix this bug we needed to check for this sort of code and in doing so we were able to fix it and also enhance the warning levels to let people detect this sort of potentially bogus code. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Segfault
Yeah...sure it's on line 42. How about some code to look at? A backtrace... Anything... -Sara - Original Message - From: RG [EMAIL PROTECTED] Newsgroups: php.internals To: internals@lists.php.net Sent: Wednesday, September 14, 2005 7:11 PM Subject: Segfault This is quite unusual, for some reason PHP segfaults after I call my function. The function deals with Resources from another module, it works, that's not the problem. The functions works exactly as anticipated, however if I call that function again or if I call die or exit PHP segfaults. Any ideas on what might be wrong? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
