Re: [PHP-DEV] Safe mode being removed in PHP6?
Mark Krenz wrote: ??? What do you mean? I talked with Ryan Bloom about this at Apache Con 2000 and he said that with Apache 2.0, modules would be able to run code with the permissions of the user assigned to each vhost. I asked about the prospect of PHP being able to utilize this and he said its possible, but I got the impression that the PHP devs where not interested. This is the perchild MPM. It was supposed to allow you to configure a given number of threads per user, which in your case would mean per virtualhost, and it would route requests correctly to these pools of threads. If you had done a bit of reading on the history of the perchild MPM since 2000, you would have discovered that it was never completed and it is no longer part of Apache2. The concept looked sort of ok on paper, but it had a number of problems. On the PHP side the main drawback with it was that it required a threadsafe environment. Back in 2000 most of the libraries PHP could be linked against were not threadsafe, and even today it is rather risky to run in threaded mode if you link in a lot of 3rd-party libraries. A small dedicated server with a limited number of extensions can run quite well threaded, but in an ISP situation where you basically have to link in everything under the sun, getting everything stable and robust in a threaded environment is painful. You will never get a 100% secure web server. It just doesn't happen. The best you can do is use a layered approach where each of your layers act at different levels and hope that the holes in each of your layers don't all line up. Think of it as using 3 innertubes in a tire each of them with a couple of holes in them. You'd have to be pretty unlucky to have a leaky tire. But in order for this to work the layers have to act on different levels and they have to all be trying to achieve one thing. In our case, what we are trying to achieve is to prevent external users from exploiting flaws in PHP or in userspace code to attack the server or the application. Safemode doesn't fit this. Safemode was a misguided attempt at providing some sort of protection against malicious users on the same server. There are no layers to help us here, and it has multiple known holes, so the tire is always flat. PHP is the wrong level to try to protect users from other users on the same server. No language does this. You brought up Perl, for some reason. It also has absolutely no way to protect two perl scripts that run as the same user id on the same server from mucking with each others' files. I added safemode to PHP years and years ago when it was a much simpler beast. I'm not (always) an idiot, and I knew at the time that it wasn't the right place to add this protection, but the alternatives at the time weren't viable, and I needed it. It was even somewhat effective since it has less things to deal with. As PHP grew and became more complex and linked in more complex libraries, it became completely impossible to even begin to pretend that safemode was still effective. Any 3rd-party library that accesses files are not subject to the safemode check unless we can somehow catch it at the PHP level. For stuff like the Oracle client library where an sql query can open a file, and that query can be written a hundred different ways, there is absolutely no way to make safemode work. We don't have the source code to this library and there are no hooks for us to override file access in it. I appreciate that you think we should just solve these problems and make safemode perfect because that would make your life easier, and I appreciate, well I don't actually, that you think we are idiots for not doing so, but while we may be idiots, we have actually thought about this quite a bit, and we consider it an intractable problem. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Safe mode being removed in PHP6?
On 8/26/07, Mark Krenz [EMAIL PROTECTED] wrote: No, this is the wrong way to approach the problem. No, this is the right way, language level security does not replace OS level security. I'm bringing it up because its something that needs to be fixed in PHP. No, fixing this issue in PHP itself is the wrong way, the only issues that needs to be fixed in PHP are. 1. security holes of PHP itself. 2. the PHP documentation in the cases it promotes bad programming practises. 3. disabling include() and require() with URls **permantently** may help as well ;P But I'm one of the ones from the 90s that cares greatly about security. If you care greatly about security then safe_mode is certainly **not** what you need, if you think so, you have been seriously misguided. -- http://www.kissofjudas.net/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Namespaces and __autoload()
Hi,
Please look into patch that implements __autoload() support for namespaces.
The patch touches not only ZE but also SPL.
In the following code we cannot exactly know if Exception class is from
current namespace or it is an internal PHP class.
?php
namespace Foo;
throw new Exception;
In this case PHP first looks for Foo::Exception and only then for internal
Exception, but the first lookup may call __autoload (or corresponding SPL
functions) and it can emit error or throw exception.
The patch provides an additional boolean argument to __autoload() that say
if class is really required. In case if it false, user code shouldn't emit
errors or throw exceptions.
I am going to commit the patch on Wednesday.
It is the last semantic patch for namespaces we have.
After its commit we are going to look into syntax problems (namespace or
package, brackets, import or using, ...).
Thanks. Dmitry.
Index: Zend/zend_builtin_functions.c
===
RCS file: /repository/ZendEngine2/zend_builtin_functions.c,v
retrieving revision 1.349
diff -u -p -d -r1.349 zend_builtin_functions.c
--- Zend/zend_builtin_functions.c 24 Aug 2007 13:50:52 - 1.349
+++ Zend/zend_builtin_functions.c 24 Aug 2007 14:33:21 -
@@ -689,7 +689,7 @@ static void is_a_impl(INTERNAL_FUNCTION_
convert_to_text_ex(class_name);
- if (zend_u_lookup_class_ex(Z_TYPE_PP(class_name),
Z_UNIVAL_PP(class_name), Z_UNILEN_PP(class_name), 0, 1, ce TSRMLS_CC) ==
FAILURE) {
+ if (zend_u_lookup_class_ex(Z_TYPE_PP(class_name),
Z_UNIVAL_PP(class_name), Z_UNILEN_PP(class_name), ZEND_AUTOLOAD_DISABLED, 1,
ce TSRMLS_CC) == FAILURE) {
retval = 0;
} else {
if (only_subclass) {
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.765
diff -u -p -d -r1.765 zend_compile.c
--- Zend/zend_compile.c 24 Aug 2007 13:50:52 - 1.765
+++ Zend/zend_compile.c 24 Aug 2007 14:33:22 -
@@ -1355,8 +1355,8 @@ void zend_do_end_function_declaration(zn
}
if (lcname_len == sizeof(ZEND_AUTOLOAD_FUNC_NAME) - 1
ZEND_U_EQUAL(utype, lcname, lcname_len,
ZEND_AUTOLOAD_FUNC_NAME, sizeof(ZEND_AUTOLOAD_FUNC_NAME)-1)
- CG(active_op_array)-num_args != 1) {
- zend_error(E_COMPILE_ERROR, %s() must take exactly 1
argument, ZEND_AUTOLOAD_FUNC_NAME);
+ CG(active_op_array)-num_args != 1
CG(active_op_array)-num_args != 2) {
+ zend_error(E_COMPILE_ERROR, %s() must take exactly 1
or 2 arguments, ZEND_AUTOLOAD_FUNC_NAME);
}
if (lcname.s != lcname_buf) {
efree(lcname.s);
Index: Zend/zend_execute.h
===
RCS file: /repository/ZendEngine2/zend_execute.h,v
retrieving revision 1.108
diff -u -p -d -r1.108 zend_execute.h
--- Zend/zend_execute.h 21 Jul 2007 00:34:41 - 1.108
+++ Zend/zend_execute.h 24 Aug 2007 14:33:22 -
@@ -75,6 +75,19 @@ static inline void safe_free_zval_ptr_re
FREE_ZVAL_REL(p);
}
}
+
+/* The following constants should be used as use_autoload argument
+ for function zend_u_lookup_class_ex() and thay control the execution
+ of user function __autoload.
+ The function __autoload() is extended with additional boolean argument
+ that shows if class is stricly required or may be absent.
+ This argument is necessary to avoid error reporting in user code during
+ resolving of ambiguous class name in namespace.
+*/
+#define ZEND_AUTOLOAD_DISABLED0 /* doesn't call __autoload() */
+#define ZEND_AUTOLOAD_REQUIRED1 /* calls __autoload($name, true); */
+#define ZEND_AUTOLOAD_ENABLED 2 /* calls __autoload($name, false); */
+
ZEND_API int zend_lookup_class(char *name, int name_length, zend_class_entry
***ce TSRMLS_DC);
ZEND_API int zend_lookup_class_ex(char *name, int name_length, int
use_autoload, zend_class_entry ***ce TSRMLS_DC);
ZEND_API int zend_u_lookup_class(zend_uchar type, zstr name, int name_length,
zend_class_entry ***ce TSRMLS_DC);
Index: Zend/zend_execute_API.c
===
RCS file: /repository/ZendEngine2/zend_execute_API.c,v
retrieving revision 1.413
diff -u -p -d -r1.413 zend_execute_API.c
--- Zend/zend_execute_API.c 24 Aug 2007 13:50:52 - 1.413
+++ Zend/zend_execute_API.c 24 Aug 2007 14:33:22 -
@@ -853,7 +853,7 @@ int zend_call_function(zend_fcall_info *
} else if (calling_scope clen == sizeof(parent) -
1
ZEND_U_EQUAL(Z_TYPE_P(fci-function_name), lcname,
clen, parent, sizeof(parent)-1)) {
ce_child = EG(active_op_array)
EG(active_op_array)-scope
[PHP-DEV] PHP 4 Bug Summary Report
PHP 4 Bug Database summary - http://bugs.php.net Num Status Summary (629 total including feature requests) ===[*Programming Data Structures]= 40496 Assigned Test bug35239.phpt still fails (works in PHP 5) ===[*Regular Expressions]= 42283 Open problem in regular expressions ===[Apache2 related]== 38670 Open Whole 4.4.x branch has problem with open_basedir option nested from Apache2 ===[Arrays related]=== 31114 Assigned foreach modify array (works with PHP 5.1) 37451 Open array_multisort fails to trigger by val copy of data (works in PHP = 5.1) 39764 Suspended array_key_exists inconsistent behavior 42177 Open Warning array_merge_recursive(): recursion detected comes again... ===[CGI related]== 40286 Open PHP fastcgi with PHP_FCGI_CHILDREN don't kill children when parent is killed 42180 Open php in fastcgi environment periodicaly get 90% of CPU ===[Class/Object related]= 39254 Open Refcount error with static variables and object references (PHP4 only) 39681 Open this assignment outside class breaks static function call (PHP4 only) ===[Compile Failure]== 42252 Analyzed Windows compile failure with mbstring and zend_multibyte ===[Documentation problem] 29045 Suspended gzopen for URL 36663 Open unexpected difference between zlib.output_compression and ob_gzhandler ===[FDF related]== 34811 Assigned fdf_get_value max size ===[Feature/Change Request]=== 3066 Open Parameter for dns functions to select different DNS 3799 Suspended default_charset brings small incompatibility 3830 Open Function to timeout/break off a function 5007 Analyzed enable no-resolve mode for here docs 5169 Open Missing recursive behavior 5311 Analyzed implement checkdnsrr() and getmxrr() on windows 5575 Open open_basedir to ~ 5601 Analyzed @function() should not turn of error reporting for critical errors 5804 Open parser error if any spaces follow indentifier in with here doc syntax 5883 Assigned --enable-trans-sid modification request 5954 Open Informix can't reliably figure if a text result column is NULL 5975 Open version of strip_tags() that specifies tags to strip (instead of tags to keep) 6118 Open Can not supress runtime warnings on foreach 6268 Open ternary op return only by value 6399 Open checkdate should be able to validate a time as well as a date (timestamp) 6427 Open func_get_arg() does not support references 6503 Open no support for multiple resultset query? 6512 Analyzed sort() Does not sort stings as expected 6574 Open SMTP functions via IMAP c-client library 6680 Open regexps (ereg*) ignores locale settings 6911 Open Problem with array_merge(_recursive) 6927 Suspended 6932 Open Filesize / File_exists and include_path 6993 Open uninstalling is a pain in the ass 7006 Open preg_replace ( string pattern, array replacement, string subject ); 7028 Analyzed xml=shared and wddx do not work together 7132 Assigned fsockopen doesn't report dns lookup failure 7398 Open Stored procedure error return values not passed through 7507 Open Better ODBC error reporting/fetching 7541 Open please consider also support HPUX shl_* 7553 Open RFC: Uplevel Block structure 7559 Open zend_hash_get_current_key_ex returning persistent strings 7578 Open next() and current() do not return referenceing arrays 7808 Open variable value triggerd by function 7923 Analyzed htmlentities doesn't work for ISO 8859-2 7930 Open List() constructor reference assignment 8100 Assigned extract(), extra feature 8108 Analyzed implement trans-sid as output handler 8295 Open absolute path in extension= directive in php.ini not recognized 8395 Open register_shutdown_function() error 8397 Open Multi-results sets are not suppported 8427 Analyzed Unwanted references 8428 Open continue doesn't pass thru a switch statement 8595 Open More effective parsing of list() (+other) 8640 Open enumeration type 8685 Open heredoc: remove column 1 closing identifier requirement 8809 Open Cookieless session with Header redirects 8827 Open PHP_AUTH_PW stores password when using External Authentication 8855 Open session_start should return also FALSE 8897 Open Significant portions of the InterBase API have no PHP representation. 8948 Open
[PHP-DEV] What should be in 5.3?
Hi, In the spirit of forwards compabitility I think the 5.3 release will we very important regardless if we keep or remove the unicode switch in PHP6. From my POV 5.1 and 5.2 have mainly covered stability and performance improvements on top of the addition of several important extensions like PDO, Json etc. In terms of changes to the actual language the main thing that sticks in my head where things like E_STRICT and is_a vs. instanceOf. So now with 5.3 we might want to look ahead towards PHP6 and make sure that we add whatever makes sense to have in 5.x that will ease the life for people writing forward compatible code for PHP6. It might also be a chance to revisit the question of how we want to approach strictness and deprecation. Forward compatibility: - binary cast - namespaces - ... Strictness: - What is our philisophy, is OO more strict than procedural or is there no such differntiation? I remember the discussions about dynamic member variables, number incrementing throwing notices inconsistently, signature rewriting. I fear I am opening a can of worms with this one. Although I disagree with the bulk of the decisions on this topic in the past I am not trying to reopen the discussions, I just hope to get a clearer definition on our philosiphie for future discussions Deprecation: - Split of deprecation from E_STRICT - Rule for deprecation See the todo wiki for some hints on things currently planned (or that I heard people thinking about planning): http://oss.backendmedia.com/PhP53 http://oss.backendmedia.com/PhP60 regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net Num Status Summary (54 total including feature requests) ===[*General Issues]== 26771 Suspended register_tick_funtions crash under threaded webservers 27372 Assigned parse error loading browscap.ini at apache startup (new parser required) ===[*Unicode Issues]== 42163 Open fgetcvs gives different output with and without Unicode ===[Apache2 related]== 42209 Open fail on make for sapi/apache2handler/apache_config.lo ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 ===[Class/Object related]= 33595 Assigned recursive references leak memory 41461 Assigned E_STRICT notice when overriding methods not defined by an Interface in hierarchy ===[Feature/Change Request]=== 20377 Open php_admin_value affects _only_ .htaccess 27618 Open curl_multi_info_read does not appear to work 29479 Suspended changing current process name 34211 Open PDO_OCI: Allow for data type TIMESTAMP(0) WITH LOCAL TIME ZONE 34252 Open Base functions extension and refactoring 34527 Open trim functions extension 34775 Open parse_url() provide better error description on failure 34882 Open Unable to access *original* posted variable name with dot in 35309 Open Database connection pooling 37081 Open Make the include-errors mention faulty permissions 37380 Open DOMDocument-createAttribute[NS] can't set value 37546 Open DOMDocumentFragment-appendXML namespace support 37796 Open t_is_not_identical for ? 38622 Open Proposed new security scheme for shared hosting (safe mode substitute) 38946 Open pecl/docblock should be merged into ext/tokenizer 40013 Open php_uname() doesnt return nodename 40499 Open filter sapi does not register any highlightning filter 40713 Open set_magic_quotes_runtime(0) causes Fatal Error 41019 Assigned auto update feature for FastCGI for IIS 41119 Open range() function behavior different on PHP6 and PHP5 41602 Open POSIX functions on Windows using Cygwin Library 42262 Open get_magic_quotes_gpc() should be there and return false ===[Filesystem function related]== 27792 Assigned Functions fail on large files (filesize,is_file,is_dir) 42037 Open fgetc() retuns one char when fails to read on php6 42057 Open fwrite() writes data into file when length is given as a negative value 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 42125 Open fgetss reads an extra char from file created using file_put_content() 42126 Open size of the file differ, when created using file_put_content() on php6 42167 Open fgetcsv gives different output on php6 compared to php5 42219 Open length argument of fgetcsv() is not effective/working in PHP6 42229 Open fgetcsv() behaves differently for a file containing '\n' with php5 and php6. ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[ODBC related]= 39756 Assigned Crashes in fetching resultsets with LONG ASCII columns from MaxDB ===[OpenSSL related]== 25614 Suspended openssl_pkey_get_public() fails when given a private key ===[Other web server]= 26495 Suspended Using WebSite Pro 2.5 with ISAPI, cookies are not working ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize 39171 Assigned pdo_mysql configure script sets empty default socket 42079 Open pdo_mysql always links to 3.x libraries ===[Program Execution] 39992 Open proc_terminate() leaves children of child running ===[Scripting Engine problem]= 33487 Assigned Memory allocated for objects created in object methods is not released 39216 Assigned call_user_func and friends don't accept array($this, func) callback anymore 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe ===[Session related]== 32330 Open session_destroy, Failed to initialize storage module, custom session handler
[PHP-DEV] 5.2.4RC was Re: [PHP-CVS] cvs: php-src(PHP_5_2) / NEWS /ext/gd/libgd gd.c /ext/gd/tests libgd00106.phpt
Hi,
I reverted this commit even if I strongly disagree with how 5.2.4-rc3
has been released and how the 5.2 was frozen without previous mail.
About 5.2.4 in general, there is still issues on windows. I have no
idea how to get the required libs updated (looks like png, freetype
and pslib have not been updated).
If they are updated, we will need another RC. If they are not and/or
if I can't commit fixes then we have serious problems in our release
process and how we communicate. I'm not sure how to fix them as I have
no control on this process.
Cheers,
--Pierre
Ilia Alshanetsky wrote:
Please revert, its too late for this patch in 5.2.4
Thanks,
On 26-Aug-07, at 4:35 PM, Pierre-Alain Joye wrote:
pajoyeSun Aug 26 20:35:11 2007 UTC
Added files: (Branch: PHP_5_2)
/php-src/ext/gd/testslibgd00106.phpt
Modified files:
/php-src/ext/gd/libgdgd.c
/php-srcNEWS
Log:
- MFB: gd #106, imagerectangle draws 1x1 rectangles as 1x3 rectangles
http://cvs.php.net/viewvc.cgi/php-src/ext/gd/libgd/gd.c?r1=1.90.2.1.2.17r2=1.90.2.1.2.18diff_format=u
Index: php-src/ext/gd/libgd/gd.c
diff -u php-src/ext/gd/libgd/gd.c:1.90.2.1.2.17
php-src/ext/gd/libgd/gd.c:1.90.2.1.2.18
--- php-src/ext/gd/libgd/gd.c:1.90.2.1.2.17Sun Jun 17 19:03:58 2007
+++ php-src/ext/gd/libgd/gd.cSun Aug 26 20:35:10 2007
@@ -2124,6 +2124,12 @@
int half1 = 1;
int t;
+
+if (x1 == x2 y1 == y2 thick == 1) {
+gdImageSetPixel(im, x1, y1, color);
+return;
+}
+
if (y2 y1) {
t=y1;
y1 = y2;
http://cvs.php.net/viewvc.cgi/php-src/NEWS?r1=1.2027.2.547.2.910r2=1.2027.2.547.2.911diff_format=u
Index: php-src/NEWS
diff -u php-src/NEWS:1.2027.2.547.2.910 php-src/NEWS:1.2027.2.547.2.911
--- php-src/NEWS:1.2027.2.547.2.910Thu Aug 23 22:39:01 2007
+++ php-src/NEWSSun Aug 26 20:35:11 2007
@@ -1,5 +1,6 @@
PHP
NEWS
|||
+- Fixed regression in imagerectangle for 1x1 rectangle (gd bug
#106) (Pierre)
23 Aug 2007, PHP 5.2.4RC3
- Fixed version_compare() to support rc as well as RC for release
candidate version numbers.
http://cvs.php.net/viewvc.cgi/php-src/ext/gd/tests/libgd00106.phpt?view=markuprev=1.1
Index: php-src/ext/gd/tests/libgd00106.phpt
+++ php-src/ext/gd/tests/libgd00106.phpt
--TEST--
libgd #106 (imagerectangle 1x1 draws 1x3)
--SKIPIF--
?php
if (!extension_loaded('gd')) die(skip gd extension not available\n);
?
--FILE--
?php
$im = imagecreatetruecolor(10,10);
imagerectangle($im, 1,1, 1,1, 0xFF);
$c1 = imagecolorat($im, 1,1);
$c2 = imagecolorat($im, 1,2);
$c3 = imagecolorat($im, 2,1);
$c4 = imagecolorat($im, 2,2);
if ($c1 == 0xFF $c2 == 0 $c3 == 0 $c4 == 0) {
echo Ok;
} else {
echo failed;
}
?
--EXPECT--
Ok
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
As an answer to question in subject: HEAD/5.3 should be identical except for the unicode support which is the only thing PHP 6 is about. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
Hello Lukas, I added 'MFH namespace' to the TODO list. Otherwise I am fine. For the given amount of stuff with my name on it I'd need some time though. marcus Monday, August 27, 2007, 11:30:22 AM, you wrote: Hi, In the spirit of forwards compabitility I think the 5.3 release will we very important regardless if we keep or remove the unicode switch in PHP6. From my POV 5.1 and 5.2 have mainly covered stability and performance improvements on top of the addition of several important extensions like PDO, Json etc. In terms of changes to the actual language the main thing that sticks in my head where things like E_STRICT and is_a vs. instanceOf. So now with 5.3 we might want to look ahead towards PHP6 and make sure that we add whatever makes sense to have in 5.x that will ease the life for people writing forward compatible code for PHP6. It might also be a chance to revisit the question of how we want to approach strictness and deprecation. Forward compatibility: - binary cast - namespaces - ... Strictness: - What is our philisophy, is OO more strict than procedural or is there no such differntiation? I remember the discussions about dynamic member variables, number incrementing throwing notices inconsistently, signature rewriting. I fear I am opening a can of worms with this one. Although I disagree with the bulk of the decisions on this topic in the past I am not trying to reopen the discussions, I just hope to get a clearer definition on our philosiphie for future discussions Deprecation: - Split of deprecation from E_STRICT - Rule for deprecation See the todo wiki for some hints on things currently planned (or that I heard people thinking about planning): http://oss.backendmedia.com/PhP53 http://oss.backendmedia.com/PhP60 regards, Lukas Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] PDO_sqlite data types
The attached patch adds basic support for storing properly-typed
integer and boolean data in SQLite3 databases. I don't really
understand why this kind of support has been so consistently lacking
in PHP database driver implementations. Similar problems have plagued
the MySQL and MySQLi extensions for a long time, and PDO seems to
struggle for the support at times. This diff is against PHP 5.2.3,
but I've verified that it works in 5.2.4RC3, 5.2.4 CVS, and HEAD.
This by itself disturbs me because it indicates that in all this time
this code hasn't been touched at all. Was it really that hard to add
this very simple code?
-- Gwynne, Daughter of the Code
This whole world is an asylum for the incurable.
Index: ext/pdo_sqlite/sqlite_statement.c
===
RCS file: /repository/php-src/ext/pdo_sqlite/sqlite_statement.c,v
retrieving revision 1.18.2.4.2.2
diff -u -r1.18.2.4.2.2 sqlite_statement.c
--- ext/pdo_sqlite/sqlite_statement.c 1 Jan 2007 09:36:05 -
1.18.2.4.2.2
+++ ext/pdo_sqlite/sqlite_statement.c 27 Aug 2007 10:08:42 -
@@ -96,7 +96,22 @@
switch (PDO_PARAM_TYPE(param-param_type)) {
case PDO_PARAM_STMT:
return 0;
-
+
+ case PDO_PARAM_INT:
+ case PDO_PARAM_BOOL:
+ if (Z_TYPE_P(param-parameter)
== IS_NULL) {
+ if (sqlite3_bind_null(S-stmt, param-paramno + 1) ==
SQLITE_OK) {
+ return 1;
+ }
+ } else {
+
convert_to_long(param-parameter);
+ if (SQLITE_OK == sqlite3_bind_int(S-stmt, param-paramno +
1, Z_LVAL_P(param-parameter))) {
+ return 1;
+ }
+ }
+ pdo_sqlite_error_stmt(stmt);
+ return 0;
+
case PDO_PARAM_NULL:
if (sqlite3_bind_null(S-stmt,
param-paramno + 1) == SQLITE_OK) {
return 1;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
Lukas Kahwe Smith schrieb: [...] - New Garbage Collector (GSoC) - Late Static Binding -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Too many extensions bundled with the Windows Installer?
On 8/21/07, John Mertic [EMAIL PROTECTED] wrote: Added a hack to care of that for 5.2.4. I see a few possibilities for a future solution to the problem: 1) Include builds from HEAD for only a certain set of known stable PECL extensions ( APC, uploadprogress, etc ). 2) Include builds from HEAD for all PECL extensions that build, but put those known stable ones in one tree and the unstable in another. 3) Include only extensions that have a stable release that builds under win32. 4) Include only extensions that have a stable release that builds under win32 for only a certain set of known stable PECL extensions ( APC, uploadprogress, etc ). 5) Include only extensions that have a stable release that builds under win32, but put those known stable ones in one tree and the unstable in another. Of these, I see (1) or (2) as the easiest to implement, but (3), (4), or (5) as being a more ideal solution. Or perhaps there is some solution in the middle that I'm missing. What sounds good to everyone else? 6) Put none and point the users to pecl.php.net and pecl4win.php.net An extension is bundled, available through pecl or both. It is not a joke to fetch extension from pecl42win. We are also working on some improvements on the win32 extension build process (see the ML archive). All in all, I see no reason to bundled a bunch of extensions that we don't support anyway (the php qa/core team). That does not mean they are bot useable or safe, only that we don't support them through php releases. Cheers, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Too many extensions bundled with the Windows Installer?
On 8/27/07, Pierre [EMAIL PROTECTED] wrote: 6) Put none and point the users to pecl.php.net and pecl4win.php.net An extension is bundled, available through pecl or both. It is not a joke to fetch extension from pecl42win. We are also working on some improvements on the win32 extension build process (see the ML archive). All in all, I see no reason to bundled a bunch of extensions that we don't support anyway (the php qa/core team). That does not mean they are bot useable or safe, only that we don't support them through php releases. That seems like the best solution to me. I think that instead of delivering just the dll files and expecting the users to put them in the right place and edit the php.ini file correctly, we need to deliver them in an installer format OR make 'pecl install xxx' actually work on win32 ( and when I mean actually work, pull against the pre-built dlls on pecl4win ). I can put together a framework for an installer if that's the route we want to go. Edin, can you no longer add in the PECL libraries to the installer when building it... -- -- John MerticExplaining a joke is like dissecting a frog: you [EMAIL PROTECTED] understand it better, but the frog dies in the process. -Mark Twain -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] PDO_sqlite data types
The attached patch adds basic support for storing properly-typed integer and boolean data in SQLite3 databases. I don't really understand why It would be nice to have some tests to verify if it works or not :) -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What should be in 5.3?
Don't you thing that a far-reaching thing like garbage collector is best left until a major release? -Andrei http://10fathoms.org/vu - daily photoblog Sebastian Bergmann wrote: Lukas Kahwe Smith schrieb: [...] - New Garbage Collector (GSoC) - Late Static Binding -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces and __autoload()
?php namespace Foo; throw new Exception; In this case PHP first looks for Foo::Exception and only then for internal Exception, but the first lookup may call __autoload (or corresponding SPL functions) and it can emit error or throw exception. The patch provides an additional boolean argument to __autoload() that say if class is really required. In case if it false, user code shouldn't emit errors or throw exceptions. There's two problems here: 1. On each access to internal class, like Exception, SPL classes, DateTime, reflection classes, etc. - we'd have call to autoload and subsequent disk access, maybe more than one if we have include path. Performance of it would be awful. 2. All libraries having autoloaders would have to rewrite them to support the new mode. I would propose different solution. When we have unresolved unqualified name, we do the following: 1. Check if we already know such class in namespace at compile-time. If so, it's resolved. 2. If not, will be resolved at run-time. 3. At run-time, check if we know such class in namespace now. If yes, it's resolved. 4. If not, check if we know internal class with such name. If yes, it's resolved to internal class. 5. If not, try to autoload this class. If autoloading fails, it's the undefined class error. This rule is a bit more complex, but allows to resolve common cases without extra filesystem accesses and allows to keep autoloader without modification. Comments? -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Namespaces and __autoload()
This is an implementation of Stas idea.
1) Look for existent class in current namespace
2) Look for existent internal class
3) Try to autoload class from current namespace
Thanks. Dmitry.
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Monday, August 27, 2007 9:49 PM
To: Dmitry Stogov
Cc: 'PHP Internals List'
Subject: Re: [PHP-DEV] Namespaces and __autoload()
?php
namespace Foo;
throw new Exception;
In this case PHP first looks for Foo::Exception and only then for
internal Exception, but the first lookup may call __autoload (or
corresponding SPL
functions) and it can emit error or throw exception.
The patch provides an additional boolean argument to
__autoload() that
say if class is really required. In case if it false, user code
shouldn't emit errors or throw exceptions.
There's two problems here:
1. On each access to internal class, like Exception, SPL classes,
DateTime, reflection classes, etc. - we'd have call to autoload and
subsequent disk access, maybe more than one if we have include path.
Performance of it would be awful.
2. All libraries having autoloaders would have to rewrite them to
support the new mode.
I would propose different solution. When we have unresolved
unqualified
name, we do the following:
1. Check if we already know such class in namespace at
compile-time. If
so, it's resolved.
2. If not, will be resolved at run-time.
3. At run-time, check if we know such class in namespace now. If yes,
it's resolved.
4. If not, check if we know internal class with such name. If
yes, it's
resolved to internal class.
5. If not, try to autoload this class. If autoloading fails, it's the
undefined class error.
This rule is a bit more complex, but allows to resolve common cases
without extra filesystem accesses and allows to keep
autoloader without
modification.
Comments?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Index: Zend/zend_constants.c
===
RCS file: /repository/ZendEngine2/zend_constants.c,v
retrieving revision 1.99
diff -u -p -d -r1.99 zend_constants.c
--- Zend/zend_constants.c 25 Aug 2007 23:28:10 - 1.99
+++ Zend/zend_constants.c 27 Aug 2007 17:59:12 -
@@ -333,7 +333,7 @@ ZEND_API int zend_u_get_constant_ex(zend
if ((UG(unicode) (colon.u = u_memrchr(name.u, ':', name_len))
colon.u name.u *(colon.u-1) == ':') ||
(!UG(unicode) (colon.s = zend_memrchr(name.s, ':', name_len))
colon.s name.s *(colon.s-1) == ':')) {
/* compound constant name */
- zend_class_entry **ce = NULL;
+ zend_class_entry *ce = NULL;
int class_name_len =
UG(unicode)?colon.u-name.u-1:colon.s-name.s-1;
int const_name_len = name_len - class_name_len - 2;
zstr constant_name, class_name;
@@ -366,7 +366,7 @@ ZEND_API int zend_u_get_constant_ex(zend
if (lcname_len == sizeof(self)-1
ZEND_U_EQUAL(type, lcname, lcname_len, self,
sizeof(self)-1)) {
if (scope) {
- ce = scope;
+ ce = scope;
} else {
zend_error(E_ERROR, Cannot access self:: when
no class scope is active);
retval = 0;
@@ -379,7 +379,7 @@ ZEND_API int zend_u_get_constant_ex(zend
} else if (!scope-parent) {
zend_error(E_ERROR, Cannot access parent::
when current class scope has no parent);
} else {
- ce = scope-parent;
+ ce = scope-parent;
}
efree(lcname.v);
} else {
@@ -427,31 +427,11 @@ ZEND_API int zend_u_get_constant_ex(zend
efree(lcname.v);
/* Check for class */
- if (zend_u_lookup_class(type, class_name,
class_name_len, ce TSRMLS_CC) != SUCCESS
- (flags ZEND_FETCH_CLASS_RT_NS_CHECK) != 0) {
- retval = 0;
- if ((UG(unicode) (colon.u =
u_memrchr(class_name.u, ':', class_name_len)) colon.u class_name.u
*(colon.u-1) == ':') ||
- (!UG(unicode) (colon.s =
zend_memrchr(class_name.s, ':', class_name_len)) colon.s class_name.s
*(colon.s-1) == ':')) {
-
- if (UG(unicode)) {
- colon.u++;
- lcname_len =
Re: [PHP-DEV] What should be in 5.3?
Andrei Zmievski schrieb: Don't you thing that a far-reaching thing like garbage collector is best left until a major release? It is just a number. We could, of course, also take what is in HEAD minus Unicode and release it, together with Garbage Collector, Late Static Bindings, and some other pending changes as PHP 6 and make PHP 7 the Unicode Release. :-) -- Sebastian Bergmann http://sebastian-bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Namespaces and __autoload()
Dmitry Stogov wrote:
This is an implementation of Stas idea.
1) Look for existent class in current namespace
2) Look for existent internal class
3) Try to autoload class from current namespace
both ways have a wtf factor in that class with names
matching 'internal' class names behave differently.
afaict you would not be able to autoload class Exception
from within namespace Foo in the example below.
currently one cannot create classes named the same as
'internal' classes ... obviously.
I would consider making internal class names illegal
in namespaces. this would be consistent simple and clear.
also I don't see what would be gained from being allowed
to do:
?php
namespace Foo;
class Exception extends Exception {};
I assume all the SPL stuff wont be moved into into own
namespace straight away with regard to BC, would that be correct?
rgds,
Jochem
Thanks. Dmitry.
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Monday, August 27, 2007 9:49 PM
To: Dmitry Stogov
Cc: 'PHP Internals List'
Subject: Re: [PHP-DEV] Namespaces and __autoload()
?php
namespace Foo;
throw new Exception;
In this case PHP first looks for Foo::Exception and only then for
internal Exception, but the first lookup may call __autoload (or
corresponding SPL
functions) and it can emit error or throw exception.
The patch provides an additional boolean argument to
__autoload() that
say if class is really required. In case if it false, user code
shouldn't emit errors or throw exceptions.
There's two problems here:
1. On each access to internal class, like Exception, SPL classes,
DateTime, reflection classes, etc. - we'd have call to autoload and
subsequent disk access, maybe more than one if we have include path.
Performance of it would be awful.
2. All libraries having autoloaders would have to rewrite them to
support the new mode.
I would propose different solution. When we have unresolved
unqualified
name, we do the following:
1. Check if we already know such class in namespace at
compile-time. If
so, it's resolved.
2. If not, will be resolved at run-time.
3. At run-time, check if we know such class in namespace now. If yes,
it's resolved.
4. If not, check if we know internal class with such name. If
yes, it's
resolved to internal class.
5. If not, try to autoload this class. If autoloading fails, it's the
undefined class error.
This rule is a bit more complex, but allows to resolve common cases
without extra filesystem accesses and allows to keep
autoloader without
modification.
Comments?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [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] Namespaces and __autoload()
afaict you would not be able to autoload class Exception from within namespace Foo in the example below. I think if you want it to work you don't have to autoload it/ I would consider making internal class names illegal in namespaces. this would be consistent simple and clear. It's one of the options, but I'm not sure it's the best one. Opinions welcome. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces and __autoload()
Stanislav Malyshev wrote: I would consider making internal class names illegal in namespaces. this would be consistent simple and clear. It's one of the options, but I'm not sure it's the best one. Opinions welcome. I don't think that's a good solution because that kind of defeats the reason we want to introduce namespaces in the first place: I can name my classes without having to be afraid of a name clash later on when PHP adds new classes. Unless the restriction only applies to the current (global) internal classes and all new classes are going to be introduced within a PHP reserved namespace (e.g. PHP::Date instead of Date or the like) while not adding more names to the list of illegal names. And even then I would prefer no restriction and give the programmers full freedom of naming within their namespace. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces and __autoload()
Jochem Maas wrote:
Dmitry Stogov wrote:
This is an implementation of Stas idea.
1) Look for existent class in current namespace
2) Look for existent internal class
3) Try to autoload class from current namespace
both ways have a wtf factor in that class with names
matching 'internal' class names behave differently.
afaict you would not be able to autoload class Exception
from within namespace Foo in the example below.
currently one cannot create classes named the same as
'internal' classes ... obviously.
I would consider making internal class names illegal
in namespaces. this would be consistent simple and clear.
If this happens, namespaces will be useless, and we'll be forced to use
_ in all classnames again to avoid potential conflicts with internal
classes.
also I don't see what would be gained from being allowed
to do:
?php
namespace Foo;
class Exception extends Exception {};
That looks awful :).
This should be:
class Exception extends ::Exception {}
Anything else does not strike me as good coding practice.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces and __autoload()
Stanislav Malyshev wrote:
?php
namespace Foo;
throw new Exception;
In this case PHP first looks for Foo::Exception and only then for
internal
Exception, but the first lookup may call __autoload (or corresponding SPL
functions) and it can emit error or throw exception.
The patch provides an additional boolean argument to __autoload() that
say
if class is really required. In case if it false, user code shouldn't
emit
errors or throw exceptions.
There's two problems here:
1. On each access to internal class, like Exception, SPL classes,
DateTime, reflection classes, etc. - we'd have call to autoload and
subsequent disk access, maybe more than one if we have include path.
Performance of it would be awful.
This is a problem, agreed.
2. All libraries having autoloaders would have to rewrite them to
support the new mode.
This is not an issue - won't they have to support
Class::Names::Like::This anyways? Backwards compatibility has already
been broken.
I would propose different solution. When we have unresolved unqualified
name, we do the following:
1. Check if we already know such class in namespace at compile-time. If
so, it's resolved.
2. If not, will be resolved at run-time.
3. At run-time, check if we know such class in namespace now. If yes,
it's resolved.
4. If not, check if we know internal class with such name. If yes, it's
resolved to internal class.
5. If not, try to autoload this class. If autoloading fails, it's the
undefined class error.
The problem is that with this autoload technique this code now throws an
Exception rather than a Foo::Exception:
Foo/Exception.php:
?php
namespace Foo;
class Exception extends ::Exception {}
?
Foo/Something.php:
?php
namespace Foo;
function __autoload($class)
{
include str_replace('::', '/', $class) . '.php';
}
class Something
{
function __construct($param)
{
if ($param == 3) {
throw new Exception('oops');
}
}
}
$a = new Something(3);
?
This would mean that all naming conflicts with internal classes must
have a different import or be fully qualified.
However, I wonder if using an import would be a clever way to get around
the problem?
Foo/Something.php:
?php
namespace Foo;
import Foo::Exception;
function __autoload($class)
{
include str_replace('::', '/', $class) . '.php';
}
class Something
{
function __construct($param)
{
if ($param == 3) {
throw new Exception('oops');
}
}
}
$a = new Something(3);
?
As I understand it, this would make the file act as if we had written it
like:
Foo/Something.php:
?php
function __autoload($class)
{
include str_replace('::', '/', $class) . '.php';
}
class Foo::Something
{
function __construct($param)
{
if ($param == 3) {
throw new Foo::Exception('oops');
}
}
}
$a = new Foo::Something(3);
?
If this is indeed the case, then it would satisfy my concerns with the
patch and would simply be up to the documentation team to document this
gotcha.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespaces and __autoload()
The problem is that with this autoload technique this code now throws an Exception rather than a Foo::Exception: Yep, unless you do require 'Foo/Exception.php'. Yes, I know it's not as nice as it might be. But the alternative is either use :: always or say goodbye to performance. However, I wonder if using an import would be a clever way to get around the problem? It would solve the issue too, of course. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: Re: [PHP-DEV] What should be in 5.3?
I think we're still far away from a working garbage collector which is production quality. At least last time we were discussing it. This should still remain a PHP 6 item if we can actually make it works in an acceptable way. Andi -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Bergmann Sent: Monday, August 27, 2007 3:37 AM To: internals@lists.php.net Subject: Re: [PHP-DEV] What should be in 5.3? Lukas Kahwe Smith schrieb: [...] - New Garbage Collector (GSoC) - Late Static Binding -- Sebastian Bergmann http://sebastian- bergmann.de/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
