Re: [PHP-DEV] pdo: patch to make leading colon unneeded for bound variables without breaking BC.
Excuse me, but what BC? I don't think this stuff has been released yet, so how could you break BC? :) --Jani On Fri, 25 Mar 2005, Thies C. Arntzen wrote: subject says it - testcase is also attached. i have updated: sqlite and oci. i have tested: sqlite and postgres (uses bind emulation). i did not look at the firebird code as it seemed "complexish" to me;-) all the other drivers seem to use the emulation (like postgres) so they should work. re, thies -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Bug #32333 - Unable to perform command line build with Ingres extension
It should work now, please test.
--Jani
On Mon, 21 Mar 2005, Croker, Grant wrote:
Modified patch applied. No need to patch php_ii.h.
--Jani
the config.w32 in cvs does not work - running 'cscript /nologo
configure.js --with-ingres' (after running buildconf) generates the
following:
Checking for iiapi.h ... C:\Ingres[GC]\ingres\files
Checking for library iilibapi.lib ...
..\..\..\..\Ingres[GC]\ingres\lib\iilibapi
.lib
C:\src\php\main\php-src\configure.js(986, 3) Microsoft JScript runtime
error: 'PHP_INGRES_II_SHARED' is undefined
the patch at the bottom corrects this, but building PHP fails with:
internal_functions.c
main\internal_functions.c(54) : error C2065: 'phpext_ingres_ptr' :
undeclared identifier
main\internal_functions.c(54) : error C2099: initializer is not a
constant
NMAKE : fatal error U1077: '"cl.exe"' : return code '0x2'
Stop.
the php_ingres.h in my original mail fixes this. At the moment the build
/configure process for windows and UNIX need bringing in to line. Until
then this kludge is needed.
grant
start-
Index: ext/ingres_ii/config.w32
===
RCS file: /repository/php-src/ext/ingres_ii/config.w32,v
retrieving revision 1.1
diff -u -b -w -B -d -r1.1 config.w32
--- ext/ingres_ii/config.w3218 Mar 2005 23:24:14 - 1.1
+++ ext/ingres_ii/config.w3221 Mar 2005 10:47:18 -
@@ -13,7 +13,7 @@
if (CHECK_HEADER_ADD_INCLUDE("iiapi.h",
"CFLAGS_INGRES", ii_system + "\\ingres\\files;" + PHP_INGRES) &&
CHECK_LIB("iilibapi.lib", "ingres",
ii_system + "\\ingres\\lib;" + PHP_INGRES)) {
AC_DEFINE('HAVE_II', 1);
- EXTENSION("ingres_ii","ii.c");
+ EXTENSION("ingres","ii.c");
} else {
// ingres is missing files
WARNING("Ingres not enabled; libraries
and headers not found in " + ii_system);
---end---
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP-DEV] Fix for 30818, 28839, 32229, 30513
On Sun, 20 Mar 2005, Kamesh Jayachandran wrote: Hi Andi, I could not see this change in CVS both in 5_0_4-dev tree and HEAD. Can someone apply my patch? Done. --Jani With regards Kamesh Jayachandran On Fri, 18 Mar 2005 13:56:25 -0800, "Andi Gutmans" <[EMAIL PROTECTED]> said: Yeah it might make sense to move that to a function. But for some reason I already see that zend_execute_API.c contains this code in HEAD. Did someone apply and I missed the commit msg? Kamesh, can you please verify if it exists in your source tree? Good catch btw. Andi At 01:46 PM 3/18/2005 +0200, val khokhlov wrote: Hello Kamesh, Friday, March 18, 2005, 1:15:53 PM, you wrote: KJ> Yes I got this fix from pass_two only. It duplicates pass_two especially KJ> the while loop. you see, i also use this part of pass_two() code in my ext. maybe, it'd be a good idea to find one place for this jump addr calculation, so it won't be duplicated? (although, it's likely a question to zend developers) -- Best regards, valmailto:[EMAIL PROTECTED] -- 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] [PATCH] mysqli: remove global symbols
If anyone objects, they'll morons. Just commit.
--Jani
On Thu, 24 Mar 2005, Joe Orton wrote:
Any objections to this patch? mysqli is defining a bunch of global
symbols which it looks like it doesn't need to. Not urgent for 5.0.4.
--- php-5.0.3/ext/mysqli/mysqli_prop.c.mysqliglobal
+++ php-5.0.3/ext/mysqli/mysqli_prop.c
@@ -57,7 +57,7 @@
p = (MYSQL_STMT *)((MY_STMT *)((MYSQLI_RESOURCE *)(obj->ptr))->ptr)->stmt
#define MYSQLI_MAP_PROPERTY_FUNC_LONG( __func, __int_func, __get_type,
__ret_type)\
-int __func(mysqli_object *obj, zval **retval TSRMLS_DC) \
+static int __func(mysqli_object *obj, zval **retval TSRMLS_DC) \
{\
__ret_type l;\
__get_type;\
@@ -77,7 +77,7 @@
}
#define MYSQLI_MAP_PROPERTY_FUNC_STRING(__func, __int_func, __get_type)\
-int __func(mysqli_object *obj, zval **retval TSRMLS_DC)\
+static int __func(mysqli_object *obj, zval **retval TSRMLS_DC)\
{\
char *c;\
__get_type;\
@@ -95,7 +95,7 @@
}
/* {{{ property link_client_version_read */
-int link_client_version_read(mysqli_object *obj, zval **retval TSRMLS_DC)
+static int link_client_version_read(mysqli_object *obj, zval **retval
TSRMLS_DC)
{
ALLOC_ZVAL(*retval);
ZVAL_LONG(*retval, MYSQL_VERSION_ID);
@@ -104,7 +104,7 @@
/* }}} */
/* {{{ property link_client_info_read */
-int link_client_info_read(mysqli_object *obj, zval **retval TSRMLS_DC)
+static int link_client_info_read(mysqli_object *obj, zval **retval TSRMLS_DC)
{
ALLOC_ZVAL(*retval);
ZVAL_STRING(*retval, MYSQL_SERVER_VERSION, 1);
@@ -113,7 +113,7 @@
/* }}} */
/* {{{ property link_connect_errno_read */
-int link_connect_errno_read(mysqli_object *obj, zval **retval TSRMLS_DC)
+static int link_connect_errno_read(mysqli_object *obj, zval **retval TSRMLS_DC)
{
ALLOC_ZVAL(*retval);
ZVAL_LONG(*retval, (long)MyG(error_no));
@@ -122,7 +122,7 @@
/* }}} */
/* {{{ property link_connect_error_read */
-int link_connect_error_read(mysqli_object *obj, zval **retval TSRMLS_DC)
+static int link_connect_error_read(mysqli_object *obj, zval **retval TSRMLS_DC)
{
ALLOC_ZVAL(*retval);
ZVAL_STRING(*retval, MyG(error_msg), 1);
@@ -148,7 +148,7 @@
/* result properties */
/* {{{ property result_type_read */
-int result_type_read(mysqli_object *obj, zval **retval TSRMLS_DC)
+static int result_type_read(mysqli_object *obj, zval **retval TSRMLS_DC)
{
MYSQL_RES *p;
@@ -167,7 +167,7 @@
/* }}} */
/* {{{ property result_lengths_read */
-int result_lengths_read(mysqli_object *obj, zval **retval TSRMLS_DC)
+static int result_lengths_read(mysqli_object *obj, zval **retval TSRMLS_DC)
{
MYSQL_RES *p;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build system support for stock FreeBSD autoconf ports
On Sun, 27 Mar 2005, Jon Parise wrote: The attached patch allows PHP's build system to recognize FreeBSD's "versioned" autoconf ports without the need for system-level symlinks or similar aliasing. It uses 'shtool path' to (attempt to) locate the appropriate autoconf / autoheader executable. I added such patch once but Sebastian got some problems with it so it was reverted. And I don't want to add this patch either unless there is very good reason to do so. There are no known problems of running buildconf with autoconf 2.13, so why shouldn't that be allowed? (it's actually PREFERRED version :) And finally: Common users should NEVER EVER run buildconf. --Jani 5B -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re[2]: [PHP-DEV] Fix for 30818, 28839, 32229, 30513
I'll commit the patch to PHP_5_0 branch after 5.0.4 is released. This is not a showstopper. --Jani On Mon, 28 Mar 2005, Kamesh Jayachandran wrote: Hi Jani, Thanks for commiting the patch. But I feel you can do the same on PHP-5.0.4-dev tree also. With regards Kamesh Jayachandran On Sat, 26 Mar 2005 04:45:58 +0200 (EET), "Jani Taskinen" <[EMAIL PROTECTED]> said: On Sun, 20 Mar 2005, Kamesh Jayachandran wrote: Hi Andi, I could not see this change in CVS both in 5_0_4-dev tree and HEAD. Can someone apply my patch? Done. --Jani With regards Kamesh Jayachandran On Fri, 18 Mar 2005 13:56:25 -0800, "Andi Gutmans" <[EMAIL PROTECTED]> said: Yeah it might make sense to move that to a function. But for some reason I already see that zend_execute_API.c contains this code in HEAD. Did someone apply and I missed the commit msg? Kamesh, can you please verify if it exists in your source tree? Good catch btw. Andi At 01:46 PM 3/18/2005 +0200, val khokhlov wrote: Hello Kamesh, Friday, March 18, 2005, 1:15:53 PM, you wrote: KJ> Yes I got this fix from pass_two only. It duplicates pass_two especially KJ> the while loop. you see, i also use this part of pass_two() code in my ext. maybe, it'd be a good idea to find one place for this jump addr calculation, so it won't be duplicated? (although, it's likely a question to zend developers) -- Best regards, valmailto:[EMAIL PROTECTED] -- 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] Build system support for stock FreeBSD autoconf ports
On Tue, 29 Mar 2005, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-03-29 11:11:27 +0300: On Sun, 27 Mar 2005, Jon Parise wrote: The attached patch allows PHP's build system to recognize FreeBSD's "versioned" autoconf ports without the need for system-level symlinks or similar aliasing. It uses 'shtool path' to (attempt to) locate the appropriate autoconf / autoheader executable. I added such patch once but Sebastian got some problems with it so it was reverted. And I don't want to add this patch either unless there is very good reason to do so. It would be interesting to know what the problems were so that they could be ironed out. He had the problems with gentoo and it's autoconf wrapper crap. And finally: Common users should NEVER EVER run buildconf. But why make hacking PHP harder? And how is it hard atm to run './buildconf' ?? If you have autoconf (any version above 2.13 works) installed, there are no problems. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build system support for stock FreeBSD autoconf ports
On Tue, 29 Mar 2005, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-03-29 15:24:07 +0300: On Tue, 29 Mar 2005, Roman Neuhauser wrote: # [EMAIL PROTECTED] / 2005-03-29 11:11:27 +0300: On Sun, 27 Mar 2005, Jon Parise wrote: The attached patch allows PHP's build system to recognize FreeBSD's "versioned" autoconf ports without the need for system-level symlinks or similar aliasing. It uses 'shtool path' to (attempt to) locate the appropriate autoconf / autoheader executable. I added such patch once but Sebastian got some problems with it so it was reverted. And I don't want to add this patch either unless there is very good reason to do so. It would be interesting to know what the problems were so that they could be ironed out. He had the problems with gentoo and it's autoconf wrapper crap. And finally: Common users should NEVER EVER run buildconf. But why make hacking PHP harder? And how is it hard atm to run './buildconf' ?? If you have autoconf (any version above 2.13 works) installed, there are no problems. I have autoconf-2.13, 2.53, 2.59, automake-1.4.5, 1.5, 1.9.4, libtool-1.3.5, 1.5.10. I have no executable named autoconf, automake, or libtool, instead, there are autoconf213, autoconf253, etc. If there are no autoconf/autoheader executables, that's no way any PHP problem. Without symlinking or installing the desired versions somewhere and munging PATH, running ./buildconf is an uber-easy way to be informed that I don't have the required tools. Life is hard sometimes. Such schemes are quite common thanks to incompatibilities between autotools versions, e. g. Subversion's buildconf equivalent accepts the names from environment, mentioning IIRC Debian installing the tools as e. g. autoconf-213. If someone can provide a patch that works in every single OS with any possible combination of autoconf* packages installed I'll be happy to commit such patch. As long as nobody can provide such patch and PROVE it won't break things for others -> no commit. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: cvs: ZendEngine2 / Zend.m4 php-src acinclude.m4
On Fri, 1 Apr 2005, David Sklar wrote: On Feb 27, 2005 8:19 AM, Jani Taskinen <[EMAIL PROTECTED]> wrote: On Sun, 27 Feb 2005, Sebastian Bergmann wrote: Jani Taskinen wrote: AC_MSG_WARN([You will need bison 1.28, 1.35, 1.75 or 1.875 if you want bison 2.0 also works (at least for me). Let's not add that to the list yet. Wait couple of months. :) FWIW, bison 2.0 also works fine for me on Fedora Core 4test1. (It's the default bison installed.) Remind me about this when FC 4 is released as 'stable' :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 Beta 1
Maybe we should first get all the tests pass before rolling
any kind of release? Here's the list of currently failing tests:
(note: some might not be bugs but just bad tests..)
ZE2 ArrayAccess::offsetGet ambiguties [tests/classes/array_access_003.phpt]
ZE2 ArrayAccess and sub Arrays [tests/classes/array_access_005.phpt]
ZE2 ArrayAccess and ASSIGN_OP operators (.=)
[tests/classes/array_access_008.phpt]
ZE2 Serializeable [tests/classes/serialize_001.phpt]
Test for buffering in core functions with implicit flush off
[tests/func/008.phpt]
Bug #22836 (returning references to NULL) [Zend/tests/bug22836.phpt]
unset() CV 5 (indirect unset() of global variable in session_start())
[Zend/tests/unset_cv05.phpt]
Bug #24155 (gdImageRotate270 rotation problem). [ext/gd/tests/bug24155.phpt]
Bug #27582 (ImageFillToBorder() on alphablending image looses alpha on fill
color) [ext/gd/tests/bug27582_1.phpt]
iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
HTML input/output [ext/mbstring/tests/htmlent.phpt]
mb_output_handler() (Shift_JIS)
[ext/mbstring/tests/mb_output_handler_shift_jis.phpt]
mb_send_mail() test 5 (lang=Simplified Chinese)
[ext/mbstring/tests/mb_send_mail05.phpt]
mb_send_mail() test 6 (lang=Traditional Chinese)
[ext/mbstring/tests/mb_send_mail06.phpt]
mb_send_mail() test 7 (lang=Korean) [ext/mbstring/tests/mb_send_mail07.phpt]
mysql connect [ext/mysql/tests/001.phpt]
Bug #29992 (foreach by reference corrupts the array)
[ext/standard/tests/array/bug29992.phpt]
Bug #31213 (Sideeffects caused by bug #29493)
[ext/standard/tests/array/bug31213.phpt]
various fputcsv() functionality tests [ext/standard/tests/file/fputcsv.phpt]
User-space streams [ext/standard/tests/file/userstreams.phpt]
Check for mktime with out-of-range parameters
[ext/standard/tests/time/003.phpt]
Bug #20382 (strtotime ("Monday", $date) produces wrong result on DST
changeover) [ext/standard/tests/time/bug20382.phpt]
Bug #21966 (date() or mktime() returning bad value for mktime month param
of '2') [ext/standard/tests/time/bug21966.phpt]
Bug #27719: mktime returns incorrect timestamp for dst days
[ext/standard/tests/time/bug27719.phpt]
Bug #32001 (xml_parse*() goes into infinite loop when autodetection in
effect) [ext/xml/tests/bug32001.phpt]
--Jani
On Sat, 2 Apr 2005, Andi Gutmans wrote:
Hey,
I'd like to roll PHP 5.1 Beta 1 very soon.
Wez, I've been waiting for PDO in order to get this going. Do you feel it's
mature enough or should I hold off some more time?
Also, has someone already integrated PDO configure switches with the old
--with-db configure switches? (i.e. the idea was that --with-mysql would
enable pdo-mysql too so that we don't get lost with a million configure
switches).
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 Beta 1
Then call it pre-alpha.
--Jani
We're talking beta (I don't mind calling it alpha either) to get PDO and the
new engine architecture tested by more people.
It doesn't mean all tests need to pass. Don't worry, bugs will be addressed
before a 5.1 release which is still very far off. But don't expect the whole
bugs.php.net DB to clean out either.
Andi
At 03:40 PM 4/3/2005 +0300, Jani Taskinen wrote:
Maybe we should first get all the tests pass before rolling
any kind of release? Here's the list of currently failing tests:
(note: some might not be bugs but just bad tests..)
ZE2 ArrayAccess::offsetGet ambiguties
[tests/classes/array_access_003.phpt]
ZE2 ArrayAccess and sub Arrays [tests/classes/array_access_005.phpt]
ZE2 ArrayAccess and ASSIGN_OP operators (.=)
[tests/classes/array_access_008.phpt]
ZE2 Serializeable [tests/classes/serialize_001.phpt]
Test for buffering in core functions with implicit flush off
[tests/func/008.phpt]
Bug #22836 (returning references to NULL) [Zend/tests/bug22836.phpt]
unset() CV 5 (indirect unset() of global variable in session_start())
[Zend/tests/unset_cv05.phpt]
Bug #24155 (gdImageRotate270 rotation problem).
[ext/gd/tests/bug24155.phpt]
Bug #27582 (ImageFillToBorder() on alphablending image looses alpha on
fill color) [ext/gd/tests/bug27582_1.phpt]
iconv stream filter [ext/iconv/tests/iconv_stream_filter.phpt]
HTML input/output [ext/mbstring/tests/htmlent.phpt]
mb_output_handler() (Shift_JIS)
[ext/mbstring/tests/mb_output_handler_shift_jis.phpt]
mb_send_mail() test 5 (lang=Simplified Chinese)
[ext/mbstring/tests/mb_send_mail05.phpt]
mb_send_mail() test 6 (lang=Traditional Chinese)
[ext/mbstring/tests/mb_send_mail06.phpt]
mb_send_mail() test 7 (lang=Korean)
[ext/mbstring/tests/mb_send_mail07.phpt]
mysql connect [ext/mysql/tests/001.phpt]
Bug #29992 (foreach by reference corrupts the array)
[ext/standard/tests/array/bug29992.phpt]
Bug #31213 (Sideeffects caused by bug #29493)
[ext/standard/tests/array/bug31213.phpt]
various fputcsv() functionality tests
[ext/standard/tests/file/fputcsv.phpt]
User-space streams [ext/standard/tests/file/userstreams.phpt]
Check for mktime with out-of-range parameters
[ext/standard/tests/time/003.phpt]
Bug #20382 (strtotime ("Monday", $date) produces wrong result on DST
changeover) [ext/standard/tests/time/bug20382.phpt]
Bug #21966 (date() or mktime() returning bad value for mktime month
param of '2') [ext/standard/tests/time/bug21966.phpt]
Bug #27719: mktime returns incorrect timestamp for dst days
[ext/standard/tests/time/bug27719.phpt]
Bug #32001 (xml_parse*() goes into infinite loop when autodetection in
effect) [ext/xml/tests/bug32001.phpt]
--Jani
On Sat, 2 Apr 2005, Andi Gutmans wrote:
Hey,
I'd like to roll PHP 5.1 Beta 1 very soon.
Wez, I've been waiting for PDO in order to get this going. Do you feel it's
mature enough or should I hold off some more time?
Also, has someone already integrated PDO configure switches with the old
--with-db configure switches? (i.e. the idea was that --with-mysql would
enable pdo-mysql too so that we don't get lost with a million configure
switches).
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build system support for stock FreeBSD autoconf ports
The patch is fine by me. It's very good idea too since it's not likely to break anyone's build whatever versions they have installed. :) Just commit. (or if you can't, I'll do it later today) --Jani On Mon, 4 Apr 2005, Jon Parise wrote: On Tue, Mar 29, 2005 at 10:43:30PM -0500, Jon Parise wrote: On Tue, Mar 29, 2005 at 04:15:38PM +0300, Jani Taskinen wrote: Such schemes are quite common thanks to incompatibilities between autotools versions, e. g. Subversion's buildconf equivalent accepts the names from environment, mentioning IIRC Debian installing the tools as e. g. autoconf-213. If someone can provide a patch that works in every single OS with any possible combination of autoconf* packages installed I'll be happy to commit such patch. As long as nobody can provide such patch and PROVE it won't break things for others -> no commit. I've read the comments and generated a second patch. This one solves my problem in a more acceptable way, by introducing two environmental variables, PHP_AUTOCONF and PHP_AUTOHEADER, which default to 'autoconf' and 'autoheader', respectively. The idea is borrowed from Subversion's buildconf equivalent (which Roman mentions above). Apologies if this got lost amongst the effort to prepare the recent set of releases, but I'm curious whether or not people find my second patch acceptable, based on the results of the prior discussion. If not, I'll know to abandon the issue. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] so called bugfix doesn't seem to be applied?
The bug #30362 has been reopened. (I could verify this with 5.1-dev too) Also added a test case into ext/standard/tests/file/ for it.. --Jani On Mon, 4 Apr 2005, Ron Korving wrote: Hi, The 5.0.4 changelog mentions a fix of stream_get_line(), but the problem seems to remain. The function keeps returning strings with the length of the first string it received. I've been waiting a long time for this fix, and now it doesn't seem to be applied somehow? I didn't compile PHP myself, I use a debian file from dotdeb.org, but the phpinfo() shows 5.0.4, so I assume it is installed relatively correctly. Could this be a bad install somehow, or is it possible that the bugfix is missing? Ron Korving -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Any intest in PHP 5.1/PDO Memory leaks?
On Tue, 5 Apr 2005, Davey wrote: As Wez knows, there are issues with OSX/PHP 5.0.x/PDO, so on What issues? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Any intest in PHP 5.1/PDO Memory leaks?
I think it would work just fine as shared too with HEAD.. Someone with Macosx should try it out. (first you need to remove the silly AC_MSG_ERROR() from ext/pdo/config.m4..) --Jani On Wed, 6 Apr 2005, Wez Furlong wrote: Rubbish. http://netevil.org/node.php?nid=202 shows how to make it compile. On Apr 6, 2005 6:49 AM, Davey <[EMAIL PROTECTED]> wrote: It doesn't compile with 5.0.x But thats nothing to do with the memleaks. - Davey Jani Taskinen wrote: On Tue, 5 Apr 2005, Davey wrote: As Wez knows, there are issues with OSX/PHP 5.0.x/PDO, so on What issues? --Jani -- 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] Build system support for stock FreeBSD autoconf ports
I made some changes to phpize now. But not using your patch since that would not have worked everywhere. Searching for these tools is _still_ a big no no. Just make sure they're in PATH. --Jani On Wed, 6 Apr 2005, Brian J. France wrote: Ok, lets try this: http://www.brianfrance.com/patch.build Brian On Apr 6, 2005, at 7:19 PM, Brian J. France wrote: On Apr 4, 2005, at 12:35 AM, Jon Parise wrote: Apologies if this got lost amongst the effort to prepare the recent set of releases, but I'm curious whether or not people find my second patch acceptable, based on the results of the prior discussion. If not, I'll know to abandon the issue. Here is a patch that we plan on using at work (Y!). This patch has two key additions to Jon's patch. The first I think should be added to Jon's patch so that shared extensions (phpize) build with his environment variable change and the second is a change so we don't have to set environment variables and it will pick up the right files. The second change may or may not make it in, but I think the first one should. The first change is in scripts/phpize.in where it tests and set PHP_AUTOCONF/PHP_AUTOHEADER variables, then uses them below. This patch should be added without the: + if ! which $PHP_AUTOCONF; then + PHP_AUTOCONF=`ls -1 /usr/local/bin/autoconf* | sort -r | head -1`; + PHP_AUTOHEADER=`ls -1 /usr/local/bin/autoheader* | sort -r | head -1`; + fi + block in it (which would be part of the second change). The second changes are the ones that do a which command to see if PHP_AUTOCONF/PHP_AUTOHEADER is really valid and if not try to find the valid one. I don't know how compatible this is across os's and is the reason I can see it not making it (but it works for us). This package also allows us to use any version of the ports/autoconf package without having to set environment variable. Let me know what you think. Thanks, Brian -- 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] Build system support for stock FreeBSD autoconf ports
On Thu, 7 Apr 2005, Brian J. France wrote: On Apr 7, 2005, at 1:28 AM, Jani Taskinen wrote: I made some changes to phpize now. But not using your patch since that would not have worked everywhere. Cool, changes look good. What about getting Jon's original patch and this change back ported? Done. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Build system support for stock FreeBSD autoconf ports
On Thu, 7 Apr 2005, Brian J. France wrote: Looks like there might be some problems with your patch to phpize.in for lines: + if ! test -x "$php_shtool path $PHP_AUTOCONF"; then and + if ! test -x "$php_shtool path $PHP_AUTOHEADER"; then shouldn't those double quotes be back-ticks? Actually both.. fixed now. Also echo and here documents are not working on my system (FreeBSD). cat seems to work with here docs. Fixed that too. (all branches) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] email getting through?
I'd be happy to commit that patch but could you at least add some comments WHY you're commenting out code in the existing parts.. Also, the new code you added should follow the CODING_STANDARDS. And please put the next patch where you've fixed these issue into the web somewhere and post an URL to the list. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update for Birdstep RDM Server / RAIMA Velocis support in PHP 4 & 5
I have committed a little bit modified version of this patch in all branches. Basically I just replaced your two 'uname' calls by using $host_alias and used $SHLIB_SUFFIX_NAME instead of .so / .sl. --Jani On Mon, 11 Apr 2005, John Higgins wrote: I would like to submit an update for the UODBC module in PHP 4 & 5. The changes update PHP's UODBC module to work with the latest versions of Birdstep's RDM Server DBMS, while maintaining compatibility with previously supported versions. The update was necessary due to a change in Birdstep's library names as well as new functionality in RDM Server. The changes affect two files, and are detailed in the diff output below. As I would like to update the latest versions of PHP 4 as well as PHP 5, I have pasted the diff output for version 5 into this post, and will reply to this post with the diff for PHP 4. Please let me know if I can do anything to make this easier... - John PHP 5 diff ** Index: ext/odbc/config.m4 === RCS file: /repository/php-src/ext/odbc/config.m4,v retrieving revision 1.72 diff -u -r1.72 config.m4 --- ext/odbc/config.m4 10 Apr 2005 19:23:59 - 1.72 +++ ext/odbc/config.m4 11 Apr 2005 17:47:11 - @@ -339,6 +339,22 @@ [ PHP_WITH_SHARED + ac_birdstep_uname_s=`uname -s 2>/dev/null` + ac_birdstep_uname_p=`uname -p 2>/dev/null` + case $ac_birdstep_uname_s in +AIX) AC_DEFINE(AIX,1,[ ]);; +HP-UX) AC_DEFINE(HPUX,1,[ ]);; +Linux) AC_DEFINE(LINUX,1,[ ]);; +QNX) AC_DEFINE(NEUTRINO,1,[ ]);; +SunOS) + if test "$ac_birdstep_uname_p" == "i386"; then +AC_DEFINE(ISOLARIS,1,[ ]) + elif test "$ac_birdstep_uname_p" == "sparc"; then +AC_DEFINE(SOLARIS,1,[ ]) + fi;; +UnixWare) AC_DEFINE(UNIXWARE,1,[ ]);; + esac + if test "$withval" != "no"; then if test "$withval" = "yes"; then ODBC_INCDIR=/usr/local/birdstep/include @@ -350,7 +366,12 @@ ODBC_INCLUDE=-I$ODBC_INCDIR ODBC_TYPE=birdstep ODBC_LFLAGS=-L$ODBC_LIBDIR - ODBC_LIBS="-lCadm -lCdict -lCenc -lCrdm -lCrpc -lCrdbc -lCrm -lCuapi -lutil" +if test -e "$ODBC_LIBDIR/libCrdbc32.so" -o -e "$ODBC_LIBDIR/libCrdbc32.sl"; then + ODBC_LIBS="-lCrdbc32 -lCadm32 -lCncp32 -lCrm32 -lCsql32 -lCdict32 -lCrdm32 -lCrpc32 -lutil" +elif test -e "$ODBC_LIBDIR/libCrdbc.so" -o -e "$ODBC_LIBDIR/libCrdbc.sl"; then + ODBC_LIBS="-lCrdbc -lCadm -lCncp -lCrm -lCsql -lCdict -lCrdm -lCrpc -lutil" +fi + AC_DEFINE(HAVE_BIRDSTEP,1,[ ]) AC_MSG_RESULT(yes) Index: ext/odbc/php_odbc.h === RCS file: /repository/php-src/ext/odbc/php_odbc.h,v retrieving revision 1.58 diff -u -r1.58 php_odbc.h --- ext/odbc/php_odbc.h 8 Jan 2004 17:32:34 - 1.58 +++ ext/odbc/php_odbc.h 11 Apr 2005 17:47:11 - @@ -33,8 +33,8 @@ extern zend_module_entry odbc_module_entry; #define odbc_module_ptr &odbc_module_entry -#if defined(HAVE_DBMAKER) || defined(PHP_WIN32) || defined(HAVE_IBMDB2) || defined(HAVE_UNIXODBC) -# define PHP_ODBC_HAVE_FETCH_HASH 1 +#if defined(HAVE_DBMAKER) || defined(PHP_WIN32) || defined(HAVE_IBMDB2) || defined(HAVE_UNIXODBC) || defined(HAVE_BIRDSTEP) +#define PHP_ODBC_HAVE_FETCH_HASH 1 #endif /* user functions */ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow .cc files for shared extensions
Why don't you name the files .cpp like you're supposed to? --Jani On Tue, 19 Apr 2005, Brian J. France wrote: Anybody see a problem with this patch that allows .cc files in shared extensions. If not I will check it into all branches. Thanks, Brian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Allow .cc files for shared extensions
On Tue, 19 Apr 2005, Brian J. France wrote: I do, but some of our developers have some wacky idea they should be named .cc. But with PHP they're named .cpp ;) I can keep a internal patch if you rather not, figure I would ask just to make sure. Just add it. But do it with the simple way: Add to the existing .cpp line: *.cpp|*.cc[)] ... --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH for EXEEXT to configure scripts
I committed a patch which works for any system with EXEEXT set. --Jani On Mon, 18 Apr 2005, Kamesh Jayachandran wrote: Hi Jani, Can you apply this patch for changing the extension of final cli binary? For 5.0 http://www.ductape.net/~kameshj/configure.in.5.0.patch http://www.ductape.net/~kameshj/sapicliconfig.m4.5.0.patch For 5.1 http://www.ductape.net/~kameshj/configure.in.5.1.patch http://www.ductape.net/~kameshj/sapicliconfig.m4.5.1.patch This patch is for netware but it can be for any non-darwin system, provided that windows build calls ./configure with EXEEXT=exe. With regards Kamesh Jayachandran -- 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: [PHP-CVS] cvs: php-src /main php_variables.c
This patch was supposed to make it RFC compliant. Can you please point me the part in the RFC 2965 which now isn't implemented correctly? As now it handles these strings it gets the same: name="whatever,this,might,be";name2="value2" name="whatever,this,might,be",name2="value2" How can this affect modsecurity at all --Jani On Sun, 24 Apr 2005, Stefan Esser wrote: Jani Taskinen wrote: sniper Sat Apr 23 16:33:35 2005 EDT Modified files: /php-src/mainphp_variables.c Log: - Fixed bug #32111 (Cookies can also be separated by colon) Could you please revert that patch, or implement the RFC correctly? Now PHP handles cookies in a completely RFC uncovered way. Either we have support for , ; " or only for ; but not something in between. F.e. with your patch you just fucked modsecurity again which will fail to correctly detect evil cookie variables. No matter if you configure it to use V0 or V1 of its detection. Stefan -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /main php_variables.c
On Sun, 24 Apr 2005, Stefan Esser wrote: As now it handles these strings it gets the same: name="whatever,this,might,be";name2="value2" name="whatever,this,might,be",name2="value2" These were actually invalid examples. 'name' can NOT contain any of these chars: =,; \t\r\n\013\014 'value' can NOT contain any of these chars: ,; \t\r\n\013\014 If you want such chars in them, you have to encode them. How can this affect modsecurity at all Forgive me my ignorance, but I do not see any handling of " chars. And there wasn't such before I added the , as acceptable separator. your strings should now result in 5 variables 1. variable: name - content: "whatever 2. variable: this - empty 3. variable: might - empty 4. variable: be" - empty 5. variable: name2 - content: "value" Yes, and with this the same would happen: name="whatever;this;might;be";name2="value2" If I could set a cookie with such value, that is. Off course this is wrong :) Yes it is, if it was allowed. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php-src /main php_variables.c
On Sun, 24 Apr 2005, Stefan Esser wrote: Forgive me my ignorance, but I do not see any handling of " chars. And there wasn't such before I added the , as acceptable separator. ^^ I hate when I have to repeat myself, so read the above line again.. Yes because PHP spoke cookie version 0 before your patch. Now it speaks neither version 0 nor version 1 but your own version. ..and again..the only change I did was adding , (comma) as the 2nd possible separator that might be used by the 2 other cookie specs there are for cookies: Netscape spec uses only ; but RFCs 2109 and 2965 may use , or ; And please tell me how could I "break" anything that was "broken" already? As you can of course send this header to ANY PHP version: GET / http/1.0 Cookie: foobar="foo;bar" And guess what?! It "works"! So do not try to accuse ME for breaking anything that was already broken!!! --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Patch to build shared extensions for Netware
Patch applied. --Jani On Fri, 22 Apr 2005, Kamesh Jayachandran wrote: Hi Jani, Please apply this patch which enables to build NetWare PHP extensions using gcc cross compiler. For 5.0 http://puggy.symonds.net/~kameshj/acinclude.m4.patch.5.0 For 5.1 http://puggy.symonds.net/~kameshj/acinclude.m4.patch.5.1 With regards Kamesh Jayachandran -- 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: #28074 [Opn->Asn]: Fast CGI standard compliance : stderr should be written in a FCGI stderr stream (fwd)
I addded fastcgi.logging ini option. Set that to 0 and you'll
get the original behaviour back.
--Jani
On Thu, 28 Apr 2005, Sascha Schumann wrote:
I'm more of the mindset that whoever breaks it, also fixes
it.
My current 'fix' would simply revert that patch. If you
agree with that, I will happily follow through.
- Sascha
-- Forwarded message --
Date: Thu, 28 Apr 2005 12:58:05 +0200
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: #28074 [Opn->Asn]: Fast CGI standard compliance : stderr should be
written in a FCGI stderr stream
[EMAIL PROTECTED] you have just been assigned to this bug by [EMAIL PROTECTED]
ID: 28074
Updated by: [EMAIL PROTECTED]
Reported By: bogus_idp at yahoo dot fr
-Status: Open
+Status: Assigned
Bug Type: CGI related
Operating System: *
PHP Version: 4CVS, 5CVS (2005-01-10)
-Assigned To:
+Assigned To: sas
New Comment:
Feel free to fix it then.
Previous Comments:
[2005-04-21 11:43:51] [EMAIL PROTECTED]
This is an ugly change for users who redirect PHP's stderr to a log
file due to file permissions (PHP is not allowed to open the log
file).
Instead of writing to the log file, the Apache log now contains tons of
rows like this:
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server "/home/www/PHP/php/bin/php" stderr: array (
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server "/home/www/PHP/php/bin/php" stderr: 'rcs' =>
[Thu Apr 21 11:18:27 2005] [error] [client 129.0.10.119] FastCGI:
server "/home/www/PHP/php/bin/php" stderr: array (
etc.
This needs to be addressed -- make logging to fastcgi's stderr
optional.
[2005-01-10 16:01:29] chris at ex-parrot dot com
This one turns out to be easy to fix, thus:
--- cgi_main.c.orig Mon Jan 10 14:57:04 2005
+++ cgi_main.c Mon Jan 10 14:53:44 2005
@@ -481,7 +481,14 @@
static void sapi_cgi_log_message(char *message)
{
- fprintf(stderr, "%s\n", message);
+#if PHP_FASTCGI
+if (!FCGX_IsCGI()) {
+FCGX_Request *request = (FCGX_Request *)SG(server_context);
+FCGX_FPrintF( request->err, "%s\n", message );
+/* ignore return code */
+} else
+#endif /* PHP_FASTCGI */
+ fprintf(stderr, "%s\n", message);
}
static int sapi_cgi_deactivate(TSRMLS_D)
However, there is another similar bug, which is that a stream opened on
"php://stderr" should also direct its output to the FCGI error stream
(rather than just to file descriptor #2).
-- Chris Lightfoot
[2004-04-20 12:03:30] bogus_idp at yahoo dot fr
Description:
The Fast CGI standard require that error be reported through the
FastCGI connection as a Stderr data stream.
But PHP Fast CGI processes still write errors to original stderr (file
handle 3) which prevent from clean standard centralized FCGI logging,
especially when the Fast CGI PHP process is not started by the web
server (remote Fast CGI).
In most cases, it makes debugging PHP scripts impossible.
--
Donate @ http://pecl.php.net/wishlist.php/sniper
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] rfc2965 version 1 cookie support
On Thu, 28 Apr 2005, Rasmus Lerdorf wrote: Stefan Esser wrote: Hi, any objections against fixing our cookie system to also read version 1 cookies correctly? I want to apply the following patch to all 3 branches: http://www.suspekt.org/patches/php_variables.c.diff What is the status of this? I have been offline for a while and am trying to catch up. My view is that we shouldn't be messing with cookie parsing in the 4.3 tree at all, but having full version 1 support in PHP5, or I guess PHP5.1 at this point is a good idea. IMO, only to HEAD. So I would like to see Jani's patch to 4.3 reverted and this committed to HEAD. You didn't catch up enough, I reverted it already. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php-5.0.-dev build failure
On Thu, 28 Apr 2005, Kamesh Jayachandran wrote: Hi Dmitry, I just did cvs upd in my php-5.0-dev workarea which brought your changes in ext/standard/basic_functions.c version 1.673.2.16. After that I get a compile error saying that /root/kamesh/work/php5_0/php-src/ext/standard/basic_functions.c:1911: `IS_CALLABLE_CHECK_NO_ACCESS' undeclared (first use in this function) I could not see this IS_CALLABLE_CHECK_NO_ACCESS getting defined anywhere. It is defined in Zend/zend_API.h. Try 'make clean && make' ? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH to check for availablity of getlogin and getgroups to posix extension
Patches applied to all branches. Just in case. :) --Jani On Thu, 5 May 2005, Kamesh Jayachandran wrote: Hi Jani, Netware LibC does not have getgroups implemented, it has getlogin functionality in recent LibC. As ext/posix/posix.c does not have #ifdef HAVE_GETLOGIN and #ifdef HAVE_GETGROUPS check before making use of getlogin and getgroups functionality, NetWare cross compile fails. I do ./configure --disable-posix to get through with the comilation. I am interested in having this extension as a part of our php5, I have a patch to check for the existence of getlogin and getgroups method. Please apply the same. http://puggy.symonds.net/~kameshj/posix.c.patch.5.0 http://puggy.symonds.net/~kameshj/posixconfig.m4.patch.5.0 With regards Kamesh Jayachandran -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] install ext/gd headers
I added PHP_INSTALL_HEADERS() macro in HEAD. And used it with gd so now those headers are installed. Feel free to backport the patch(es). --Jani On Mon, 14 Feb 2005, Joe Orton wrote: On Thu, Feb 10, 2005 at 03:21:45PM +0200, Jani Taskinen wrote: While this patch works fine, what if you don't actually have GD installed in your PHP? There should be a configure macro that adds the headers when really needed.. Good point. OK, how about this instead: Index: scripts/Makefile.frag === RCS file: /repository/php-src/scripts/Makefile.frag,v retrieving revision 1.14 diff -u -r1.14 Makefile.frag --- scripts/Makefile.frag 20 Jan 2005 01:41:20 - 1.14 +++ scripts/Makefile.frag 14 Feb 2005 10:15:31 - @@ -38,6 +38,7 @@ main/ \ main/streams/ \ regex/ \ + $(GD_HEADER_DIRS) \ ext/iconv/ \ ext/libxml/ \ ext/standard/ \ Index: ext/gd/config.m4 === RCS file: /repository/php-src/ext/gd/config.m4,v retrieving revision 1.151 diff -u -r1.151 config.m4 --- ext/gd/config.m44 Jan 2005 06:51:44 - 1.151 +++ ext/gd/config.m414 Feb 2005 10:15:31 - @@ -410,7 +410,9 @@ if test "$GD_MODULE_TYPE" = "builtin"; then GDLIB_CFLAGS="-I$ext_srcdir/libgd $GDLIB_CFLAGS" PHP_ADD_BUILD_DIR($ext_builddir/libgd) +GD_HEADER_DIRS="ext/gd/ ext/gd/libgd/" else +GD_HEADER_DIRS="ext/gd/" GDLIB_CFLAGS="-I$GD_INCLUDE $GDLIB_CFLAGS" PHP_ADD_INCLUDE($GD_INCLUDE) @@ -421,4 +423,5 @@ PHP_SUBST(GDLIB_CFLAGS) PHP_SUBST(GD_SHARED_LIBADD) + PHP_SUBST(GD_HEADER_DIRS) fi -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unserialize Bug
Is it documented anywhere what the allowed chars are..?
(I couldn't find it anywhere but sources :)
--Jani
On Tue, 17 May 2005, Timm Friebe wrote:
Hi,
unserialize() cannot unserialize objects whose names contain anything except
a-z, 0-9 and _, the parser allows those, though.
Example
===
$ cat unserialize.php
var_dump(unserialize(serialize(new Über(;
?>
Expected behaviour
==
$ php unserialize.php
object(über)(0) {
}
Actual behaviour
$ php unserialize.php
bool(false)
PHP Notice: unserialize(): Error at offset 5 of 15 bytes in
F:\Programme\cygwin\home\thekid\unserialize.php on line 4
Cause
=
http://cvs.php.net/diff.php/php-src/ext/standard/var_unserializer.re?sa=1&r1
=1.40&r2=1.41&ty=u
Fix
===
Allow anything the parser allows, [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
- Timm
--
Donate @ http://pecl.php.net/wishlist.php/sniper
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: References Problem Patch
Switching to PHP 5 (.1) here is not an option yet either. (and nobody can guarantee this same bug doesn't exist in it). Regarding the magnitude: It's pretty damn high, if you look at how many bug reports we've got about reference issues and large (huge) codebases. (where finding the short reproducing script is impossible) --Jani On Mon, 30 May 2005, Zeev Suraski wrote: At 17:10 30/05/2005, Derick Rethans wrote: Not fixing it is *not* an option. You fix something that's broken - you don't leave it broken. That's called responsibility. And no, switching to PHP 5 is not an option either. Sorry Derick, but you saying that not fixing it and/or that switching to PHP 5 are not valid options doesn't mean that they're not valid options. I think that with the rarity of this issue and even higher rarity of it actually causing problems, taking this approach is extremely valid. Breaking binary compatibility inside a 'PHP version family' on the other hand is not an option, we've decided not to do this 3 or 4 years ago, and I don't see any reason to break this decision at all. I for one think that (a) providing info and workarounds, and (b) pointing people to use PHP 5 is a completely acceptable solution to a problem of this magnitude, when compared to the cost of fixing it. Let's see what others think. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: References Problem Patch
On Mon, 30 May 2005, Zeev Suraski wrote: arguments. But it isn't. It's a bug that is pretty uncommon and can be worked around in userspace. Yes, it's annoying if you bump into it, but in the scale of severity, I don't think it rates very high. It rates pretty high on my list when I have to dig into (somebody else's) code trying to find which one of the dozens of "&"'s is causing the random segfaults, etc. anomalities. And eventually decide that the best way to get it to work is either rewrite all of it or simply remove every single "&" from the files and try and fix what might break.. So no, by no means: Don't fix it! I can justify some more time being spent on that and send a bigger invoice. =) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PTS support patch
Sascha pretty well explained why adding such automagic is not possible. But maybe if there is some small test prog to try with AC_TRY_RUN(), I can always add that. (but I lack the knowledge on how to write such prog..) --Jani On Sun, 29 May 2005, Wez Furlong wrote: None from me. Would be cool if we could automagically detect support during configure time, but due to the lack of any kind of positive feedback to my last efforts, I won't be the person doing it. --Wez. On 5/29/05, Michael Spector <[EMAIL PROTECTED]> wrote: On 12:51, Wed 25 May 05, Michael Spector wrote: Here's a patch for PTS support in proc_open, instead of having PHP_CAN_DO_PTS always disabled this patch introduces --enable-pty option. Added support for BSD4 PTS types. Please review it. Anybody has any objections to including this patch? -- Best regards, Michael -- 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] SID was accidently changed to CONST_CS?
Regarding this bug: http://bugs.php.net/bug.php?id=29322&edit=1
And by looking at this commit by Andi:
http://cvs.php.net/diff.php/php-src/ext/session/session.c?r1=1.391&r2=1.392&ty=u
and this part of it:
- REGISTER_STRINGL_CONSTANT("SID", empty_string, 0, 0);
+ REGISTER_STRINGL_CONSTANT("SID", "", 0, 1);
Where flags changed from 0 to 1..
Intentional or not?
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Sun, 5 Jun 2005, Magnus Määttä wrote: Hi Andi, On Saturday 04 June 2005 07.58, Andi Gutmans wrote: I'd like to roll a beta of it towards the end of next week such as Thursday (giving a chance for some last minute fixes), and then hopefully RC within a week or two. Once we RC PHP 5.1, we should branch it off to PHP_5_1 and make HEAD the Unicode development stream (merging Unicode changes into HEAD). What about ifsetor for 5.1 ? +1000 And the much needed goto for the next one (5.2/5.5/6.0 or whatever it will be) ? I've found a lot of cases where this would have been nice to have and simplified the code too.. So +1 from me. (wasn't there a patch for this already somewhere?) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 4.4 branch
Fixed in CVS now. (please test, I have no solaris machine to test with :) --Jani On Wed, 8 Jun 2005, Uwe Schindler wrote: At 19:38 07.06.2005, Derick Rethans wrote: On Mon, 6 Jun 2005, Derick Rethans wrote: > If you have any issues that you really want to get fixed in PHP 4.4, > please reply to this email (on the internals@ list). If there is nothing, I'd like to start releasing RC1 on Monday. regards, Derick Only one thing: after you reverted my patch (because of my error with the man pages - i'm sorry) the installation of manpages in 4.4 does not work because the variable $(man_PAGES) is not defined in Makefile.frag (it never worked). I also removed the $(bin_src_SCRIPTS) part like in 5.0 and HEAD because the solaris /bin/sh does not like empty lists in for-loops. If there is no problem this time I will apply this patch. - 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] Improving (?) PHP extension loading mechanism (was: Re: [PHP-CVS] cvs: php-src /ext/pdo pdo.c) (fwd)
The patch in question can be found here: http://www.php.net/~jani/patches/exts_loading_poc.patch It is merely a quick proof-of-concept: a) Separates PHP extension registering and startup routines b) Adds an extra 'depends' entry to the module struct c) Nukes the problematic AWK script (just for debugging so that I got 'wrong' order :) If an extension has no dependancies, it will be registered and started in same loop. If it has dependancies, it is registered but the startup routines are not run. When all extensions are loaded and registered, the startup routines are run for all the extensions (if one is already started it's just skipped). That patch needs a bit tuning up before it can be applied, given the concept is approved, of course. :) Needs to be done: - All extensions requiring something from other extensions need to be updated to have the deps in their module entry - php_startup_extensions() needs to be more intelligent and loop through until all dependancies are met and not just blindly try starting up anything before extensios it depends on are started - Make it quicker. I haven't done any benchmarks but it's pretty obvious this does make the PHP startup slower.. --Jani On Fri, 10 Jun 2005, Wez Furlong wrote: Yeah, that's what I'm thinking--would you mind posting that to internals for consideration for 5.1? I think it would be a strong addition. --Wez. On 6/10/05, Jani Taskinen <[EMAIL PROTECTED]> wrote: That patch of mine to the extension loading mechanism should fix this? Just add a dependancy of spl to pdo..and fix the 'delayed' startup routine. :) --Jani On Fri, 10 Jun 2005, Marcus Boerger wrote: Hello Wez, we could check if spl is initialized and if not forcefully initialize it in pdo's MINIT. marcus Friday, June 10, 2005, 8:11:30 AM, you wrote: wez Fri Jun 10 02:11:30 2005 EDT Modified files: /php-src/ext/pdopdo.c Log: "Fix" PECL #4411 SPL is not initialized before PDO, so inheriting from SPL's runtime exception class gives PDO a broken exception class. We don't currently have a way to express this kind of "soft" dependency in the build system, so I'm disabling inheriting from the runtime exception for now. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Sat, 11 Jun 2005, Derick Rethans wrote: On Sat, 11 Jun 2005, Andi Gutmans wrote: Hi Wez and all, I built Beta 2 with the latest CVS which appears to have Wez's fixes. Please check it out and let me know if it resolves the critical problem and can be posted. Very nice Andi. I asked yesterday for one or two days, then you put out beta1 one followed by beta 2 a day later. That does not make a single bit of sense. besides that, the NEWS file is still broken, it misses the changes from 5.0.4 to 5.0.5-dev. Instead of adding to this nagging I went and added those entries myself. Now get your finger out of your ass, stop whining and actually commit the ext/date stuff! --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] HEAD does not compile with GCC 4.0.1
See also http://bugs.php.net/bug.php?id=33212&edit=1 --Jani On Mon, 13 Jun 2005, Dmitry Stogov wrote: Hi, Is GCC 4.0.1 already released? Did you try GCC 4.0.0? Something was changed in GCC. The error message is proper, but I don't understand why this became a error. Probably I'll need to take advice from somebody of GCC developers. Thanks. Dmitry. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann Sent: Monday, June 13, 2005 10:39 AM To: internals@lists.php.net Subject: [PHP-DEV] HEAD does not compile with GCC 4.0.1 /usr/local/src/php/php-5.1/Zend/zend_execute.c:47: error: 'zend_error_noreturn' aliased to external symbol 'zend_error' -- 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 -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zend standalone build broken
Fixed. --Jani On Tue, 14 Jun 2005, Stanislav Malyshev wrote: As of now, Zend engine standalone build is broken in CVS, in two places: 1. SED variable is used though not defined 2. PHP_ARG_WITH is used, though not defined -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Adding the generated files for GOTO/SWITCH VM to CVS
Here's a patch to get the multiple versions: (totally untested!) http://www.php.net/~jani/patches/zend_multi_vm.patch I didn't want to change the generator that much, so if you want to generate all, just run it 3 times. Perhaps this could be a buildconf thing? --Jani On Fri, 17 Jun 2005, Sebastian Bergmann wrote: It would be great (from a usability point) to add the generated files for all three (CALL, GOTO, SWITCH) VM models to CVS as zend_vm_opcodes_call.h zend_vm_execute_call.h zend_vm_opcodes_goto.h zend_vm_execute_goto.h zend_vm_opcodes_switch.h zend_vm_execute_switch.h and have the --with-zend-vm configure parameter choose the right pair. This way it will be possible to build GOTO and SWITCH without a working PHP interpreter available. It would also be consistent with the "have all generated files in CVS" rule. To make things easier with this new setup the zend_vm_gen.php script should be changed that it creates the above listed files by default. -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Adding the generated files for GOTO/SWITCH VM to CVS
They have to be in CVS, otherwise there is the small but annoying chicken'n'egg problem..you might not have PHP installed to begin with. :) --Jani On Fri, 17 Jun 2005, Dmitry Stogov wrote: Hi Sebastian, I don't like generated files in CVS at all. Having several copies can be a reason of lot of mistakes. Right now you are able to make call-threaded PHP, then regenerate executor and build another one. I think it is possible to automat this process with PHP building system. Old version of specialiser was implemented in C preprocessor and didn't require generation at all. But final executor was hard for debug. Thanks. Dmitry. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann Sent: Friday, June 17, 2005 2:06 PM To: internals@lists.php.net Subject: [PHP-DEV] Adding the generated files for GOTO/SWITCH VM to CVS It would be great (from a usability point) to add the generated files for all three (CALL, GOTO, SWITCH) VM models to CVS as zend_vm_opcodes_call.h zend_vm_execute_call.h zend_vm_opcodes_goto.h zend_vm_execute_goto.h zend_vm_opcodes_switch.h zend_vm_execute_switch.h and have the --with-zend-vm configure parameter choose the right pair. This way it will be possible to build GOTO and SWITCH without a working PHP interpreter available. It would also be consistent with the "have all generated files in CVS" rule. To make things easier with this new setup the zend_vm_gen.php script should be changed that it creates the above listed files by default. -- 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 -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Adding the generated files for GOTO/SWITCH VM to CVS
Ok, I'll redo the patch. hangon.. :) --Jani On Fri, 17 Jun 2005, Dmitry Stogov wrote: Hi Jani, You shouldn't patch zend_vm_gen.php. The option --without-old-executor is reverted to --with-old-executor. So people will be able to generate old executor too. Other part probably should work, but as I said, I don't like generated files in CVS (however we can generate them for release). Thanks. Dmitry. -Original Message----- From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Friday, June 17, 2005 2:17 PM To: Sebastian Bergmann Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Adding the generated files for GOTO/SWITCH VM to CVS Here's a patch to get the multiple versions: (totally untested!) http://www.php.net/~jani/patches/zend_multi_vm.patch I didn't want to change the generator that much, so if you want to generate all, just run it 3 times. Perhaps this could be a buildconf thing? --Jani On Fri, 17 Jun 2005, Sebastian Bergmann wrote: It would be great (from a usability point) to add the generated files for all three (CALL, GOTO, SWITCH) VM models to CVS as zend_vm_opcodes_call.h zend_vm_execute_call.h zend_vm_opcodes_goto.h zend_vm_execute_goto.h zend_vm_opcodes_switch.h zend_vm_execute_switch.h and have the --with-zend-vm configure parameter choose the right pair. This way it will be possible to build GOTO and SWITCH without a working PHP interpreter available. It would also be consistent with the "have all generated files in CVS" rule. To make things easier with this new setup the zend_vm_gen.php script should be changed that it creates the above listed files by default. -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Adding the generated files for GOTO/SWITCH VM to CVS
New version now @ http://www.php.net/~jani/patches/zend_multi_vm.patch --Jani On Fri, 17 Jun 2005, Jani Taskinen wrote: Ok, I'll redo the patch. hangon.. :) --Jani On Fri, 17 Jun 2005, Dmitry Stogov wrote: Hi Jani, You shouldn't patch zend_vm_gen.php. The option --without-old-executor is reverted to --with-old-executor. So people will be able to generate old executor too. Other part probably should work, but as I said, I don't like generated files in CVS (however we can generate them for release). Thanks. Dmitry. -Original Message----- From: Jani Taskinen [mailto:[EMAIL PROTECTED] Sent: Friday, June 17, 2005 2:17 PM To: Sebastian Bergmann Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Adding the generated files for GOTO/SWITCH VM to CVS Here's a patch to get the multiple versions: (totally untested!) http://www.php.net/~jani/patches/zend_multi_vm.patch I didn't want to change the generator that much, so if you want to generate all, just run it 3 times. Perhaps this could be a buildconf thing? --Jani On Fri, 17 Jun 2005, Sebastian Bergmann wrote: It would be great (from a usability point) to add the generated files for all three (CALL, GOTO, SWITCH) VM models to CVS as zend_vm_opcodes_call.h zend_vm_execute_call.h zend_vm_opcodes_goto.h zend_vm_execute_goto.h zend_vm_opcodes_switch.h zend_vm_execute_switch.h and have the --with-zend-vm configure parameter choose the right pair. This way it will be possible to build GOTO and SWITCH without a working PHP interpreter available. It would also be consistent with the "have all generated files in CVS" rule. To make things easier with this new setup the zend_vm_gen.php script should be changed that it creates the above listed files by default. -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] In regards to E_STRICT and PHP5
Perhaps you should have noticed that the errors in php.ini-recommended are logged so whatever the error level is shouldn't matter. And I don't think this file is read-only everywhere? :) --Jani On Sat, 18 Jun 2005, Andi Gutmans wrote: Thanks for spotting that. Not sure how it got in there. I removed E_STRICT from the default error_reporting in php.ini-recommended. At 01:24 PM 6/18/2005 +0100, Nicholas Telford wrote: Hello everyone, It seems that E_STRICT is on by default in php.ini-recommended as of 5.1 I think the real issue here is nothing to do with E_STRICT being too strict, it does what it says, and as Andi has already said, it's there as a means of best practice checking for pedantic developers. The problem is that far too many people look at the distribution, see "php.ini-recommended" and think that they should be using it, this isn't to say that they shouldn't, but they should at least be aware that -recommended means that everything is set up to be as tight as possible. I propose changing php.ini-recommended's error reporting level to simply E_ALL. Those developers who require E_STRICT know how to turn it on and will do so. I agree with Sara that E_STRICT could probably do with expanding, having it simply checking for depreceated stuff is all well and good, but it's name implies that it will alert the developer to anything not considered strictly correct coding practice. Since this thread spawned off the one about adding public to PHP4.4, it's probably not worth it, not due to backwards compatability (try running code written for 4.3.x under 4.0.0...), but mostly because it'd effectively be creating an intermediary branch between PHP 4 and PHP 5 that would be neither one nor the other. It's probably just best to allow people to make the move to PHP 5 over a longer period of time. Besides, as Andrey said, you can just insert the keywords and have them commented out until the entire app is ported. Sorry for the rather lengthy post, I've been watching these discussions with great interest over the last few days and have only now had the chance to post my thoughts. Nicholas Telford -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] In regards to E_STRICT and PHP5
An ini file we might provide does not set the defaults. Try running stuff without any php.ini file.. The error_reporting in a recommended (PHP 5.1!!!) ini file should be at the "pedantic" level.. --Jani On Sat, 18 Jun 2005, Daniel Convissor wrote: Hi Zeev: On Sat, Jun 18, 2005 at 12:59:31PM +0300, Zeev Suraski wrote: Where do you see that? As far as I can tell it certainly looks off by default even in 5.1. http://cvs.php.net/php-src/php.ini-recommended#rev1.173 That change is still in there as version 1.176, which was used for the latest 5.1 betas. --Dan -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 Beta 2
Fixed in CVS. --Jani On Tue, 21 Jun 2005, Nuno Lopes wrote: I still have a problem in the configure script. With the package you post: checking for embedded SAPI library support... no ./configure: syntax error at line 9265: `;' unexpected checking that line, there is a problem indeed: header_path=sapi/embed/php_embed.h for header_file in ; do hp_hf="$header_path/$header_file" With latest cvs and with my autoconf/automake tools: checking for embedded SAPI library support... no ./configure: line 10030: syntax error near unexpected token `;' ./configure: line 10030: `for header_file in ; do' This is on a Solaris 9 box. Nuno - Original Message - Hi, You can reach Beta 2 at http://snaps.php.net/~andi/ If there are no surprise show stoppers I'll put it live tomorrow evening. Andi -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] httpOnly Cookies [tiny enhancement]
Provide the patch against CVS HEAD branch. (either get the sources via CVS or as snapshot from http://snaps.php.net) --Jani On Thu, 23 Jun 2005, Jochen Hansper wrote: Hello Marcus, patches for official php-4.3.11 release in attachment... (diff -Naur) Jochen [php_session.h.patch; session.c.patch] Am Donnerstag, den 23.06.2005, 02:15 +0200 schrieb Marcus Boerger: Hello Jochen, please resend your patch as unified patch (cvs di -u). marcus Thursday, June 23, 2005, 2:03:24 AM, you wrote: -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug DB
On Thu, 23 Jun 2005, Derick Rethans wrote: On Thu, 23 Jun 2005, Andi Gutmans wrote: I can do that if we agree on doing it. You do know that most of the ones in the "scripting engine" one are ZE1 bugs? It seems the majority were also verified with PHP 5, no? I'm not sure, but would it help to move the ZE2 bugs to the "Scripting Engine" category instead? I think that's more logical. UPDATE bugdb SET bug_type='Scripting Engine problem' WHERE bug_type='Zend Engine 2 problem'; --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: allow_url_fopen should be INI_ALL
On Mon, 27 Jun 2005, Yasuo Ohgaki wrote: Derick Rethans wrote: On Sun, 26 Jun 2005, Sara Golemon wrote: Yes, unregister/restore is PHP5 only. I'd personally be okay with merging this to 4.4 as the bulk of the support for it is already there internally, it's just adding a couple PHP_FUNCTION hooks to make it happen. That's up to the RM and general consensus though. 4.3/4.4 is a bugfix only branch, so no new features... Derick Looks like I missed some messages, what about the original request? - allow_url_fopen back to INI_ALL. That would be same as keeping it the way it is, ie. on-by-default. Allowing anybody simply change it in their script is not acceptable. - allow_url_fopen = Off by default. That's very good idea. But only if it's kept INI_SYSTEM. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Win32 php4ts.dll 875k Larger in 5.1?
1.6MB timezonedb.h in ext/date/lib/ would be a good guess. :) --Jani On Mon, 27 Jun 2005, Michael Sisolak wrote: The default build of php4ts.dll has grown from 3,421k in 5.0.4 to 4,297k in 5.1.0b2 (an increase of over 25%). Does anyone know what the change was that had such a dramatic effect on the size of the DLL? Michael Sisolak [EMAIL PROTECTED] Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] allow_url_fopen should be INI_ALL
Please troll, do you go away if I close my eyes? --Jani On Wed, 29 Jun 2005, Russell Nelson wrote: Rasmus Lerdorf writes: > Russell Nelson wrote: > > When the top Google result for 'php security flaw' returns > > mysql_query() instead of include(), I will agree that you are correct. > > I am not sure a Google search is a very good barometer here. > ... today it really doesn't seem like it is even in the top 10 PHP > security problems. Essentially, you're saying that Google doesn't do a good job at finding pages people would be interested in reading. That's a strong claim to make. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 Release Candidate 1
These should be definately fixed:
http://bugs.php.net/bug.php?id=33772&edit=1 (destruct thing)
http://bugs.php.net/bug.php?id=33723&edit=1 (apache + php_admin_value issue)
These would be nice to get fixed:
http://bugs.php.net/bug.php?id=31177&edit=1 (memory leak)
http://bugs.php.net/bug.php?id=33598&edit=1 (throw from __destruct -> fatal
error)
http://bugs.php.net/bug.php?id=30453&edit=1 (a) some engine bug)
http://bugs.php.net/bug.php?id=30452&edit=1 (b) some engine bug)
http://bugs.php.net/bug.php?id=31341&edit=1 (inconsistency with { escaping)
http://bugs.php.net/bug.php?id=25359&edit=1 (array_multisort +
global/reference)
Some of those I've got bitten by myself too.. :)
--Jani
On Tue, 26 Jul 2005, Andi Gutmans wrote:
Hi all,
As planned (a tiny bit delayed), I'd like to RC1 PHP 5.1 within the next few
days. I suggest to aim for Tuesday in a week.
If there are any critical issues which need addressing please email me.
As previously mentioned, I'd like to branch of PHP_5_1 after RC1 in order to
allow for the Unicode merge to take place. We'll need about a week of HEAD
silence in the core components (Dmitry and Andrei will indicate which ones) so
that we can do the merge.
Thanks,
Andi
--
Donate @ http://pecl.php.net/wishlist.php/sniper
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] moving extensions to pecl
On Thu, 4 Aug 2005, Marc Boeren wrote: Hiyall and Wez in particular, In general, unless the extension is a really ancient forgotten thing, the person moving it should coordinate with the current maintainer to set that up. That would have been nice :-) Please note this: This was only removed from PHP 5.1-dev (HEAD), it still exists in the PHP_4_4 branch.. And AFAIK, there are no releases of PHP 5.1 (other than betas) out yet? :) Plus it does have a package.xml. Added in 2004/03/24.. --Jani p.s. I thought Derick handled the CVS stuff..also the access. :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem updating CVS HEAD
On Thu, 4 Aug 2005, Pasha Zubkov wrote: Hi list, If after `... checkout php-src` I go to directory php-src and remove ZendEngine2 directory, then run `... up -APd` don't restore this directory from repo. How I can update my copy to repo status? Do NOT remove the directory. buildconf handles this. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem updating CVS HEAD
On Fri, 5 Aug 2005, Pasha Zubkov wrote: Andrey Hristov wrote: Because CVS works and ppl are so far happy with it Andrey CVS don't always work properly. This example shows it ;) Also SVN has It works fine as long as you don't try to outsmart it. better versioning control mechanism. Hope sometime in the future php SVN is far from better. will "update" to SVN, so why not now? Over my smoking carcass.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Any reasons for not making exif and sockets extensions dynamically loadable.
On Fri, 5 Aug 2005, Kamesh Jayachandran wrote: Hi All, I could not build exif and sockets extension as a shared extension(Our php set up is like windows PHPTS). With the current config.m4 I get link failure stating that php5lib not found. PHP_SUBST(SOCKETS_SHARED_LIBADD) PHP_SUBST(EXIF_SHARED_LIBADD) in the corresponging config.m4 files would do the needful. Neither of the extensions in questions use any external libraries so those lines are unnecessary. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Any reasons for not making exif and sockets extensions dynamically loadable.
Stupid system it is. :) You should handle this differenly but I don't care. Just add those lines if you can't come up with some better solution. --Jani On Sat, 6 Aug 2005, Kamesh Jayachandran wrote: Hi Jani, In NetWare all extensions/sapis need the php5lib(Core php shared library) which won't be available for these binaries to be linked without the following lines(in PHP_SHARED_MODULE of acinclude.m4 we set MODULE_SHARED_LIBADD), PHP_SUBST(SOCKETS_SHARED_LIBADD) PHP_SUBST(EXIF_SHARED_LIBADD) Can i checkin this? With regards Kamesh Jayachandran On Fri, 5 Aug 2005 23:58:39 +0300 (EEST), "Jani Taskinen" <[EMAIL PROTECTED]> said: On Fri, 5 Aug 2005, Kamesh Jayachandran wrote: Hi All, I could not build exif and sockets extension as a shared extension(Our php set up is like windows PHPTS). With the current config.m4 I get link failure stating that php5lib not found. PHP_SUBST(SOCKETS_SHARED_LIBADD) PHP_SUBST(EXIF_SHARED_LIBADD) in the corresponging config.m4 files would do the needful. Neither of the extensions in questions use any external libraries so those lines are unnecessary. --Jani -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 8 Aug 2005, Derick Rethans wrote: On Mon, 8 Aug 2005, Sebastian Bergmann wrote: Derick Rethans schrieb: Throwing two different kinds of Exceptions is evil. Just as evil as allowing SPL to be disabled. Not really. SPL is only for people that actually want to use Java. Enabling it by default is same as enabling unnecessary bloat by default. So no thanks for making it not possible to disable.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 8 Aug 2005, Marcus Boerger wrote: without SPL. At the end of the day i'd even like to drop reflection support from the engine and move it to a specialized extensions - again - for speed/memory reasons. YES PLEASE! I've absolutely no use for it, and I really really need every bit of memory/speed/whatever I can get out of PHP.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
On Mon, 8 Aug 2005, Ondrej IvaniÄ wrote: Jani Taskinen wrote: without SPL. At the end of the day i'd even like to drop reflection support from the engine and move it to a specialized extensions - again - for speed/memory reasons. YES PLEASE! I've absolutely no use for it, and I really really need every bit of memory/speed/whatever I can get out of PHP.. Wow! Is PHP the right tool for you? I think I know what is right or not for me. =) If you don't use 00 things you can stay on PHP 4.x with ZE1. What you need/don't from PHP? Ehehehehhehheheheee... --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.5 or 6.0
On Tue, 9 Aug 2005, Derick Rethans wrote: Now that we branched it's time to rename HEAD to something else than 5.1 in order to have different version numbers. Although the name PHP 5.5 was mentioned before, I do think we should call it PHP 6.0. As the Unicode support is quite a drastic change. Going with PHP 6.0 also allows us to be a little less strict with breaking BC in the cases where that might be useful for the Unicode support. +1 and can we now also drop PHP_5_0 branch? :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Fri, 12 Aug 2005, Rasmus Lerdorf wrote: 1. Remove register_globals completely +1 (then we can cleanup the mess in ext/session too :) 2. Remove magic_quotes_* +1 (definately, finally, at last! The filter stuff obsoletes those anyway?) 3. Add input filter extension which will include a mechanism for application developers to very easily turn it off which would swap the raw GPC arrays back in case the site had it turned on by default. +1 (to be able to do 2. for real, of course) 4. Include an opcode cache by default. A lot of work has gone into pecl/apc recently, but I am not hung up on which one goes in. +100 (it's ridiculous to have to install it separately) 5. Remove safe_mode and focus on open_basedir +1 6. Remove some stuff that has been marked deprecated since PHP 3/4 Something like 'allow_call_time_pass_reference' or whatever it was again? A couple of others that we could consider, but I don't actually think wins us much apart from academic purity (which I have never been all that keen on) are: 7. Make identifiers case-sensitive Such as function names? :) That'd be kinda nice since it not only makes the language more consistent but also tad faster, especially now with the unicode stuff slowing that down even more.. 8. Remove various function aliases I was toying with an idea about a configure switch and/or ini option. But I guess some of those just should go away. The other wild idea I got while thinking about this was to add opposite option for 'disable_functions', 'enable_functions', which would only enable the functions I _really_ use :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 6.0 Wishlist
Very good idea. We do bundle the thing? :) --Jani On Fri, 12 Aug 2005, Ilia Alshanetsky wrote: This is a very good, point we really should drop support for things like gd1 (no reason anymore, latest versions (including bundled) have GIF support). These only add a hundreds of ifdefs to the code or prevent usage of new(er) functionality. IMHO we should see what is the lowest possible version of a lib distributed by commonly used distro and upgrade our requirements to @ least that version. Ilia Pierre-Alain Joye wrote: Hello, +1 to all things, same comment as the opcode cache Ilia's one. I would like to add one from my wishes: Bump version for the required library as high as possible (or realist) and do not support museum softwares at all, like droping freetype v1 for example. Most of the users do not use it anymore, but it will make the whole much more clean and easier to maintain. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 6.0 Wishlist
On Fri, 12 Aug 2005, Pierre-Alain Joye wrote: On Sat, 13 Aug 2005 00:21:29 +0300 (EEST) [EMAIL PROTECTED] (Jani Taskinen) wrote: Very good idea. We do bundle the thing? :) I do not think we can use the extern GD2 in the same nice way than we use ours. But droping _extern_ gd2 support is possible. The only remaining thing is to check that we will be really binary compatible. I don't think dropping the external library linking support is such a good idea. Just nuke GD1 support. (gotta start somewhere :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Fri, 12 Aug 2005, Andrei Zmievski wrote:
We did, but we never arrived at consensus. I don't really see a good reason
for giving people access to code-units with such a low-level operator. If we
fix it, I'd rather fix it so that [] only works on arrays, and {} on strings,
+100
with some sort of BC switch.
-Inf
We're talking about cleaning up legacy stuff, not creating new, aren't we?
:)
And iirc, using [] for strings has been "deprecated" for ages now.
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 6.0 Wishlist
On Sat, 13 Aug 2005, David Zülke wrote: 10. namespace support (we are telling everyone php is ready for the big soup. In those scenarios you often find big teams and any help allowing things like dedicated responisbilities and preventing communication problems is more then welcome.) -1 before, -1 still. Well... if you're so anti-namespaces, I'm sure you will change all my code to use different names when collisions occur, right? Thanks man, saves me loads of trouble then. # perl -p -i -e 's/stupidclassnamewithoutproperprefix/good_classname/g' *.php That wasn't so hard, was it? :) (that's basically only thing I use perl for :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Sat, 13 Aug 2005, Marco Tabini wrote: Or maybe so that you don't have to look at the manual fifteen times a minute so that you can remember whether the needle goes before the haystack in a particular function or not. I'm all for making this consistent all around. Best way to get this done is propably to first come up with a list of functions which are inconsistent? And get a concensus over it. :) This is the first one that comes to my mind: int strpos (string haystack, mixed needle [, int offset]) Whenever I've used that, I've ALWAYS mixed the needle with haystack. Same goes with every str* function, I guess.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Sat, 13 Aug 2005, Lukas Smith wrote: Xuefer wrote: possibly make a internal or loadable "argument reposition table", enabled with: declare(fix_function_argument_position); fix at compile time, no performance lost on runtime. but might confuse the debuger if the origin position in source is forget after compile As I suggested by using runkit (AFAIK it could be extended to be able to intercept calls to internal fuctions .. if it cant do that already) we could provide a BC lib for every BC break we make due to parameter order changing. PEAR::PHP_Compat could be used to fix up all the changed function names or dropped alias. Or do that the other way around: Provide the changed ones in there for forward compatibility and just break it hard on PHP 6. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Sat, 13 Aug 2005, George Schlossnagle wrote: On Aug 13, 2005, at 5:08 AM, Ondrej Ivani wrote: 9. Shared memory storage for variables with transparent access. (superglobal array?) -1. This is hard to make consistent across all platforms, and will break instantly when you go past 1 machine, making it confusing and of marginal usage. Maybe this could be something that ext/session could provide. I sure can find some uses for a 'global session'. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 6.0 Wishlist
On Sat, 13 Aug 2005, Lukas Smith wrote: Ron Korving wrote: 16. Support for that reminds me: set short_open_tags to off in any sample php.ini we ship. Ah yes, that reminds me: 17. Nuke every "alternative" open tag and only have http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Sat, 13 Aug 2005, George Schlossnagle wrote: Maybe this could be something that ext/session could provide. I sure can find some uses for a 'global session'. That seems like a reasonable to go. I question it's utility a bit - how often is this really useful? For large objects (like a real cache), this isn't the best place to store it, for most resources it won't work at all. So what's a typical use case for this? I wasn't even dreaming of using it for storing stuff like objects in it. As a real world example, I'd use something like that for "locking" stuff in the admin interface, e.g. when someone opens an item for editing, it's locked for all other moderators/administrators/etc... Of course I can accomplish that by a separate table in the database, but I'd like to avoid any unnecessary writes to DB whenever possible. :) Anyone have any other solutions to this (I'd guess quite common problem) I'm open for suggestions. :) Some other uses for a "global session" might be forums and their 'show online users' feature. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Need a cache for ucnv_open()
I'd go with zend_unicode.c as you can disable ext/unicode. --Jani On Sat, 13 Aug 2005, Wez Furlong wrote: A number of extensions/functions (strangely, most of the things I work on :-) will need to be able to convert between unicode and arbitrary encodings. It makes a lot of sense to keep some kind of per-request cache (of limited length) to avoid having to load and unload the conversion table on each conversion attempt. Since this cache needs to always be present (to avoid crazy conditional compilation) we either need to put it in zend_unicode.c or put it in ext/unicode and always require it to be statically compiled into php. Thoughts? --Wez. -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Sat, 13 Aug 2005, Sara Golemon wrote: This is the first one that comes to my mind: int strpos (string haystack, mixed needle [, int offset]) And this is why they're inconsistent to begin with. When I look at strpos() I think: strchr(char *, int) So the parameter ordering does make sense there (to me). Yes, coming from a C background you would think like that. But when you think about it with some logic (not women's logic :): "I'm looking for a character inside a string." Thus: strpos(needle, haystack) is the correct way (tm) =) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 6.0 Wishlist
On Sat, 13 Aug 2005, Sara Golemon wrote: set short_open_tags to off in any sample php.ini we ship. Ah yes, that reminds me: 17. Nuke every "alternative" open tag and only have Agreed (though not so much nuke as default to off). Whenever open tags comes up, I'll toss
Re: [PHP-DEV] PHP 6.0 Wishlist
Yeah. It's propably best to leave these alone. :)
--Jani
On Sat, 13 Aug 2005, Wez Furlong wrote:
I really doubt this will change.
It would be a *huge* mess in the docs and peoples scripts and brains
if we did change it--it wouldn't really win anyone anything:
function portable_strpos($needle, $haystack) {
if (version_compare(phpversion(), "6.0"))) {
return strpos($needle, $haystack);
} else {
return strpos($haystack, $needle);
}
}
--Wez.
On 8/13/05, Ryan King <[EMAIL PROTECTED]> wrote:
On Aug 13, 2005, at 6:50 PM, Jani Taskinen wrote:
On Sat, 13 Aug 2005, Sara Golemon wrote:
This is the first one that comes to my mind:
int strpos (string haystack, mixed needle [, int offset])
And this is why they're inconsistent to begin with. When I look
at strpos() I think: strchr(char *, int) So the parameter
ordering does make sense there (to me).
Yes, coming from a C background you would think like that.
But when you think about it with some logic (not women's logic :):
"I'm looking for a character inside a string."
Or looking for a *needle* in a *haystack*.
-ryan
Thus: strpos(needle, haystack) is the correct way (tm) =)
I agree, though I don't really care so long as its the same in all
the str* and array* functions
-ryan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Donate @ http://pecl.php.net/wishlist.php/sniper
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Sun, 14 Aug 2005, Ilia Alshanetsky wrote: If apc comes bundled then it includes apc_store() and apc_fetch() this is pretty much $_MEMORY with a few tweaks. Yes, but that is restricted to one server installations. I need such a 'global session' that is available with multiple front-end servers..ie. using DB as session storage. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Sun, 14 Aug 2005, Zeev Suraski wrote: worried about the wholesale mode that internals@ switched into, the almost unanimous "YES!" response, and the overall feeling that suddenly with 6.0 Good. Phear the masses. It's not your vote that counts anymore. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
On Sun, 14 Aug 2005, George Schlossnagle wrote:
On Aug 14, 2005, at 3:37 PM, Jani Taskinen wrote:
On Sun, 14 Aug 2005, Ilia Alshanetsky wrote:
If apc comes bundled then it includes apc_store() and apc_fetch() this
is pretty much $_MEMORY with a few tweaks.
Yes, but that is restricted to one server installations.
I need such a 'global session' that is available with multiple
front-end servers..ie. using DB as session storage.
ext/session has the framework for doing this. I concur with your original
idea of augmenting it to provide those services. Perhaps a new autoglobal
$_GLOBAL_SESSION[]. Thoughts?
session_set_application_id('someid');
session_start();
$_SESSION['foobar'] = 'foo';
$_GLOBAL['someid'] = 'bar';
etc.
?>
Thanks to Marc for mentioning the application id. :)
It should propably behave so that if the application id
is not set, then we won't init the $_GLOBAL at all.
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
First: Where can I get that stuff you're smoking? :) On Mon, 15 Aug 2005, Zeev Suraski wrote: upgrade path that does not include auditing their entire codebase. Yes, a script in userspace (bundled and without dependencies) is acceptable. extract() was already mentioned (by Rasmus even?) so I don't understand why you're still trying to propose something as silly as renaming register_globals.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] custom streams
Not critical enough to try and find the fix. Just use 5.1. As far as I'm concerned, 5.0 is dead along with 4.4 :) --Jani On Thu, 18 Aug 2005, Lukas Smith wrote: Hi, I am using custom streams for the LOB support in PEAR::MDB2. It seems that things work nicely on PHP 4.4 and PHP 5.1.0RC1. However using todays windows 5.0.x binarys from snaps.php.net still give me errors. Atleast there is still bug that leads to the stream_eof() return being flipped (false becomes true). http://bugs.php.net/bug.php?id=27508 Seems to indicate this is fixed in CVS, so maybe the problem is that nobody thought we would see 5.0.5? regards, Lukas -- Donate @ http://pecl.php.net/wishlist.php/sniper -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] custom streams
On Thu, 18 Aug 2005, Lukas Smith wrote: Jani Taskinen wrote: Not critical enough to try and find the fix. Just use 5.1. As far as I'm concerned, 5.0 is dead along with 4.4 :) But why even bother with 5.0.5 .. or more specifically whats the purpose of Ask Zeev. minor version if one gets released. So I presume alot of users will be surprised when they find that numerous bugs they would expect to be fixed in a 5.0.5 release. Feel free to go through every commit and check if it was MFH'd. :) If however 5.0.5 never comes to light, then those users will know that they will need to move to 5.1.0 to get the fixes for "fixed in CVS". I'd like to skip 5.0.5 and go with 5.1 instead. We just don't have enough resources to be able to handle 4 branches. (4.4, 5.0, 5.1, HEAD) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ext/gd, cleanup, iirc
On Thu, 18 Aug 2005, Pierre-Alain Joye wrote: * bump the minimum version of the required libs (I left zlib to the base dependency as it is used anywhere). - libpng, 1.2.8 - libjpeg 6b3x - freetype 2.1.10 As long as these are only preferred not required, they're fine. RHEL4 for example has libpng 1.2.7 and freetype 2.1.9. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 6.0 Wishlist
On Mon, 22 Aug 2005, Mikko Rantalainen wrote: upload *before* it has been completed. Make it possible to handle *big* uploads without requiring uploaded file to fit the memory. Handle multiple This was changed in PHP 4.2.0, the file uploading code was rewritten to not load the whole fie in memory. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.0.5 RC2
Yeah, don't release it and push 5.1 instead. Nobody should be using 5.0 anymore after 5.1 is out.. --Jani On Wed, 24 Aug 2005, Zeev Suraski wrote: Any outstanding things for this release beyond PEAR and XMLRPC? I'd like to roll RC2 as soon as possible. Thanks, Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6.0 Wishlist
Let's just nuke all other opening tags than
It would be nice if PHP could not get tripped up by "
Already included, you may have seen this feature used before, I gather he meant making the scanner intelligent enough to see that the followed by 'xml' and just ignoring the fact that short open tags is on. I
wouldn't expect to see it happen (or want it to), but if he wants it, here's a
sloppy implementation:
Index: Zend/zend_language_scanner.l
===
RCS file: /repository/ZendEngine2/zend_language_scanner.l,v
retrieving revision 1.131
diff -u -r1.131 zend_language_scanner.l
--- Zend/zend_language_scanner.l3 Aug 2005 13:30:54 - 1.131
+++ Zend/zend_language_scanner.l27 Aug 2005 21:55:36 -
@@ -1379,6 +1379,12 @@
}
}
+"value.str.val = (char *) estrndup(yytext, yyleng);
+ zendlval->value.str.len = yyleng;
+ zendlval->type = IS_STRING;
+ return T_INLINE_HTML;
+}
"<%="|" if ((yytext[1]=='%' && CG(asp_tags)) || (yytext[1]=='?' &&
CG(short_tags))) {
--
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] PHP 5.1: Does it still require ext/xmlrpc for pear?
If I understood correctly, the fixed XML_RPC pear package was updated to the PHP_5_1 branch already. Why is ext/xmlrpc still required? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 5.1: Does it still require ext/xmlrpc for pear?
On Sat, 27 Aug 2005, Rasmus Lerdorf wrote: Jani Taskinen wrote: If I understood correctly, the fixed XML_RPC pear package was updated to the PHP_5_1 branch already. Why is ext/xmlrpc still required? It isn't. Ok. Fix committed. :) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.1 release..
What's the status with 5.1 release? Somehow I've got the feeling that nobody's doing anything about it after the unicode merge..? (nobody == Dmitry :) And who is the RM for PHP_5_1 branch anyway? --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Tue, 30 Aug 2005, Andrei Zmievski wrote: On Aug 30, 2005, at 10:30 AM, Rasmus Lerdorf wrote: Also, I see the following 6 failed test cases on my Linux box: -Bug #16069 [ext/iconv/tests/bug16069.phpt] According to the last two comments in that bug report, glibc iconv() does not support CP932 and this test should be skipped instead of failing. No idea how to check for that in the test system, so I'll leave it to Jani or someone else. That test HAS a check for it but it doesn't work. :) I don't know how you should test if you have the support or not so I leave that to someone else. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Fix inherent problem with php core ini options
Patch: http://www.php.net/~jani/patches/ini_fix.patch See also: http://bugs.php.net/bug.php?id=34307 --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Fix inherent problem with php core ini options
On Wed, 31 Aug 2005, Jani Taskinen wrote: Patch: http://www.php.net/~jani/patches/ini_fix.patch See also: http://bugs.php.net/bug.php?id=34307 The patch was a bit broken, fixed one now uploaded. (if the one you have grabbed has anything with Zend/zend.c in it, nuke it!) --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
Done. All distros should have at least 2.6.8. Most have 2.6.16 or above.. --Jani On Wed, 31 Aug 2005, Rob Richards wrote: I would suggest bumping up the libxm2 minimum version to 2.6.8. Had forgotten about this until a recent bug, but 2.6.6 and 2.6.7 can cause memory corruption thats fixed in 2.6.8. Rob Zeev Suraski wrote: For those of you who submitted patches to 5.1 since RC1 - do you believe that we need another RC or can we go ahead and roll 5.1 final and run a sanity test for 24 hours? I went over the patches, none of them appears to be too dangerous, but if any of you thinks differently, let me know. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bugs in 5.0.5 and 5.1 RCs
On Wed, 31 Aug 2005, steve wrote: At any rate, there are two problems: 1) That the newly thrown exception blows up into a fatal error that doesn't list the file or line number. Example code? 2) mysqli is unloaded(!?) (or appears to be) before the the user's shutdown function is called. This one is SERIOUS -- I use it to save session data, etc. This then becomes impossible to do. __destruct()'s are called before the user registered shutdown functions. This will not change so don't bother reporting a bug about this. In the backtrace you'll notice that the function table (in fact, all parameters, are, as Markus says, borked!) when going from call_user_function() to call_user_function_ex() on the mysqli extention. #24 0x0823e95c in call_user_function_ex (function_table=0x1, object_pp=0x1, function_name=0x1, retval_ptr_ptr=0x1, param_count=1, params=0x1, no_separation=1, symbol_table=0x1) at /php-5.1.0RC1/Zend/zend_execute_API.c:571 #25 0x0823e998 in call_user_function (function_table=0xa0a2350, object_pp=0x0, function_name=0xa43f80c, retval_ptr=0xbfe96ad0, param_count=0, params=0xa448280) at /php-5.1.0RC1/Zend/zend_execute_API.c:544 Provide short (and I mean SHORT) reproducing script before you report any bugs about this. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Thu, 1 Sep 2005, Derick Rethans wrote: On Wed, 31 Aug 2005, Derick Rethans wrote: On Tue, 30 Aug 2005, Zeev Suraski wrote: For those of you who submitted patches to 5.1 since RC1 - do you believe that we need another RC or can we go ahead and roll 5.1 final and run a sanity test for 24 hours? I went over the patches, none of them appears to be too dangerous, but if any of you thinks differently, let me know. Should I also commit: http://files.derickrethans.nl/patches/e_recoverable_error-php-5.1-20050826.diff.txt ? Should I assume that if nobody replies, there are no objections? I'm replying now and I don't want to see something like this in 5.1. This is new stuff, new stuff goes to HEAD.. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
On Wed, 31 Aug 2005, Ondrej IvaniÄ wrote: Jani Taskinen wrote: On Tue, 30 Aug 2005, Andrei Zmievski wrote: On Aug 30, 2005, at 10:30 AM, Rasmus Lerdorf wrote: Also, I see the following 6 failed test cases on my Linux box: -Bug #16069 [ext/iconv/tests/bug16069.phpt] According to the last two comments in that bug report, glibc iconv() does not support CP932 and this test should be skipped instead of failing. No idea how to check for that in the test system, so I'll leave it to Jani or someone else. That test HAS a check for it but it doesn't work. :) I don't know how you should test if you have the support or not so I leave that to someone else. Is this way acceptable? $cp932 = (strpos(trim(`iconv -l | grep CP932`), 'CP932') === 0); No. Even if CP932 is not supported, it's still listed. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] sqlite: retrieve SQL syntax errors
On Fri, 2 Sep 2005, Ilia Alshanetsky wrote:
the "feature request":
prints "SQL logic error or missing database", but you don't have a clue
of what error is.
with my patch, you can retrieve the error (in the additional variable)
you get in the Warning message ("no such column: column").
Aha, I see... that is indeed useful. +1
Just commit it..
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
