Bug #16480 Updated: strings should remember whether they are magic_quoted, htmlized or neither
ID: 16480
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Open
Bug Type: Feature/Change Request
Operating System: any
-PHP Version: 4.1.2
+PHP Version: 4.3.0
New Comment:
Bogus? BOGUS?!?! Whaddaya mean, bogus?! I'm offended!
;-) OK, I'm not. But Bugzilla's WONTFIX is certainly much more polite,
though just as disappointing.
Anyway, as the saying goes, talk is cheap but code is free. (Of course,
not all code is free and some talk can get you into prison...) Well,
the saying doesn't mention code, but after all, we're extending
languages, aren't we?
OK, I'm getting to the point. You can download the patch at:
http://nebuchadnezzar.zion.cz/php_strings.php
Try it, test it, read what I have to say about it, perhaps even use it,
make an opinion and tell me what it is! Just don't forget it's early
alpha, nearly untested code.
Sniper, why do you want to remove magic_quotes _and_ not implement
string types? That's cruel!
Is it a definitive and shared opinion that This feature is not the way
to go.? Has there been any debate? (Sorry, I'm not subscribed to the
mailing lists.) What do the other developers think? Have you even
seriously considered it?
Previous Comments:
[2002-04-19 11:20:40] [EMAIL PROTECTED]
Real solution is to remove those magic_* options altogether.
And write your code using the addslashes(), etc.
This feature is not the way to go.
[2002-04-09 13:42:45] [EMAIL PROTECTED]
Clarification: to preserve backward compatibility, string literals
without a string type specification would have an undefined or
unknown type and PHP wouldn't do any automatic conversion on them.
This makes it necessary to add a type specifier for normal,
non-escaped, non-HTMLized strings: n... or (NormalString)..., or
perhaps (PlainString)
[2002-04-07 19:09:06] [EMAIL PROTECTED]
Idea: any string should know whether AddSlashes (or magic quotes) or
HtmlSpecialChars or neither has been applied to it. Then you could have
functions declare what kind of string they expect as parameters and
what kind of string they return, and PHP would automatically do the
conversion. When writing string literals, one could indicate the type
by prepending a letter: q... for magic-quoted (or s... for added
slashes, which is the same), and h... for HTMLized string. When
including variables in a string literal, PHP would convert them, if
necessary, to the same string type as the literal. Then you could
write:
mysql_query(qINSERT INTO table VALUES('$var'));
and PHP would do the right thing regardless of whether $var has the
quotes escaped or not, because it would _know_ if it has, and escape
them if it has not.
The example for HTMLized string goes like this:
echo hINPUT TYPE=HIDDEN NAME=whatever VALUE=\$var\;
Of course, PHP would also have to correctly handle string
concatenations etc. - when you join several strings of different kinds,
it should convert all of them to the kind of the first one...
If you don't like the q... syntax, the same could be done with
typecasting: (EscapedString)... and (HTMLizedString)... - in fact,
it's probably better, because that way you could typecast any strings
(or any values, in fact), not just string literals.
I think it is a problem that now the behaviour of applications is
seriously dependent on PHP's configuration of magic_quotes - this would
solve it! (I.e. now, when I write a script that expects magic_quotes
on, it will have serious security holes when run with magic_quotes
off!)
Wow, isn't that a brilliant idea! ;-) (You can't expect praise from
anyone but yourself.)
--
Edit this bug report at http://bugs.php.net/?id=16480edit=1
Bug #16480 Updated: strings should remember whether they are magic_quoted, htmlized or neither
ID: 16480
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: any
PHP Version: 4.1.2
New Comment:
Clarification: to preserve backward compatibility, string literals
without a string type specification would have an undefined or
unknown type and PHP wouldn't do any automatic conversion on them.
This makes it necessary to add a type specifier for normal,
non-escaped, non-HTMLized strings: n... or (NormalString)..., or
perhaps (PlainString)
Previous Comments:
[2002-04-07 19:09:06] [EMAIL PROTECTED]
Idea: any string should know whether AddSlashes (or magic quotes) or
HtmlSpecialChars or neither has been applied to it. Then you could have
functions declare what kind of string they expect as parameters and
what kind of string they return, and PHP would automatically do the
conversion. When writing string literals, one could indicate the type
by prepending a letter: q... for magic-quoted (or s... for added
slashes, which is the same), and h... for HTMLized string. When
including variables in a string literal, PHP would convert them, if
necessary, to the same string type as the literal. Then you could
write:
mysql_query(qINSERT INTO table VALUES('$var'));
and PHP would do the right thing regardless of whether $var has the
quotes escaped or not, because it would _know_ if it has, and escape
them if it has not.
The example for HTMLized string goes like this:
echo hINPUT TYPE=HIDDEN NAME=whatever VALUE=\$var\;
Of course, PHP would also have to correctly handle string
concatenations etc. - when you join several strings of different kinds,
it should convert all of them to the kind of the first one...
If you don't like the q... syntax, the same could be done with
typecasting: (EscapedString)... and (HTMLizedString)... - in fact,
it's probably better, because that way you could typecast any strings
(or any values, in fact), not just string literals.
I think it is a problem that now the behaviour of applications is
seriously dependent on PHP's configuration of magic_quotes - this would
solve it! (I.e. now, when I write a script that expects magic_quotes
on, it will have serious security holes when run with magic_quotes
off!)
Wow, isn't that a brilliant idea! ;-) (You can't expect praise from
anyone but yourself.)
--
Edit this bug report at http://bugs.php.net/?id=16480edit=1
Bug #16479 Updated: var declaration in class has no meaning?
ID: 16479 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Documentation problem Operating System: Win98SE PHP Version: 4.0.6 New Comment: Yeah, I guess I asked for it. But then I'd have to argue that the var declaration itself is against the nature of PHP! Firstly because it's a declaration, and secondly because it's useless. Anyway, I understand that there will be major changes in OOP in ZendEngine2, so this is probably not relevant anymore. BTW, when is this ZE2 scheduled to launch? Will it be already in 4.2.0 which is now in RC stage? Previous Comments: [2002-04-08 01:29:14] [EMAIL PROTECTED] Well, you have get_class_vars() which can retrieve all the default properties (i.e. the ones declared with 'var $foo'). And your last suggestions is against the nature of PHP. You just do not have to declare variables to use it. Making this a doc problem though I'm not quite sure; letting the doc team decide. [2002-04-07 18:31:55] [EMAIL PROTECTED] I am not sure whether this is a bug, a feature, or lack of a feature. Perhaps this should be marked a Feature Request then... Anyway, here goes: the var declaration in a class seems to have no meaning whatsoever, except perhaps for documentation purposes. PHP allows me to assign to class variables that weren't declared without even a warning at the highest warning reporting level. That's actually not very surprising since PHP doesn't otherwise have declarations of variables, but what is then the meaning of var in classes? I suggest that PHP should at least warn about class variables that weren't declared. -- Edit this bug report at http://bugs.php.net/?id=16479edit=1
Bug #15663 Updated: add foreach reference values
ID: 15663
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type:Feature/Change Request
PHP Version: 4.1.1
Assigned To: derick
New Comment:
Can I expect this anytime soon, please?
And what is ZendEngine2 - is it what will be in 4.2.0? I haven't
found any information on what will be in 4.2.0. Is it anywhere on the
website? Thanks.
Previous Comments:
[2002-02-21 20:37:34] [EMAIL PROTECTED]
Don't close, it does apply to arrays.
[2002-02-21 20:21:11] [EMAIL PROTECTED]
This bug has been fixed in CVS.
ZendEngine2 uses handle for object.
[2002-02-21 17:20:05] [EMAIL PROTECTED]
Objects are bad examples as they will completely change how they behave
in ZE2. However, it is true for normal arrays and it's in the TODO list
of PHP:
Zend
* allow foreach ($array as $k = $val) syntax. right now we cannot
traverse an array without copying each element.
[2002-02-21 12:34:00] [EMAIL PROTECTED]
Just a small request that could be fairly useful.
Say you have an array of objects, $objects. Right now, doing:
foreach ($objects as $obj) {
$obj-something();
}
will create a copy of each object (using unnecessary memory) and call
something() on the copy, not the actual object (which is bad if it's a
mutator function of that class).
The best way to do it now is to do:
foreach (array_keys($objects) as $key) {
$objects[$key]-something();
}
but it would be very cool if php had the syntax:
foreach ($objects as $obj)
where it would create $obj as a reference to each object.
thanks
--
Edit this bug report at http://bugs.php.net/?id=15663edit=1
Bug #16479: var declaration in class has no meaning?
From: [EMAIL PROTECTED] Operating system: Win98SE PHP version: 4.0.6 PHP Bug Type: Class/Object related Bug description: var declaration in class has no meaning? I am not sure whether this is a bug, a feature, or lack of a feature. Perhaps this should be marked a Feature Request then... Anyway, here goes: the var declaration in a class seems to have no meaning whatsoever, except perhaps for documentation purposes. PHP allows me to assign to class variables that weren't declared without even a warning at the highest warning reporting level. That's actually not very surprising since PHP doesn't otherwise have declarations of variables, but what is then the meaning of var in classes? I suggest that PHP should at least warn about class variables that weren't declared. -- Edit bug report at http://bugs.php.net/?id=16479edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16479r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16479r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16479r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16479r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16479r=support Expected behavior: http://bugs.php.net/fix.php?id=16479r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16479r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16479r=submittedtwice
Bug #16480: strings should remember whether they are magic_quoted, htmlized or neither
From: [EMAIL PROTECTED]
Operating system: any
PHP version: 4.1.2
PHP Bug Type: Feature/Change Request
Bug description: strings should remember whether they are magic_quoted, htmlized or
neither
Idea: any string should know whether AddSlashes (or magic quotes) or
HtmlSpecialChars or neither has been applied to it. Then you could have
functions declare what kind of string they expect as parameters and what
kind of string they return, and PHP would automatically do the conversion.
When writing string literals, one could indicate the type by prepending a
letter: q... for magic-quoted (or s... for added slashes, which is the
same), and h... for HTMLized string. When including variables in a
string literal, PHP would convert them, if necessary, to the same string
type as the literal. Then you could write:
mysql_query(qINSERT INTO table VALUES('$var'));
and PHP would do the right thing regardless of whether $var has the quotes
escaped or not, because it would _know_ if it has, and escape them if it
has not.
The example for HTMLized string goes like this:
echo hINPUT TYPE=HIDDEN NAME=whatever VALUE=\$var\;
Of course, PHP would also have to correctly handle string concatenations
etc. - when you join several strings of different kinds, it should convert
all of them to the kind of the first one...
If you don't like the q... syntax, the same could be done with
typecasting: (EscapedString)... and (HTMLizedString)... - in fact,
it's probably better, because that way you could typecast any strings (or
any values, in fact), not just string literals.
I think it is a problem that now the behaviour of applications is
seriously dependent on PHP's configuration of magic_quotes - this would
solve it! (I.e. now, when I write a script that expects magic_quotes on,
it will have serious security holes when run with magic_quotes off!)
Wow, isn't that a brilliant idea! ;-) (You can't expect praise from anyone
but yourself.)
--
Edit bug report at http://bugs.php.net/?id=16480edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=16480r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=16480r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=16480r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=16480r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=16480r=support
Expected behavior: http://bugs.php.net/fix.php?id=16480r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=16480r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=16480r=submittedtwice
