Hi.
Looking on "Feature/Change Request", i have seen curious things, and i
think that them should issue any error message. See above.
Bug #39915 - Trying to access the index of an integer should throw a
warning:
Actual result:
$a = 1234;
$a[0]; // Not shows error
Proposed:
- Shows error message (Fatal error, as happens with objects) for
integer and float variables.
http://felipe.ath.cx/diff/bug39915.diff
Bug #42852 - Inconsistent message when creating default object from
empty value:
Actual result:
$obj1->p = 1; // Shows 'Strict Standards ...'
$obj2->p[] = 1; // Not shows
$a = 1;
$obj3->p = &$a; // Not shows
Proposed:
- 'Strict Standards' for all cases.
http://felipe.ath.cx/diff/bug42852.diff
--
Regards,
Felipe Pena.
2008/2/19, Felipe Pena felipensp@gmail.com:
Proposed:
- Shows error message (Fatal error, as happens with objects) for
integer and float variables.
http://felipe.ath.cx/diff/bug39915.diff
+1 , fatal error for consistency.
Proposed:
- 'Strict Standards' for all cases.
http://felipe.ath.cx/diff/bug42852.diff
I would make that message an E_NOTICE or E_WARNING.
2008/2/19, Cristian Rodriguez judas.iscariote@gmail.com:
2008/2/19, Felipe Pena felipensp@gmail.com:
Proposed:
- Shows error message (Fatal error, as happens with objects) for
integer and float variables.
http://felipe.ath.cx/diff/bug39915.diff+1 , fatal error for consistency.
you need to handle offset of booleans too..
<?php
$foo = true;
var_dump($foo[1]);
?>
Index: Zend/zend_execute.c
RCS file: /repository/ZendEngine2/zend_execute.c,v
retrieving revision 1.716.2.12.2.24.2.20
diff -u -p -r1.716.2.12.2.24.2.20 zend_execute.c
--- Zend/zend_execute.c 18 Feb 2008 12:11:47 -0000 1.716.2.12.2.24.2.20
+++ Zend/zend_execute.c 19 Feb 2008 04:22:41 -0000
@@ -1229,6 +1229,15 @@ static void zend_fetch_dimension_address
}
return;
break;
-
case IS_LONG: -
zend_error_noreturn(E_ERROR, "Cannot use
integer as array");
-
/* break intentionally missing */ -
case IS_DOUBLE: -
zend_error_noreturn(E_ERROR, "Cannot use float
as array");
-
/* break intentionally missing */ -
case IS_BOOL: -
zend_error_noreturn(E_ERROR, "Cannot use
boolean as array");
-
/* break intentionally missing */ default: if (result) {
Hello Felipe,
Tuesday, February 19, 2008, 4:21:20 AM, you wrote:
Hi.
Looking on "Feature/Change Request", i have seen curious things, and i
think that them should issue any error message. See above.
Bug #39915 - Trying to access the index of an integer should throw a
warning:
Actual result:
$a = 1234;
$a[0]; // Not shows error
Proposed:
- Shows error message (Fatal error, as happens with objects) for
integer and float variables.
http://felipe.ath.cx/diff/bug39915.diff
This patch results in two error message for type long, one complaining about
long, one about double. You can use function zend_get_type_by_const() to
avoid this. Also make sure that we see the new style message for type bool
and anything else that is not handled right now (aka just use default case).
Bug #42852 - Inconsistent message when creating default object from
empty value:
Actual result:
$obj1->p = 1; // Shows 'Strict Standards ...'
$obj2->p[] = 1; // Not shows
$a = 1;
$obj3->p = &$a; // Not shows
Proposed:
- 'Strict Standards' for all cases.
http://felipe.ath.cx/diff/bug42852.diff
Looks good.
Best regards,
Marcus
Em Ter, 2008-02-19 às 12:28 +0100, Marcus Boerger escreveu:
This patch results in two error message for type long, one complaining about
long, one about double. You can use function zend_get_type_by_const() to
avoid this. Also make sure that we see the new style message for type bool
and anything else that is not handled right now (aka just use default case).
Ooops, I forget that! :D
Here's: http://felipe.ath.cx/diff/bug39915.diff
Em Ter, 2008-02-19 às 01:25 -0300, Cristian Rodriguez escreveu:
you need to handle offset of booleans too..
Oops! Thanks.
... I was sleepy :P
2008/2/19, Felipe Pena felipensp@gmail.com:
Em Ter, 2008-02-19 às 01:25 -0300, Cristian Rodriguez escreveu:
you need to handle offset of booleans too..
Oops! Thanks.
There is a similar case with unset() an offset of booleans and integers.
<?php
$foo = true:
/* should throw a fatal error, like it does when trying to unset string offsets.
actually $foo remains unchanged after unset() (!!)
unset($foo[0]);
Index: Zend/zend_vm_def.h
RCS file: /repository/ZendEngine2/zend_vm_def.h,v
retrieving revision 1.59.2.29.2.48.2.36
diff -u -p -r1.59.2.29.2.48.2.36 zend_vm_def.h
--- Zend/zend_vm_def.h 11 Feb 2008 15:46:10 -0000 1.59.2.29.2.48.2.36
+++ Zend/zend_vm_def.h 19 Feb 2008 14:32:18 -0000
@@ -3281,6 +3281,7 @@ ZEND_VM_HANDLER(75, ZEND_UNSET_DIM, VAR|
zend_error_noreturn(E_ERROR, "Cannot
unset string offsets");
ZEND_VM_CONTINUE(); /* bailed out before */
default:
-
zend_error_noreturn(E_ERROR, "Cannot
unset %s offsets", zend_get_type_by_const(Z_TYPE_PP(container)));
FREE_OP2();
break;
}
2008/2/19, Cristian Rodriguez judas.iscariote@gmail.com:
There is a similar case with unset() an offset of booleans and integers.
<?php
$foo = true:
/* should throw a fatal error, like it does when trying to unset string
offsets.
actually $foo remains unchanged after unset() (!!)
unset($foo[0]);Index: Zend/zend_vm_def.h
RCS file: /repository/ZendEngine2/zend_vm_def.h,v
retrieving revision 1.59.2.29.2.48.2.36
diff -u -p -r1.59.2.29.2.48.2.36 zend_vm_def.h
--- Zend/zend_vm_def.h 11 Feb 2008 15:46:10 -0000
1.59.2.29.2.48.2.36
+++ Zend/zend_vm_def.h 19 Feb 2008 14:32:18 -0000
@@ -3281,6 +3281,7 @@ ZEND_VM_HANDLER(75, ZEND_UNSET_DIM, VAR|
zend_error_noreturn(E_ERROR, "Cannot
unset string offsets");
ZEND_VM_CONTINUE(); /* bailed out before
*/
default:
zend_error_noreturn(E_ERROR, "Cannotunset %s offsets", zend_get_type_by_const(Z_TYPE_PP(container)));
FREE_OP2();
break;
}
Added!
I have updated the patch, because the bool variables (used internally on
foreach, list(.., ..) = each(...), for example) are passed also to
zend_fetch_dimension_address_read(), what break the previous patch (default:
zend_error...) Then, i think that this could be handled in zend_vm_def.h,
checking for OP1_TYPE != IS_VAR when the type is boolean.
Well, i don't know how the Zend Engine works properly... So, If i said
anything wrong, let me know, please.
Finally, this was my suggestion.
http://felipe.ath.cx/diff/bug39915.diff
Thanks.