[PHP-DEV] PHP 5 Bug Summary Report
PHP 5 Bug Database summary - http://bugs.php.net Num Status Summary (490 total including feature requests) ===[*Compile Issues]== 28103 Open During ./configure you get png error instead of iodbc 28700 Open yaz recode conflict 28776 Open Make fails when installing ODBC libraries 29267 Open quoting problem in configure 29329 Open configure missing -L$MYSQL_LIB_DIR when checking for mysql_stmt_field_count 29956 Open support for s390 architecture in aclocal.m4 and configure script 31138 Feedback Invalid config check for libxml2 when enabling SOAP 31145 Open configure is using -lcpdf instead of -lcpdfm ===[*Configuration Issues] 29478 Open ignore_user_abort not in php.ini 29971 Open variables_order behaviour ===[*Directory/Filesystem functions] 29922 Assigned Huge memory usage in file copy of big files 30195 Open scandir etc cannot read Chinese file/folder name ===[*General Issues]== 29468 Open Warning POPUP whenever php-cgi.exe is executed 30306 Open tmp_name is not showing correct path 30539 Open shell doesnt close the connex after forking a process ===[*Network Functions]=== 29280 Assigned changing the default http-wrapper ===[Apache related]=== 27558 Open Location HTTP header failure [apache hooks] 29695 Open php_admin_value being overriden by php_value ===[Apache2 related]== 28373 Open Backslashes no longer escaped in $_SERVER variables 29681 Open Parent: child process exited with status 3221225477 29983 Open default_charset not set by ini_set 31055 Open per request leak proportional to the full path of the request URI 31163 Open exit status 128 on mysqli_connect() 31183 Open exit status 128 when printing something before header() ===[Arrays related]=== 29687 Open By-reference passed value inside foreach() is no longer working 30833 Assigned array_count_values modifing input array 30862 Assigned Static array with boolean indexes 30871 Open Misleading warning message for array_combine() ===[Bzip2 Related] 29521 Open compress.bzip2 wrapper ===[CGI related]== 27943 Open PHP FastCGI child exit and fork forever. 28074 Assigned Fast CGI standard compliance : stderr should be written in a FCGI stderr stream 29574 Open FastCgi server can't be used with unix domain sockets 29836 Open Wrong variables 30722 Open php://input causes hanging of web scripts 30818 Open CLI Access Violation in XP ===[Class/Object related]= 28444 Assigned Cannot access undefined property for object with overloaded property access 28491 Suspended $this may be modified indirectly inside a method 28872 Open accessing a __get (getter) method from object value fails 29458 Open Dereferencing, __get and array property 30823 Open Objects destroyed in FIFO rather LIFO. 30889 Open Conflict between __get/__set and ++ operator 30934 Open Special keyword 'self' inherited in child classes 30957 Open filesystem functions bugs in destructor (under gc condition) 30958 Open Wrong instance returned with 2 singletons 31006 Open __get : fictive attribute can be accessed only once ! 31023 Open $var = myClass::myMethod; echo $var(); does generate Error 31061 Open debug_print_backtrace reports wrong classes 31086 Open Type hinting in constructor crashes php 31109 Open cannot pass result of __get by reference ===[ClibPDF related]== 30836 Open Call to undefined function: cpdf_place_inline_image() ===[COM related]== 28117 Open chinese comparision in delphi 5 COM object 29583 Open com_dotnet crashes when trying to strlen 29669 Open Setting ADO RecordSet CursorLocation to adUseClient causes query delay 29973 Assigned Comparing COM object variable with NULL throws an exception 30461 Assigned Failed to Instantiate .Net Object error (again) 30979 Open Cant load COM 31005 Open office web compenonts can't work in php5 normally 31040 Assigned Bad parameters when getting some events from browser ===[Compile Failure]== 27729 Suspended cant compile ext/sqlite as shared 28157 Open error: storage size of
Re: [PHP-DEV] ftp_get_resp ftp_get_conv functions
Jesse, By the way, I would guess that reallocating memory in the area of a few K would be negligible to sending FTP commands over the network. So in this case I wouldn't worry about it too much and I agree with Wez suggestion to look at smart_str API. Andi At 04:51 PM 12/16/2004 -0500, Wez Furlong wrote: Check out either the smart_str API or simply log the conversation to a user-supplied stream. --Wez. On Thu, 16 Dec 2004 11:02:43 -0700, Binam, Jesse [EMAIL PROTECTED] wrote: Agreed. That was a bad idea. After I slept on it, I regreted sending that, cause the default memory limit is 8M (with the exception of the cli sapi). With no option on whether or not to do the trace and 2500x4096 being a 10M buffer, I imagine just calling ftp_connect would put you over your memory limit. So I will change it to allocate the memory dynamically, and an optional parmeter to ftp_connect on whether or not to do the trace at all. But now I need some advise from you experts... I can't imagine getting a 4k response or sending a 4k command on the control channel of an FTP session. So that is a lot of unused memory, on the other hand, that's how big the input/output buffers are and without knowing what the length of the longest response/command is until the whole conversation is finished, if my string buffer is to small, it will either truncate the string (with proper bounds checking) or create the potential for a buffer overflow. I could check the length of the string and if it is longer than the current length of the string array, then allocate enough memory to hold it, increasing the length of the element for all the other strings. In which case I would think it appropriate to #define MAX_RESP_LENGTH to prevent potential for a DOS. Also allocating N+1 elements every time a command is sent or a response is received would create a ton of overhead because wouldn't I would have to allocate the new buffer, then copy the current buffer in to it resulting in a serious performance hit? Regretfully ignorant, Jess -Original Message- From: Kamesh Jayachandran [mailto:[EMAIL PROTECTED] Sent: Thursday, December 16, 2004 6:57 AM To: Binam, Jesse; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] ftp_get_resp ftp_get_conv functions Hi Jesse, 2500*4096 = 10M on ftpbuf would be too much for the user who is not interested in this functionality. It should be allocating the memory dynamically instead of hardcoding the size to 2500. This need to happen only when requested, may be some option argument to ftp_connect whether to track the ftp conversation. With regards Kamesh Jayachandran On Wed, 15 Dec 2004 21:47:09 -0700, Binam, Jesse [EMAIL PROTECTED] said: The attached diff adds 2 ftp functions. I read the README.SUBMITTING_PATCH and went thru all the steps, but there are no tests for ftp, and I didn't understand how to update the docs. So if someone would like to help me with that, great. Basically, I modifed ftpbuf_t adding a 2 dimensional array (array of strings) to store the conversation, and an int that indicates the next element in first dimension the array. I modified ftp_putcmd and ftp_getresp to add what gets sent/recvd in the conversation. And lastly I added ftp_get_resp which returns the 3 digit return code from the server of the last command sent, and ftp_get_conv (which I would not be opposed to changing the name of, that's just what I came up with) that returns the ftp conversation as an array. Both functions must be called before ftp_close (or ftp_quit) because it frees the resource. The array I defined is 2500x4096. 4096 was already there as the FTP_BUFSIZE, 2500 maybe a little excesive but in my environment it could get that bad. :/ So I was thinking that maybe I should add a optional flag on ftp_connect on where or not to trace the conversation? Thoughts? Jess -- 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-DEV] Why we don’t like PHP / PHP’s anti-Apache2 FUD
Via PlanetApache: - http://drbacchus.com/wordpress/index.php?p=843 - http://drbacchus.com/wordpress/index.php?p=844 Season's Greetings, Sebastian -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Please Update Your PayPal Account
Dear PayPal Customer This e-mail is the notification of recent innovations taken by PayPal to detect inactive customers and non-functioning mailboxes. The inactive customers are subject to restriction and removal in the next 1 month. Please confirm your email address and credit card information by clicking the link below: https://www.paypal.com/cgi-bin/webscr?cmd=_login-run This notification expires January 1, 2005 Thanks for using PayPal! This PayPal notification was sent to your mailbox. Your PayPal account is set up to receive the PayPal Periodical newsletter and product updates when you create your account. To modify your notification preferences and unsubscribe, go to https://www.paypal.com/PREFS-NOTI and log in to your account. Changes to your preferences may take several days to be reflected in our mailings. Replies to this email will not be processed. Copyright© 2004 PayPal Inc. All rights reserved. Designated trademarks and brands are the property of their respective owners.
Re: [PHP-DEV] Why we don’t like PHP / PHP’s anti-Apache2 FUD
Is the AddType stuff true? If yes, I can change the docs to AddHandler.. Nuno - Original Message - From: Sebastian Bergmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 20, 2004 2:21 PM Subject: [PHP-DEV] Why we dont like PHP / PHPs anti-Apache2 FUD Via PlanetApache: - http://drbacchus.com/wordpress/index.php?p=843 - http://drbacchus.com/wordpress/index.php?p=844 Season's Greetings, Sebastian -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why we don’t like PHP / PHP’s anti-Apache2 FUD
Like with most of the criticisms along these lines, they don't bother actually researching why something is a certain way. There was a time when there was no AddHandler directive. Addtype was the way you did this. Since AddType works with every version of Apache I never saw a reason to change this even after AddHandler was added since it is purely academic in nature. -Rasmus Nuno Lopes wrote: Is the AddType stuff true? If yes, I can change the docs to AddHandler.. Nuno -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why we don’t like PHP /
Rasmus Lerdorf wrote: Like with most of the criticisms along these lines, they don't bother actually researching why something is a certain way. There was a time when there was no AddHandler directive. Addtype was the way you did this. Since AddType works with every version of Apache I never saw a reason to change this even after AddHandler was added since it is purely academic in nature. I think that is a minor matter anyway, my own installation notes follow old practices, but it is about time that I tidied them up. The Apache2 debate is more interesting. I am just running up a nice new AMD64, with SUSE9.1 (no 9.2 disk handy), and the first thing I find - and which does not bother me at all - ONLY Apache2 in the distribution. I KNOW all the reasons for feet dragging, and I am doing it myself over VCL/Win32 and Microsoft's latest 'standards', but at some point we will all have to give in an move on. Is now not the time at least to start treating Apache2 as a current version, and start looking into the problems? -- Lester Caine - L.S.Caine Electronic Services -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why we don’t like PHP / PHP’s anti -Apache2 FUD
I would personally consider Rich Bowen an authority on the subject, and as such trust what he is saying as true. paul On Mon, 20 Dec 2004 20:28:09 -, Nuno Lopes [EMAIL PROTECTED] wrote: Is the AddType stuff true? If yes, I can change the docs to AddHandler.. Nuno - Original Message - From: Sebastian Bergmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 20, 2004 2:21 PM Subject: [PHP-DEV] Why we don't like PHP / PHP's anti-Apache2 FUD Via PlanetApache: - http://drbacchus.com/wordpress/index.php?p=843 - http://drbacchus.com/wordpress/index.php?p=844 Season's Greetings, Sebastian -- Sebastian Bergmann http://www.sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Paul Reinheimer Zend Certified Engineer -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why we don’t like PHP /
On Mon, 20 Dec 2004, Lester Caine wrote: Rasmus Lerdorf wrote: Like with most of the criticisms along these lines, they don't bother actually researching why something is a certain way. There was a time when there was no AddHandler directive. Addtype was the way you did this. Since AddType works with every version of Apache I never saw a reason to change this even after AddHandler was added since it is purely academic in nature. I think that is a minor matter anyway, my own installation notes follow old practices, but it is about time that I tidied them up. The Apache2 debate is more interesting. I am just running up a nice new AMD64, with SUSE9.1 (no 9.2 disk handy), and the first thing I find - and which does not bother me at all - ONLY Apache2 in the distribution. I KNOW all the reasons for feet dragging, and I am doing it myself over VCL/Win32 and Microsoft's latest 'standards', but at some point we will all have to give in an move on. Is now not the time at least to start treating Apache2 as a current version, and start looking into the problems? Why would we (as PHP developers) invest time in something while the current version provides us with all we need? 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] [PATCH] php.ini-(recommended|dist) whitespace noise and typo fix
Hi
I did a `diff -u php.ini-dist php.ini-recommended` to see which settings
differ. I discovered a lot of 'whitespace noise' and some typos in
comments. No big deal but I'd be glad if someone could apply the patch
attached to this mail.
Daniel
diff -ur php-4.3.10-dist/php.ini-dist php-4.3.10/php.ini-dist
--- php-4.3.10-dist/php.ini-distWed Aug 18 07:05:23 2004
+++ php-4.3.10/php.ini-dist Tue Dec 21 00:54:26 2004
@@ -108,7 +108,7 @@
; Transparent output compression using the zlib library
; Valid values for this option are 'off', 'on', or a specific buffer size
; to be used for compression (default is 4KB)
-; Note: Resulting chunk size may vary due to nature of compression. PHP
+; Note: Resulting chunk size may vary due to nature of compression. PHP
; outputs chunks that are few hundreds bytes each as a result of
; compression. If you prefer a larger chunk size for better
; performance, enable output_buffering in addition.
@@ -153,6 +153,7 @@
; reference).
allow_call_time_pass_reference = On
+;
; Safe Mode
;
safe_mode = Off
@@ -231,6 +232,7 @@
max_input_time = 60; Maximum amount of time each script may spend parsing
request data
memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)
+
;;
; Error handling and logging ;
;;
@@ -309,7 +311,7 @@
; Disable the inclusion of HTML tags in error messages.
;html_errors = Off
-
+
; If html_errors is set On PHP produces clickable error messages that direct
; to a page describing the error or function causing the error in detail.
; You can download a copy of the PHP manual from http://www.php.net/docs.php
@@ -469,7 +471,7 @@
; RFC2616 compliant header.
; Default is zero.
;cgi.rfc2616_headers = 0
-
+
; File Uploads ;
@@ -692,7 +694,7 @@
pgsql.allow_persistent = On
; Detect broken persistent links always with pg_pconnect(). Need a little
overhead.
-pgsql.auto_reset_persistent = Off
+pgsql.auto_reset_persistent = Off
; Maximum number of persistent links. -1 means no limit.
pgsql.max_persistent = -1
@@ -701,6 +703,7 @@
pgsql.max_links = -1
; Ignore PostgreSQL backends Notice message or not.
+; Notice message logging requires a little overhead.
pgsql.ignore_notice = 0
; Log PostgreSQL backends Noitce message or not.
@@ -892,7 +895,7 @@
;session.entropy_file = /dev/urandom
-; Set to {nocache,private,public,} to determine HTTP caching aspects
+; Set to {nocache,private,public,} to determine HTTP caching aspects.
; or leave this empty to avoid sending anti-caching headers.
session.cache_limiter = nocache
@@ -900,7 +903,7 @@
session.cache_expire = 180
; trans sid support is disabled by default.
-; Use of trans sid may risk your users security.
+; Use of trans sid may risk your users security.
; Use this option with caution.
; - User may send URL contains active session ID
; to other person via. email/irc/etc.
@@ -936,7 +939,7 @@
; Compatability mode with old versions of PHP 3.0.
mssql.compatability_mode = Off
-; Connec timeout
+; Connect timeout
;mssql.connect_timeout = 5
; Query timeout
diff -ur php-4.3.10-dist/php.ini-recommended php-4.3.10/php.ini-recommended
--- php-4.3.10-dist/php.ini-recommended Wed Aug 18 07:05:23 2004
+++ php-4.3.10/php.ini-recommended Tue Dec 21 00:54:55 2004
@@ -121,12 +121,12 @@
; Transparent output compression using the zlib library
; Valid values for this option are 'off', 'on', or a specific buffer size
; to be used for compression (default is 4KB)
-; Note: Resulting chunk size may vary due to nature of compression. PHP
-; outputs chunks that are few handreds bytes each as a result of
compression.
-; If you want larger chunk size for better performence, enable
output_buffering
-; also.
-; Note: output_handler must be empty if this is set 'On'
-; Instead you must use zlib.output_handler.
+; Note: Resulting chunk size may vary due to nature of compression. PHP
+; outputs chunks that are few hundreds bytes each as a result of
+; compression. If you prefer a larger chunk size for better
+; performance, enable output_buffering in addition.
+; Note: You need to use zlib.output_handler instead of the standard
+; output_handler, or otherwise the output will be corrupted.
zlib.output_compression = Off
; You cannot specify additional output handlers if zlib.output_compression
@@ -414,7 +414,7 @@
default_mimetype = text/html
;default_charset = iso-8859-1
-; Always populate the $HTTP_RAW_POST_DATA variable.
+; Always populate the $HTTP_RAW_POST_DATA variable.
;always_populate_raw_post_data = On
@@ -435,7 +435,7 @@
; cgi.force_redirect configuration below
doc_root =
-; The directory under which PHP opens the script using /~usernamem used only
+; The directory under which PHP opens the script using /~username used only
; if
Re: [PHP-DEV] Why we don’t like PHP /
On Mon, 20 Dec 2004, Lester Caine wrote: The Apache2 debate is more interesting. I am just running up a nice new AMD64, with SUSE9.1 (no 9.2 disk handy), and the first thing I find - and which does not bother me at all - ONLY Apache2 in the distribution. I KNOW all the reasons for feet dragging, and I am doing it myself over VCL/Win32 and Microsoft's latest 'standards', but at some point we will all have to give in an move on. Is now not the time at least to start treating Apache2 as a current version, and start looking into the problems? Although I cannot speak for extlib maintainers, our repository awaits your code submissions. I don't see any advantage to making claims of support when there are known corruption issues, and functinoality only in a crippled mode (for lack of a better term right now). --- Dan KalowskyI thought you died alone, http://www.deadmime.org/~danka long long time ago. [EMAIL PROTECTED]- The Man Who Sold the World [EMAIL PROTECTED] David Bowie -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why we don’t like PHP /
Derick Rethans wrote: Why would we (as PHP developers) invest time in something while the current version provides us with all we need? Because more and more people want to run Apache 2 for different reasons? According to your argument PHP would only need to support one single OS and Webserver because it provides all we need. At some point you'll have to face it: Apache 2 is becoming a popular platform. It's obviously up to you at what point you'll consider this important enough to spend time on it but a reality check every so often is never a bad thing. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why we don’t like PHP /
George Schlossnagle wrote: At some point you'll have to face it: Apache 2 is becoming a popular platform. It's obviously up to you at what point you'll consider this important enough to spend time on it but a reality check every so often is never a bad thing. Not to sound overly American, but isn't this the sort of thing that's just worked out by market forces? When enough people want the apache2 sapi to be production quality, then eventually someone will become interested enough to do the work. But isn't that exactly what is happening at the moment ? Personally, I like apache 1.3.x. I like the way it does things, and it suits me down to the ground - but I can't ignore the fact that both redhat and suse are shipping with apache2 by default. Hell, even debian testing is apache2 by default now - and you all know how long debian take to pick up on something. However, distributions are forcing this change no matter what people may or may not prefer. As such, rather than play catch-up when everything else fully supports apache2, doesn't it make sense to pre-empt that move towards a new sapi and make sure that php plays properly with apache2. I only suggest this because otherwise I see it putting people off php in the future. Put it this way, if you have a choice between php and perl, pretty similar in ease-to-learn and perl works properly with apache2 and php doesn't, which one are you going to pick ? But that's just my 2c. -- Gareth Ardron -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why we don’t like PHP /
Rasmus Lerdorf wrote: actually researching why something is a certain way. There was a time when there was no AddHandler directive. Addtype was the way you did According to the Apache documentation AddHandler appeared in Apache 1.1. I'm impressed with your memory, it's better than the memory of http://web.archive.org/web/*/http://apache.org which reaches back to Apache 1.1.1 Oct 28 1996; PHP 3 was released June 6 1998. Who wants to break with decade old traditions? PS: No, I refuse to explain that this is supposed to be funny (-:C - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why we don’t like PHP /
;) I wrote the first Apache module version of PHP in 1995 though. -Rasmus On Tue, 21 Dec 2004, Christian Schneider wrote: Rasmus Lerdorf wrote: actually researching why something is a certain way. There was a time when there was no AddHandler directive. Addtype was the way you did According to the Apache documentation AddHandler appeared in Apache 1.1. I'm impressed with your memory, it's better than the memory of http://web.archive.org/web/*/http://apache.org which reaches back to Apache 1.1.1 Oct 28 1996; PHP 3 was released June 6 1998. Who wants to break with decade old traditions? PS: No, I refuse to explain that this is supposed to be funny (-:C - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Why we don’t like PHP /
On Mon, 20 Dec 2004, Lester Caine wrote: The Apache2 debate is more interesting. I am just running up a nice new AMD64, with SUSE9.1 (no 9.2 disk handy), and the first thing I find - and which does not bother me at all - ONLY Apache2 in the distribution. I KNOW all the reasons for feet dragging, and I am doing it myself over VCL/Win32 and Microsoft's latest 'standards', but at some point we will all have to give in an move on. Is now not the time at least to start treating Apache2 as a current version, and start looking into the problems? What problems? Threading will never be fixed in the large hundreds of 3rd-party library sense. So there is nothing to fix there. The only question is whether we start recommending Apache2-prefork over Apache1. As far as I am concerned we start doing that when a majority of main PHP developers switch to Apache2-prefork. Personally I am completely unmotivated to make that change because I have a boatload of other modules written against the Apache1 API that I would need to port to Apache2 and there just isn't a killer feature in Apache2 that warrants doing all that work for me at this point and Apache1 works fine. There isn't that much for a web server to do. We just need a simple working server. If I am in the minority I don't mind suggesting people use Apache2, but we need a bunch of PHP developers to stand up and say they are using Apache2-prefork in large production systems. It has never been a matter of not liking Apache2 or having some irrational bias against it, it is purely a matter of what we use and what we know. If someone reports a problem with PHP running under Apache1 we know how to fix that. For other servers, including Apache2, the pool of people familiar enough with it to provide decent support is much smaller. The documentation should probably be changed to better reflect that and make it sound less negative towards Apache2. My personal view is that the bucket brigade API in Apache2 is unneccesarily complex and quirky and we mostly have to defeat it anyway with PHP so it doesn't add anything for us. It just gets in the way. There are a few exceptions to that, but not enough for me to be worth the complexity and the overhead. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
