[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/standard array.c
Ilia Alshanetsky wrote:
I've discussed this issue with Andrei at least a month ago (if not
longer) when the patch was originally added, and I believe that the
introduced behavior is the correct one.
IMO correct or not depends on the context where the function is used.
At least, as array_unique() was not capable of dealing with objects
before the Andrei's patch, every existing code should use it with
strings, not objects.
If SORT_REGULAR could handle objects as well as strings in the same
manner as SORT_STRING I wouldn't see any problem, although it cannot.
Moriyoshi
On 14-Feb-09, at 9:12 PM, Moriyoshi Koizumi wrote:
So, what are RM's thoughts on this? My points are:
1. Making SORT_REGULAR default *actually* broke existing code.
2. Adding the second argument addressed the problem enough that the
elements are treated indifferently when used with objects.
Regards,
Moriyoshi
Moriyoshi Koizumi wrote:
Whatever reasoning, I don't think it's a good idea to revert someone
else's patch before discussing anything.
Aside from this, I agree with you the old behavior is that stupid, but
BC should always be honored.
Moriyoshi
Andrei Zmievski wrote:
Don't do this please. Why did you feel the need to go back and
change my
patch including the NEWS entry? I knew what I was doing when I set the
default behavior to SORT_REGULAR and this was discussed with both 5.3
and 5.2 RMs. With your change it'l back to the stupid old behavior of:
$array = array(new stdClass(), new stdClass(), new Foo());
$array = array_unique($array);
And now $array has only 1 element. I really hate having tell PHP not to
be stupid, rather than having it default to being smart.
I'm going to revert this.
-Andrei
Moriyoshi Koizumi wrote:
moriyoshiThu Feb 12 18:29:15 2009 UTC
Modified files: /php-src/ext/standardarray.c
Log:
* Fix bug #47370 (BC breakage of array_unique())
http://cvs.php.net/viewvc.cgi/php-src/ext/standard/array.c?r1=1.471r2=1.472diff_format=u
Index: php-src/ext/standard/array.c
diff -u php-src/ext/standard/array.c:1.471
php-src/ext/standard/array.c:1.472
--- php-src/ext/standard/array.c:1.471Mon Feb 9 10:47:19 2009
+++ php-src/ext/standard/array.cThu Feb 12 18:29:15 2009
@@ -21,7 +21,7 @@
+--+
*/
-/* $Id: array.c,v 1.471 2009/02/09 10:47:19 dmitry Exp $ */
+/* $Id: array.c,v 1.472 2009/02/12 18:29:15 moriyoshi Exp $ */
#include php.h
#include php_ini.h
@@ -2924,7 +2924,7 @@
};
struct bucketindex *arTmp, *cmpdata, *lastkept;
unsigned int i;
-long sort_type = PHP_SORT_REGULAR;
+long sort_type = PHP_SORT_STRING;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, a|l,
array, sort_type) == FAILURE) {
return;
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.3 todos
Hello shire, Thursday, February 12, 2009, 8:02:06 PM, you wrote: Lukas Kahwe Smith wrote: The following remain open and it does not seem someone is actively working in it: - PHP_5_3 missed merge from PHP_5_2 for write_func callback Seeing as I have an interest in this getting in 5_3, I'll work up a patch for this unless someone wants to speak up that they've got it. I don't have Karma to Zend though, so I'll need someone to commit for me. ;-) He there, thanks for looking into this (I sadly really cannot find much more time these days than allows me to occasionally read PHP mails). Thus I gave you karma now. If you want I can of course review your patch. Best regards thanks Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tidying up PDO tests
I've been looking into the failures on http://gcov.php.net/viewer.php?version=PHP_5_3func=tests with relation to the firebird pdo driver, and the first problem that needs to be addressed is the SQL differences in order for the different drivers to work. I'm seeing specific fixes for some drivers in the tests, but how should the fact that PDO does not handle the different SQL requirements be addressed in these generic tests? Obviously the first problem is identifying driver bugs from bugs in the tests themselves, in particular the upper/lower case 'defaults', and the use of non standard field definitions. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] towards the next 5.3 release
On 15.02.2009, at 17:18, Marcus Boerger wrote: Hello Stanislav, Friday, February 13, 2009, 7:03:30 AM, you wrote: Hi! it should actually be a hard error. As we always claim PHP follows pure IS-A relation ships. I feel very uneasy with hard errors on something that is not indeed an error preventing engine from continuing. I.e. my (personal) opinion is that if the engine can move forward, even with some assumption, it should. IMHO it's like having undefined variables, etc. It makes PHP less strict, but I'd say it's not necessarily a bad thing. Hard as in E_RECOVERABLE_ERROR of course, since you are right that the engine indeed can continue. Thats almost as useless. If you make it E_RECOVERABLE_ERROR .. it essentially prevents people from modifying the method signatures in a non academic OO manner, which I think is not the point of PHP. E_STRICT reminds people that they are doing the wrong thing in academic terms, which however might very well make sense in business terms non the less. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] int/long conflict in spl?
Hi,
While tracking down a problem in one of phar's tests, I found what might
be a problem in RecursiveDirectoryIterator's handling of flags. Here is
a crude patch demonstrating the issue, and wondering if this is
something to be concerned about. Basically, we're mixing long and int,
which could lead to truncation in unpredictable ways.
Greg
Index: spl_directory.c
===
RCS file: /repository/php-src/ext/spl/spl_directory.c,v
retrieving revision 1.45.2.27.2.23.2.40
diff -u -r1.45.2.27.2.23.2.40 spl_directory.c
--- spl_directory.c31 Dec 2008 11:15:43 -1.45.2.27.2.23.2.40
+++ spl_directory.c15 Feb 2009 21:45:00 -
@@ -215,7 +215,7 @@
/* open a directory resource */
static void spl_filesystem_dir_open(spl_filesystem_object* intern, char
*path TSRMLS_DC)
{
-int skip_dots = intern-flags SPL_FILE_DIR_SKIPDOTS;
+int skip_dots = (intern-flags SPL_FILE_DIR_SKIPDOTS) ? 1 : 0;
intern-type = SPL_FS_DIR;
intern-_path_len = strlen(path);
@@ -314,7 +314,7 @@
case SPL_FS_DIR:
spl_filesystem_dir_open(intern, source-_path TSRMLS_CC);
/* read until we hit the position in which we were before */
-skip_dots = source-flags SPL_FILE_DIR_SKIPDOTS;
+skip_dots = (source-flags SPL_FILE_DIR_SKIPDOTS) ? 1 : 0;
for(index = 0; index source-u.dir.index; ++index) {
do {
spl_filesystem_dir_read(intern TSRMLS_CC);
@@ -600,7 +600,7 @@
#define DIT_CTOR_FLAGS 0x0001
#define DIT_CTOR_GLOB 0x0002
-void spl_filesystem_object_construct(INTERNAL_FUNCTION_PARAMETERS, int
ctor_flags) /* {{{ */
+void spl_filesystem_object_construct(INTERNAL_FUNCTION_PARAMETERS, long
ctor_flags) /* {{{ */
{
spl_filesystem_object *intern;
char *path;
@@ -698,7 +698,7 @@
SPL_METHOD(DirectoryIterator, next)
{
spl_filesystem_object *intern =
(spl_filesystem_object*)zend_object_store_get_object(getThis() TSRMLS_CC);
-int skip_dots = intern-flags SPL_FILE_DIR_SKIPDOTS;
+int skip_dots = (intern-flags SPL_FILE_DIR_SKIPDOTS) ? 1 : 0;
intern-u.dir.index++;
do {
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src /main output.c /tests/output bug46900.phpt bug46903.phpt ob_014.phpt ob_015.phpt ob_start_basic_002.phpt ob_start_basic_004.phpt
Robin Fernandes wrote:
robinf Sun Dec 28 19:50:58 2008 UTC
Added files:
/php-src/tests/output bug46903.phpt bug46900.phpt
Modified files:
/php-src/tests/output ob_start_basic_004.phpt
ob_start_basic_002.phpt ob_015.phpt
ob_014.phpt
/php-src/main output.c
Log:
Fix bugs #46900 and #46903.
http://cvs.php.net/viewvc.cgi/php-src/main/output.c?r1=1.214r2=1.215diff_format=u
Index: php-src/main/output.c
diff -u php-src/main/output.c:1.214 php-src/main/output.c:1.215
--- php-src/main/output.c:1.214 Mon Aug 18 07:45:59 2008
+++ php-src/main/output.c Sun Dec 28 19:50:58 2008
@@ -19,7 +19,7 @@
+--+
*/
-/* $Id: output.c,v 1.214 2008/08/18 07:45:59 tony2001 Exp $ */
+/* $Id: output.c,v 1.215 2008/12/28 19:50:58 robinf Exp $ */
#ifndef PHP_OUTPUT_DEBUG
# define PHP_OUTPUT_DEBUG 0
@@ -1342,6 +1342,8 @@
}
if (chunk_size 0) {
chunk_size = 0;
+ } else if (chunk_size == 1) {
+ chunk_size = 4096;
}
if (SUCCESS != php_output_start_user(output_handler, chunk_size, flags
TSRMLS_CC)) {
The documentation stated IMHO silly magic behavior of the old output
layer. Why start sprinkling the new code with useless magic meanings?
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tidying up PDO tests
Hi Lester, Em Dom, 2009-02-15 às 18:31 +, Lester Caine escreveu: I've been looking into the failures on http://gcov.php.net/viewer.php?version=PHP_5_3func=tests with relation to the firebird pdo driver, and the first problem that needs to be addressed is the SQL differences in order for the different drivers to work. I'm seeing specific fixes for some drivers in the tests, but how should the fact that PDO does not handle the different SQL requirements be addressed in these generic tests? Obviously the first problem is identifying driver bugs from bugs in the tests themselves, in particular the upper/lower case 'defaults', and the use of non standard field definitions. I'm looking at this. I'll check each test and will try to be fixing the bugs as soon as possible. Please, report whatever bug that you found. :) Thanks for the heads up! -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: cvs: php-src /main output.c /tests/output bug46900.phpt bug46903.phpt ob_014.phpt ob_015.phpt ob_start_basic_002.phpt ob_start_basic_004.phpt
2009/2/15 Michael Wallner m...@php.net:
Robin Fernandes wrote:
robinf Sun Dec 28 19:50:58 2008 UTC
Added files:/php-src/tests/output bug46903.phpt
bug46900.phpt
Modified files: /php-src/tests/output
ob_start_basic_004.phpt
ob_start_basic_002.phpt ob_015.phpt
ob_014.phpt/php-src/main output.c Log:
Fix bugs #46900 and #46903.
http://cvs.php.net/viewvc.cgi/php-src/main/output.c?r1=1.214r2=1.215diff_format=u
Index: php-src/main/output.c
diff -u php-src/main/output.c:1.214 php-src/main/output.c:1.215
--- php-src/main/output.c:1.214 Mon Aug 18 07:45:59 2008
+++ php-src/main/output.c Sun Dec 28 19:50:58 2008
@@ -19,7 +19,7 @@
+--+
*/
-/* $Id: output.c,v 1.214 2008/08/18 07:45:59 tony2001 Exp $ */
+/* $Id: output.c,v 1.215 2008/12/28 19:50:58 robinf Exp $ */
#ifndef PHP_OUTPUT_DEBUG
# define PHP_OUTPUT_DEBUG 0
@@ -1342,6 +1342,8 @@
}
if (chunk_size 0) {
chunk_size = 0;
+ } else if (chunk_size == 1) {
+ chunk_size = 4096;
}
if (SUCCESS != php_output_start_user(output_handler, chunk_size,
flags TSRMLS_CC)) {
The documentation stated IMHO silly magic behavior of the old output layer.
Why start sprinkling the new code with useless magic meanings?
Hi Mike,
Fair point regarding bug 46903. In this case, I can see how
documenting a change in behaviour could be better than implementing
the currently documented behaviour - either approach is fine by me.
I'm happy to revert this and raise a doc bug instead, if that's the
right way to go.
Cheers,
Robin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
