Re: [PHP-DEV] zend_ini_parser.c fails to create in latest PHP6
2008/3/30, Graham Frank [EMAIL PROTECTED]: Hello, I was trying to compile the latest PHP6 dev release and I keep getting the following error: gcc: /root/php6.0-200803301630/Zend/zend_ini_parser.c: No such file or directory gcc: no input files make: *** [Zend/zend_ini_parser.lo] Error 1 you need to install re2c and run ./buildconf --force -- If debugging is the process of removing bugs, then programming must be the process of putting them in. – Edsger Dijkstra http://www.cristianrodriguez.net
Re: [PHP-DEV] Re: Backporting to 5_3
2008/3/30, Edward Z. Yang [EMAIL PROTECTED]: list($b) = 'asdf'; // $b is NULL yep, that does not work, and should IMHO emit the warning I mentioned in a previuos email... ;) -- If debugging is the process of removing bugs, then programming must be the process of putting them in. – Edsger Dijkstra http://www.cristianrodriguez.net
Re: [PHP-DEV] Re: Backporting to 5_3
2008/3/28, Hannes Magnusson [EMAIL PROTECTED]: I agree. Any functionality removal, no matter how wtf it might be, shouldn't be merged. If we could however throw E_DEPRECATED there, that would be great. I guess an E_WARNING is more appropiate Warning : list() only works on numerical arrays and assumes the numerical indices start at 0. in case of a) $a is not an array b) array index is not numeric b) the array index does not start at 0... -- If debugging is the process of removing bugs, then programming must be the process of putting them in. – Edsger Dijkstra http://www.cristianrodriguez.net
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/3/27, Richard Lynch [EMAIL PROTECTED]: As I understand the situation, if you can get ALL the sysadmins of the world to update their [bleep] timezonedb frequently, PHP can drop the internal timezonedb. OS vendors release timezone updates frecuently, there is no need for such bundled tz database, just duplicates work. -- If debugging is the process of removing bugs, then programming must be the process of putting them in. – Edsger Dijkstra http://www.cristianrodriguez.net
Re: [PHP-DEV] Backporting to 5_3
2008/3/26, Stanislav Malyshev [EMAIL PROTECTED]: - Removed support for continue and break operators with non-constant operands. (Dmitry) I'd wait for 6 with this. May break some scripts. I dont think it will break more a piece of code that doesnt really work. ;) -- If debugging is the process of removing bugs, then programming must be the process of putting them in. – Edsger Dijkstra http://www.cristianrodriguez.net
Re: [PHP-DEV] CMake SoC Proposal
2008/3/19, Scott MacVicar [EMAIL PROTECTED]: Another alternative would be to simply bundle CMake with PHP, Nope, Cmake is available in almost all distributions and in the case some of them dont have it yet, they will because sooner or later will need to integrate KDE4. Please dont bundle more stuff in PHP, life is already painful ( bundled PCRE, regexp, libzip, libgd , timezonedb..) dont add yet another duplicate task for distributors. -- If debugging is the process of removing bugs, then programming must be the process of putting them in. – Edsger Dijkstra http://www.cristianrodriguez.net
Re: [PHP-DEV] Dropping ze1_compatibility_mode (PHP 5.3)
2008/3/10, Felipe Pena [EMAIL PROTECTED]: Hello! I've backported the Dmitry's patch (HEAD) for to drop zend.ze1_compatibility_mode in PHP_5_3 branch. Would be interesting remove it in 5_3? :) +1 , because this feature does not work, so there is no point to keep it anymore. -- If debugging is the process of removing bugs, then programming must be the process of putting them in. – Edsger Dijkstra http://www.cristianrodriguez.net
Re: [PHP-DEV] Error messages for wrong coding
2008/2/19, Felipe Pena [EMAIL PROTECTED]: Em Ter, 2008-02-19 às 01:25 -0300, Cristian Rodriguez escreveu: you need to handle offset of booleans too.. Oops! Thanks. There is a similar case with unset() an offset of booleans and integers. ?php $foo = true: /* should throw a fatal error, like it does when trying to unset string offsets. actually $foo remains unchanged after unset() (!!) unset($foo[0]); Index: Zend/zend_vm_def.h === RCS file: /repository/ZendEngine2/zend_vm_def.h,v retrieving revision 1.59.2.29.2.48.2.36 diff -u -p -r1.59.2.29.2.48.2.36 zend_vm_def.h --- Zend/zend_vm_def.h 11 Feb 2008 15:46:10 - 1.59.2.29.2.48.2.36 +++ Zend/zend_vm_def.h 19 Feb 2008 14:32:18 - @@ -3281,6 +3281,7 @@ ZEND_VM_HANDLER(75, ZEND_UNSET_DIM, VAR| zend_error_noreturn(E_ERROR, Cannot unset string offsets); ZEND_VM_CONTINUE(); /* bailed out before */ default: + zend_error_noreturn(E_ERROR, Cannot unset %s offsets, zend_get_type_by_const(Z_TYPE_PP(container))); FREE_OP2(); break; } -- http://www.cristianrodriguez.net
Re: [PHP-DEV] PHP mail() header patch for SafeMode
2008/2/18, Paul van Brouwershaven [EMAIL PROTECTED]: Enabling it from the php.ini would also be a good option, the main point is to get some help with tracking the spam source in a shared hosted environment. IIRC Ilia had a better patch for this, I dont know why it hasnt been merged into PHP core. -- http://www.cristianrodriguez.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Error messages for wrong coding
2008/2/19, Cristian Rodriguez [EMAIL PROTECTED]:
2008/2/19, Felipe Pena [EMAIL PROTECTED]:
Proposed:
- Shows error message (Fatal error, as happens with objects) for
integer and float variables.
http://felipe.ath.cx/diff/bug39915.diff
+1 , fatal error for consistency.
you need to handle offset of booleans too..
?php
$foo = true;
var_dump($foo[1]);
?
Index: Zend/zend_execute.c
===
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.716.2.12.2.24.2.20
diff -u -p -r1.716.2.12.2.24.2.20 zend_execute.c
--- Zend/zend_execute.c 18 Feb 2008 12:11:47 - 1.716.2.12.2.24.2.20
+++ Zend/zend_execute.c 19 Feb 2008 04:22:41 -
@@ -1229,6 +1229,15 @@ static void zend_fetch_dimension_address
}
return;
break;
+ case IS_LONG:
+ zend_error_noreturn(E_ERROR, Cannot use
integer as array);
+ /* break intentionally missing */
+ case IS_DOUBLE:
+ zend_error_noreturn(E_ERROR, Cannot use float
as array);
+ /* break intentionally missing */
+ case IS_BOOL:
+ zend_error_noreturn(E_ERROR, Cannot use
boolean as array);
+ /* break intentionally missing */
default:
if (result) {
--
http://www.cristianrodriguez.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a final decision
2008/2/6, Derick Rethans [EMAIL PROTECTED]: I don't care that much, but I think it would matter if the functions just are there and return false (so -1). for set_magic_quotes_runtime(), if true is passed, it should still throw a fatal error, if false is passed it should not (or actually 1 yes if set_magic_quotes_runtime(true), a big fatal error ( under no circustance a warning or notice) , if false it should emit either an E_NOTICE or E_STRICT telling the magic_quotes_runtime is deprecated and that using set_magic_quotes_runtime has no effect. Although I still think this functions should be removed. -- http://www.cristianrodriguez.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a final decision
2008/2/5, Pierre Joye [EMAIL PROTECTED]: Hi, It seems that there is voice +1: remove them (as it is now in HEAD) Remove them , they are of no use. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode() bug
2008/1/25, Stanislav Malyshev [EMAIL PROTECTED]: Now this is an easy fix but would lead to bad strings silently converted to empty strings. The question is - should we have an error there? If so, which one - E_WARNING, E_NOTICE? I'm for E_WARNING. Yes , E_WARNING is the right thing to have IMHO. -- http://www.cristianrodriguez.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) / zend_API.c zend_API.h php-src/ext/standard type.c
2008/2/1, Marcus Boerger [EMAIL PROTECTED]: - Fix callable/static mess, the following will now all result in a E_STRICT . binding a dynamic function as a static callback . static call of a dynamic function . is_callable() on a static binding to a dynamic function Does not compile.. php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_register': php5.3/ext/spl/php_spl.c:423: error: too few arguments to function 'zend_is_callable_ex' php5.3/ext/spl/php_spl.c: In function 'zif_spl_autoload_unregister': php5.3/ext/spl/php_spl.c:515: error: too few arguments to function 'zend_is_callable_ex' make: *** [ext/spl/php_spl.lo] Error 1 -- http://www.cristianrodriguez.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PDO 2: Request for Comments
2008/1/29, Cristian Rodriguez [EMAIL PROTECTED]: If this idea succeeds, you have lost one potential PDO2 , I meant, potential PDO2 contributor ;) So, are PHP core developers crazy enough to be willing to sign this stuff ? ;-) -- http://www.cristianrodriguez.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PDO 2: Request for Comments
2008/1/28, Derick Rethans [EMAIL PROTECTED]: I'm totally against having a CLA on any part of PHP. Amen ! If some oorporation wants to make profit from PHP I think they shouldnt try to impose their rules, but follow the project's ones. If this idea succeeds, you have lost one potential PDO2 , I would never ever sign a CLA, it is pretty much against the OSS idea and may carry unaceptable legal risks for individuals that do this **for free**(!) although as far as I know, the CLA as is seems to be suitable only for toilet paper here :P due to large legal system differences (IANAL) -- http://www.cristianrodriguez.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
2008/1/21, Antony Dovgal [EMAIL PROTECTED]: 6) we need to remove the switch ASAP Yes :) I urge you to do this, the introduction of this setting is probably the worst design mistake in PHP history after safe_mode and register_globals . Please withdrawn this insanity before it is too late, if you dont, it will probably not work correctly anyway.. Deeply concerned, Cristian. -- http://www.cristianrodriguez.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/1/10, Pierre [EMAIL PROTECTED]: Besides the issues listed by Derick, there is two problems with these choices (distro making design changes to upstream software). Please don't add the timezone to the list of troubles. The vast mayority of PHP users obtain it via their OS vendor, isnt that enough reason to make their life easier just providing an alternative ? We sometimes have to do those design changes because the original behaviuor is simple not suitable. If distros start to use the system timezone Distros use system timezonedb for %99 of the other components(some of them far more critical than PHP) , why PHP has to be special ? I'm sure we will see very old databases on many servers in a couple of years. yes but PHP nor the distro makers are to be blamed for that, because distros **do** update the system tzdb regulary otherwise you have literally gazillions of components that will return out-of-date information. -- http://www.cristianrodriguez.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/1/10, Rasmus Lerdorf [EMAIL PROTECTED]: Making this an option for the distros is something we pretty much have to do. Yes, or otherwise distros will simple implement their own options. ;-) And yes, I know it makes life harder for people writing portable apps, but that's just the way it goes sometimes. As I said before, distros update the timezonedb everytime a change occurs, so it is really no problem. -- http://www.cristianrodriguez.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/1/9, Joe Orton [EMAIL PROTECTED]: Hi folks. It's a bit of a maintenance headache for distributions when packages include their own copy of the timezone database, since this needs to be updated frequently. +1000 :-D -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/1/9, Derick Rethans [EMAIL PROTECTED]: Why do you need this? It is simple, even releasing an update for a particular extension, trigger the whole manteniance and QA in distributions, and it unneccesary work , when the system tz is used you have QA and mantain just one component, the timezone package. jfyi: in a complete distribution, there are only 3 components that has this highly questionable behaviuor, Evolution, PHP and JAVA all the other hundred of components do the right thing or at least offer an option just like the Joe's patch. my 2 CLP. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] date/timelib: use system timezone database
2008/1/9, Ilia Alshanetsky [EMAIL PROTECTED]: The reason we do not use the system database is because it is inconsistent and likely is updated less frequently then the one included with PHP. please consider this patch as an alternative for us !! in anycase, you will probably find this patch included in distros anyway, because this particular feature causes a lot of unnecesary manteniance pain, distributions just update the system timezonedb in regular basis. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
2008/1/4, Jani Taskinen [EMAIL PROTECTED]:
As I'm +1 for OPTIONAL scalar-type hinting.
me too +1 as long as :
?php
function foo(int $a) {}
foo('5');
?
Raises an error, and is rejected because is not a valid integer, otherwise -1
--
http://www.kissofjudas.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
2008/1/5, Alain Williams [EMAIL PROTECTED]: 1 and 1 should both be acceptable to type hint 'int'. No way, 1 is an string, not an integer. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Internals read-only
remember it is OPEN source yeah, start doing something useful then.. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
2007/12/3, Ilia Alshanetsky [EMAIL PROTECTED]: I think the patch does have a value, yes, it does, what worries me is the introduction of yet another non-sense ini setting that modified the very engine behaviuor.. I think we all agree that there are way too many of those do we ? . My suggestion is that we make this feature a compile time flag. My suggestion is not to add any compile time flag, either provide it or dont. and people who feel that their applications warrant a garbage collector can enable it for their install and at the same time those who don't (general case) have no penalties of having it in place. People more commonly uses PHP from distributors, in binary form.. they dont usually decide what is enabled or not, so you have to either reccommend this feature or mark it clearly as untrusted, experimental. such switches only add more complexity, confusion for users and addtional trouble to distributors. my 2CLP. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
2007/11/18, Derick Rethans [EMAIL PROTECTED]:
I am actually thinking that it might be a good thing to add more and
more. I know my quick hack isn't the best implementation though.
Yes and it is an alternative and not a mandatory thing to use.. as long as :
?php
function foo(int $num) {
return $num
}
foo(12345) // emit fatal error, NOT accept it as valid integer
all is fine and Im all for it ;)
--
http://www.kissofjudas.net/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bring back call-time pass-by-reference
2007/11/17, Karoly Negyesi [EMAIL PROTECTED]: There are things you can't without call time pass-by-reference, huh ? are you seriuos ? care to show some proof of your statements ? -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Question about superglobals
2007/11/17, Rasmus Lerdorf [EMAIL PROTECTED]: Trust me, you will grumble a lot more at that. I agree, This is usually not a problem when you are the only person that looks at a very small amount of code, but later when app gets bigger it becomes and unmanteniable mess and I dont want the language to contribute more problems. This suggestion is a bad thing(tm) ;-) -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
2007/11/15, Sam Barrow [EMAIL PROTECTED]: I found a patch by Derick online to allow for scalar type hinting, and made it work with the newest snapshot of PHP 5.3. IIRC Hannes had a patch to implement this the right way, but unfortunately it has not been merged. . Hopefully he can publish an updated version somewhere because I agree that having this functionality is a good thing. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Preliminary PHP taint support available
2007/11/3, Wietse Venema [EMAIL PROTECTED]: OK, I have updated the apache2 module SAPI, a The CGI sapi. using this tarball ftp://ftp.porcupine.org/pub/php/php-5.2.3-taint-20071103.tar.gz does not compile /home/cristian/php5.2.3-tainted/php-5.2.3-taint-20071103/sapi/cgi/cgi_main.c: In function 'cgi_php_import_environment_variables': /home/cristian/php5.2.3-tainted/php-5.2.3-taint-20071103/sapi/cgi/cgi_main.c:514: warning: passing argument 5 of 'sapi_module.input_filter' makes integer from pointer without a cast /home/cristian/php5.2.3-tainted/php-5.2.3-taint-20071103/sapi/cgi/cgi_main.c:514: error: too few arguments to function 'sapi_module.input_filter' make: *** [sapi/cgi/cgi_main.lo] Error 1 -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] conf.d support within PHP 5.2 core ?
2007/11/7, Sriram Natarajan [EMAIL PROTECTED]: Hi Will you guys consider adding support for 'Include' file / directory support (like 'conf.d' in Apache HTTPd) so that extensions can be defined within a separate file rather than editing a single 'php.ini' ? I understand that some Linux distributions do this currently. But, I am interested in hearing if this will be considered to be delivered as part of standard PHP distribution. If in case, this can be done with the current distribution itself then I am very much interested in learning as to how this can be done. Distributions do no other thing than using the oficially provided --with-config-file-scan-dir configure option, no other black magic involved -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe mode being removed in PHP6?
2007/11/5, Mark Krenz [EMAIL PROTECTED]: Unless there is some other way in PHP of restricting where you can run programs from (can't find any), Why PHP needs to do that ? isnt that part of OS level security ? this is going to become a major problem. This is going to **solve** a major problem, this change will eliminate the false sense of security that safe_mode provides and will tell people to start securing their stuff better. safe_mode does not really resist any analysis, whoever convinced you that it is a good thing does not have a clue. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] My musings on problems I've had with the PHP community
2007/10/15, Antony Dovgal [EMAIL PROTECTED]: Thank you? Rarely, as the year advances, people is getting more and more stressed and is certainly not fun to deal with the reports. Also some people tend to think that their bug reports have to be reviewed now (I mean NOW!!!), unfortunately, they fail to recognize that the project is run by volunteers -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reference cycle collector patch
2007/10/8, David Wang [EMAIL PROTECTED]: Hey all, Now that macros for manipulating refcount and is_ref have been implemented, I'm ready to submit patches for the GC. I know you all have been waiting for this for a long time ☺. Good, I will test you patches as soon I have time to. P.S. This patch has the GC enabled by default. cool, otherwise does not make sense to have it, there are enough magic switches already ;-) -- http://www.kissofjudas.net/
Re: [PHP-DEV] substr/array_slice in []
2007/10/1, Antony Dovgal [EMAIL PROTECTED]: Yeah, too Perl-ish for me. =) I dont see the need of implementing this either. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Bug#442250: [PHP-DEV] CVE-2007-4840
On 9/18/07, Pierre Habouzit [EMAIL PROTECTED] wrote: tag 442250 + wontfix thanks see http://sourceware.org/bugzilla/show_bug.cgi?id=5043 -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 Suggested Feature List
On 9/9/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote: 12) Merge the GCC 4 -fvisibility patch That patch is a very good idea, but it does not work there are symbols that are no lomger exported on libxml extension , and although everything compiles, I ended with a broken PHP. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for macros for tracking refcount and is_ref
On 9/10/07, Marcus Boerger [EMAIL PROTECTED] wrote: And please no more magic switches that lead to broken code. that's what worries me, I dont get why people wants to introduce yet another switch to disable to garbage collector ( that will lead to different/broken behaviuor) I think there is enough non-sense already with the unicode.semantics switch thingy. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: FW: [PHP-DEV] Patch for macros for tracking refcount and is_ref
On 9/8/07, Rasmus Lerdorf [EMAIL PROTECTED] wrote: And yes, if it turns out to be 10% slower, a lot of sites are going to want to run without it. Sad, I see you have lost the notion about who are the vast mayority of your users. Facebook or any top site that requires extreme performance represents a very small (less than 10%) of your real users. Instead of discussing about speed, I think we should talk about proper behaviuor first, premature optimization is an horrible bad thing. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for macros for tracking refcount and is_ref
On 9/7/07, Andi Gutmans [EMAIL PROTECTED] wrote: Let's not run before we walk. The GC already walks. There's still testing and review and some stabilizing period we should be doing if it is disabled by default it is unlikely that people will test it with real life code even more with in you place a #if ZEND_GC around the functionality... -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch for macros for tracking refcount and is_ref
On 9/7/07, Derick Rethans [EMAIL PROTECTED] wrote: But you might want to wonder if that's not a good thing? Without the prefix there will be no indication for third party extensions that they might be doing something that's not going to work nicely with the new GC anymore. I'd prefer it to have the __gc always there. And extensions will break anyway with or without the #if ZEND_GC ps: remember to change the Zend/PHP API number as well ;) -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
On 8/29/07, Rasmus Lerdorf [EMAIL PROTECTED] wrote: What sort of script did you save a lot of memory on? It takes some very specific code for you to see noticable savings with this. I used very specific code otherwise there is no way to test if the particular enhacement work ;) I also used average and big apps in order to check if there was some regression, so far, no problem detected.( note that I did not measure speed, because I care 99% about proper behaviuor and 1% about speed) -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] What should be in 5.3?
On 8/27/07, Andi Gutmans [EMAIL PROTECTED] wrote: I think we're still far away from a working garbage collector which is production quality. Im sure it has bugs, but last time I tested the circular repository it was working really fine and the save of memory was really big ;-) -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe mode being removed in PHP6?
On 8/26/07, Mark Krenz [EMAIL PROTECTED] wrote: No, this is the wrong way to approach the problem. No, this is the right way, language level security does not replace OS level security. I'm bringing it up because its something that needs to be fixed in PHP. No, fixing this issue in PHP itself is the wrong way, the only issues that needs to be fixed in PHP are. 1. security holes of PHP itself. 2. the PHP documentation in the cases it promotes bad programming practises. 3. disabling include() and require() with URls **permantently** may help as well ;P But I'm one of the ones from the 90s that cares greatly about security. If you care greatly about security then safe_mode is certainly **not** what you need, if you think so, you have been seriously misguided. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe mode being removed in PHP6?
On 8/26/07, Mark Krenz [EMAIL PROTECTED] wrote: So what is the plan for increasing the security of PHP rather than decreasing it? The plan is probably increasing the security of PHP, and removing safe_mode is an step to do that, false sense of security is worst than no security at all, unfortunately there are lot of people that believes in the myth that safe_mode actually provides security... safe_mode is one of the worst, ill-concieved features of PHP and Im glad to see last of it. No, it does not work the way you expect, Ilia has an interesting article about this see http://ilia.ws/archives/18-PHPs-safe_mode-or-how-not-to-implement-security.html -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] bracketed namespace, unset import, removal of namespace blah;
On 8/21/07, Gregory Beaver [EMAIL PROTECTED] wrote: Hi again, The attached patch: 1) adds unset import syntax for declaring a namespace to have local import scope (it does NOT affect variable scope or the global class/function table) huh ? o_O unset import ? that's really weird. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Fwd: [PHP-CVS] cvs: php-src /ext/standard formatted_print.c]
On 8/14/07, Antony Dovgal [EMAIL PROTECTED] wrote: This patch breaks PEAR phar install on 64bit. From what I can see in the source code, it compares data in the phar with the result of sprintf(%u..), which is different on 32bit and 64bit because of this patch. Either phar should be changed to detect this situation or this patch should be reverted. Phar seems to be fixed in CVS but the phar file of PEAR does not seem to be fixed yet. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2) / zend_language_parser.y
On 8/13/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: Was there something wrong with the patch or what? Yes, it was major syntax change in minor version. A Major bugfix maybe ( yes, it was clearly a bug/misfeature) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming namespaces to packages
On 8/10/07, Marc Gear [EMAIL PROTECTED] wrote: You're absolutly right. Except for a little thing, those are not namespaces, but something more similar to packages. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] buildconf hell
On 7/19/07, Richard Lynch [EMAIL PROTECTED] wrote: Kind of a PITA... No problems here with automake-1.10 , autoconf-2.61 , libtool-1.5.22, bison-2.3. the only oldie we had to keep is flex, as PHP buildsystem wont support newer flex versions. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Always enable mail() function
On 7/10/07, Johannes Schlüter [EMAIL PROTECTED] wrote: Hi, recently I had the problem that we disable the mail() function if configure can't find the sendmail binary. Is there any real reason for this? I suspect there is no real reason, I have always wondered why is like that. I can image a few situations where the binary is in a non-standard location or PHP is compiled on a different host than used. you use sendmail_path in that case ;) http://schlueters.de/~johannes/php/php_mail_always_available.diff too. +1
Re: [PHP-DEV] RIP PHP 4?
On 7/9/07, Pierre [EMAIL PROTECTED] wrote: That's the ideal world. Unfortunately yes. They should really not use it anymore but they can and they will. No matter what we do. Right. Some Linux distributors will certainly take care of php5 for an even longer period. Yes, about 6 or 7 years more. It is not really important if it is one year or six months (not like php4 gives us a lot of work :), my preference still goes to the end of this year. From my point of view, the year is merely a marketing argument, if it helps us to get a better image, why not... IMHO this should be done this way 1. Announce **clearly** that PHP4 has reached EOL ASAP. 2. Stop any kind of non-security bugfixing **inmediately** ( well. that is happening now anyway, :-) ) This include marking as wont fix all the opened PHP4 bug reports and removing PHP4 from the version list in the bugtracker as well adding a warning in the bug report form about this. 3. Move PHP4 releases to the Museum ASAP. 4. gave users a reasonable time to discontinue security fixes (no less that 8 months IMHO) also state clearly that this covers only critical security bugs. 5. Fix the documentation, the migration to PHP5 documents are missing many backward incompatible changes. just as an example. http://php.net/manual/en/migration5.incompatible.php does not list the fact that you cannot reasign $this and that unset($this) does nothing. there are many others. 6. finally people will attempt to use backward compatibilty hacks like the horrendous and non-working like zend.ze1_compatibility_mode, it is very important to either fix it or remove it ( I suggest removing it) , there are many extensions that dont even work or crash with it enabled. my $2 chilean pesos. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On 7/6/07, Johannes Schlüter [EMAIL PROTECTED] wrote: which will just produce way more problems to hosters and developers of software for PHP 6. yes :-( .. So if unicode.semantics cannot be set at runtime with ini_set() or at least per-dir is a complete non-sense to have it, as the vast mayority of users will not be able to turn it On/off and will certainly be off in most configurations as otherwise it will break too much code. Im sorry but I dont see this ending as a good thing.. looks pretty much like more of the same old mistakes ( magic_quotes , safe_mode anyone ? this may be even worse..)
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard basic_functions.c streamsfuncs.c streamsfuncs.h /ext/standard/tests/file include_userstream_001.phpt include_userstream_002.phpt /main main.c php
On 7/3/07, sean finney [EMAIL PROTECTED] wrote: hrm.. then this could potentially be a problem for 3rd party packagers such as debian or redhat. well.. I can say is not a problem at least for openSUSE, as we dont use the (IMHO) wrong way of rebuilding extensions based in the PHP API number that other distributions use :P everytime PHP changes (does not matter where, when or why) all extensions are rebuilt automatically , this rule is not specific to PHP but an overall [and sane] rule of the build system itself. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] toString() and Object #ID
On 6/29/07, Lars Schultz [EMAIL PROTECTED] wrote: Hi there I just tried to switch from 5.1 to 5.2.3 and got thrown off right away by: Object of class MyObject could not be converted to string I googled a bit and also read any Messages in the internals list but couldn't find a decisive answer as to wether this will stay this way or not. In the PHP 5 Bug Summary Report I found Bug # 40799 change string conversion behaviour for objects not implementing __toString() which is still open. I don't want to complain or anything but I'd like to know wether it's feasible to wait for a change in this current, modified, behaviour or if it's going to stay this way. The old beahviuor was absolute non-sense.. always helpful). Is there any other way than casting an object to a string to get an objects #ID? use var_dump() or spl_object_hash for that. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] SPL PCRE as always enabled in core
On 6/6/07, Marcus Boerger [EMAIL PROTECTED] wrote: Also we have no control over mbstring's license because the license holder refuses to change mbstring library to PHP License. why he has to ? the library is not derivated work of PHP, is a plain non-sense to ask other people libraries or work to be under the PHP license. If we use the same rationale, is like asking IBM to license ICU under the PHP license for use (or bundling) with PHP6. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What is the use of unicode.semantics in PHP 6?
On 6/14/07, Jani Taskinen [EMAIL PROTECTED] wrote: I mean, if PHP 6 is about unicode, why upgrade to PHP 6 and disable it? I think if unicode.semantics remains PHP_INI_SYSTEM it is useless as most users ( people that runs in shared hosting servers) will simple not be able to turn it on, as well hosting companies will keep it off because turning it on will break applications. So, either make it at least PHP_INI_PER_DIR or remove it all togeteher ( aka.. always behave like unicode.semantics= On) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Still having lstat trouble
2007/5/23, Arnold Daniels [EMAIL PROTECTED]: Expected: link link differ I get the expected result. with apache 2.2.3 and fastcgi in both 5.2.2 and current -dev , /tmp is mounted as a separate directory with noatime on a reiserfs filesystem. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Unicode extension in PHP6
2007/5/22, Andrei Zmievski [EMAIL PROTECTED]: Nobody is breaking your code. Yes, it does break code, unicode.semantics is ZEND_INI_SYSTEM, hence I cannot even turn it off with htaccess. You are free to use unicode.semantics or turn it off. No, I cant. redistributable applications (most opensource code out there) cannot 1. rely on having php 5.2.1 or later , please see the real world out there.. very few hosts has PHP5. Since you are turning it on, Im not turning it on.. redistributable application are at mercy of the server configuration. I assume that you are willing to make some changes to your code in order to take advantage of the new features. Yes but not breaking backward compatibility. Don't forget that you can still use most of the Unicode features even with unicode.semantics=off, if it were INI_PER_DIR maybe I can, nowdays is nto possible. so it's up to you to decide. With the current situation the only alternative is to keep applications backward compatible with PHP4 and PHP5 and forget PHP6 . Hoepfully this project will learn something with the previuos experiences ( PHP5 adoption anyone? ) and think in a reasoanble backward compatibility policy. ps: I know you will tell me that people should use fastcgi..and blabla.. sure. I agree.. but that is not what the real world out there uses. Always concerned of the project direction. Sincerly Cristian. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP Unicode extension in PHP6
2007/5/22, Andrei Zmievski [EMAIL PROTECTED]: Right, it's available in 5.2.1. What's the problem? the problem is exactly that, it is backward incompatible, and PHP 5 is available in less than 20% of the hosts out there.. you can imagine that hosts running 5.2.1 are practically unexistant. and the old mistakes are repeating over and over again, this is the same reason why the PHP5 adoption is in a sorry state after 5 years, it will be much worse with PHP6 unless you change this odd policy of breaking people's code on every release. But looks like you will have to learn this lesson the hard way.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dismantling the lies...
2007/5/21, Stanislav Malyshev [EMAIL PROTECTED]: at openSUSE, we also have a patch for this issue since a few weeks, as a vendor unfortunately we have to take care of things that people here dont want to fix... http://www.flyspray.org/patches/MOPB-01-abicompatible.patch.bz2 Did you perform the performance tests for this patch? What were the results? no, no performance tests has been done over that patch, but as rasmus said. it is probably negible or acceptable for real world.. I only knows it works with real like code ( i tried ezpublish, phpmyadmin) and passes the PHP test suite correctly ( or no worse than without the patch) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Dismantling the lies...
2007/5/21, Stanislav Malyshev [EMAIL PROTECTED]: I'm moe worried about the performance - the vast mayority of users will be happy with a more secure system and will like accept a 0.0.0.0.0.0.0.0.0.1% slowdown in case it is slow.. I sometimes wonder what it is real target of PHP, the masses or a selected neglible group of users that requires extreme craze performance.. If you would have time to run a benchmark using something like bench.php and maybe some more complicated code, it'd be nice to know the result. maybe I can check that tomorrow.. but you can also run it by yourself :P However , is in your hands to end with this strange policy, you can either make the 32 bit reference counter, apply this hackaround or state publicitely in the php homepage that PHP4 will not get proper/complete security fixes anymore because you dont want to break binary compatibility to protect corporate interests or simple because it is dead. that would be clearer for users and for all the people/companies that distributes/uses your software. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
2007/5/18, Stanislav Malyshev [EMAIL PROTECTED]: Sane hosters do not rely on general-purpose language to provide security, they use OS and hardware designed for exactly that purpose. ;) unfortunately hosters has to equilibrate security vs/usability for their customers.. so disaloowing 100% access to outside world is frecuently not possible. The issue with this remote url include thingy is that is hard to find a valid use case ..does anyone has a **real** one ? why it was introduced in the first place..?? no, Im not talking about crippling the language for security reasons as some may argue..my point is this feature in the reality causes far more harm than good and it has become one of the top ways to attack applications since it's introduction..my intention is only to make people think if the hassle of adding new ini directives (like allow_url_include) or functions is worth. maybe with PHP6 this issue can be addressed from it's roots instead of adding yet another workaround. my $2. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
2007/5/18, Greg Beaver [EMAIL PROTECTED]: ?php include $_GET['dumb']; ? What about permanently removing this (mis) feature ?? , Im yet to hear any valid reason or example to continue to permit this remote include thingy, all examples I have seen are bogus and broken.. does anyone really think there are valid use cases ? (note that Im talking about include* and require* only ;) ) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
2007/5/18, Greg Beaver [EMAIL PROTECTED]: Hi, I think I have a solution that would allow user streams in PHP 6 and still satisfy paranoid hosters. s/paranoid/sane/g as it is still possible through fsockopen() and other methods to access the outside world. with a tiny :) difference, remote connections fsockopen() and friends will not parse and interprate PHP code directly unless the user eval() it..:) A firewall is the only way to truly prevent access to the outside world. yes, agree, but the remote include feature just make unintentional mistakes easy, if you look real life code that uses the url_include thingy.. in the 99% they meant readfile() ..ohh but what about fopen + eval ? well in that case the user will **always** want to eval() **explicitely** and there is nothing that PHP can do to avoid that stupiduty.. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 Preview
2007/5/17, Steph Fox [EMAIL PROTECTED]: You still need to beat the Perl 6 release folks ;) What PHP6 needs is **not** repeating the same old mistakes over and over again : 1. It should be developed without pressure, with quality being more important than schedule, or you expect the first PHP6 releases to be as buggy and broken as 5.0.x series do you ? 2. It should have the less possible BC breaks, otherwise it will end up in a much worse scenario than PHP5 is nowdays ( aka. a very small adoption after 4 years), yes , Unicode is a nice feature, but not everyone cares about that. ( I guess Europe and Asia does though) 3. pressure oever developers does not make any good, is disrespectul, specially when they are not getting paid to work. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
