Bug #62964 [Com]: Cross-Site Scripting
Edit report at https://bugs.php.net/bug.php?id=62964&edit=1
ID: 62964
Comment by: zyss at mail dot zp dot ua
Reported by:ymaryshev at ptsecurity dot ru
Summary:Cross-Site Scripting
Status: Open
Type: Bug
Package:*General Issues
Operating System: win
PHP Version:5.4.6
Block user comment: N
Private report: N
New Comment:
Unfortunately most of PHP output functions are vulnerable in the same way...
For example, built-in echo function:
$a = "alert('Positive')";
echo $a; // echo IS VULNERABLE!!!11oneoneeleven
Seriously, healthy programmer never allows untrusted data (user input) to be
passed to stream_filter_register() as well as to other functions.
Moreover, phpinfo() should never be exposed.
Previous Comments:
[2012-08-29 12:06:08] ymaryshev at ptsecurity dot ru
Description:
An attacker can conduct cross-site scripting attack because of incorrect
implementation of php_info_print_stream_hash function in phpinfo in PHP.
Vulnerability exists in /ext/sqlite3/ info.c file. Here is the vulnerable code:
static void php_info_print_stream_hash(const char *name, HashTable *ht
TSRMLS_DC)
/* {{{ */ {
...
while (zend_hash_get_current_key_ex(ht, &key, &len,
NULL,
0, &pos) == HASH_KEY_IS_STRING)
{
php_info_print(key);
...
Test script:
---
alert('Positive')","a");
phpinfo();
?>
--
Edit this bug report at https://bugs.php.net/bug.php?id=62964&edit=1
Bug #49859 [Com]: PHP_FCGI_CHILDREN not work
Edit report at https://bugs.php.net/bug.php?id=49859&edit=1 ID: 49859 Comment by: zyss at mail dot zp dot ua Reported by:loki5100-nospam at yahoo dot fr Summary:PHP_FCGI_CHILDREN not work Status: Not a bug Type: Bug Package:PHP options/info functions Operating System: Windows Vista PHP Version:5.3.0 Block user comment: N Private report: N New Comment: I have the same problem. We're using PHP with windows embedded. PHP just ignores this environment variable (PHP_FCGI_CHILDREN). Please reopen this bug. Previous Comments: [2012-04-04 12:12:29] strayer at olle-orks dot org I just discovered this while checking out xcache and this really doesn't work... phpinfo() even shows the env var in its output! cmd: # set PHP_FCGI_CHILDREN=5 # set PHP_FCGI_MAX_REQUESTS=3 # php-cgi -b 127.0.0.1:9000 Process Explorer shows only one process with one thread. Ran phpinfo() via browser: Environment PHP_FCGI_CHILDREN 5 PHP_FCGI_MAX_REQUESTS 3 It looks like php-cgi just ignores the PHP_FCGI_CHILDREN, since PHP_FCGI_MAX_REQUESTS seems to be working as intended. [2009-10-19 14:40:16] j...@php.net You have just set the environment variables in wrong place / wrong way. (no idea how you do that in windows, but this works just fine under *nix) [2009-10-13 08:00:52] loki5100-nospam at yahoo dot fr Description: i found a bug in PHP-cgi.exe I use Php-cgi as fastCgi php-cgi.exe -b host:port i set in environement variables this : PHP_FCGI_CHILDREN=8 PHP_FCGI_MAX_REQUESTS=1000 in the task manager i see only one Php-cgi.exe process (when normaly i must see 9 process no?) and after i send more than 1000 request the php-cgi.exe process died ! and i must manually restart it! that not a normal behavior when PHP_FCGI_CHILDREN is > 1 Reproduce code: --- set in environement variables : PHP_FCGI_CHILDREN=8 PHP_FCGI_MAX_REQUESTS=1000 exec: php-cgi.exe -b 127.0.0.1:9000 see in task manager only one Php-cgi.exe process send more than 1000 request to php-cgi.exe, the process will die and you will need to manually restart it ! Expected result: process must be restarted automatiquely Actual result: -- the main process die and you need to manually restart it ! -- Edit this bug report at https://bugs.php.net/bug.php?id=49859&edit=1
Req #62572 [Com]: Relax syntax by skipping ";" at end of line
Edit report at https://bugs.php.net/bug.php?id=62572&edit=1
ID: 62572
Comment by: zyss at mail dot zp dot ua
Reported by:thbley at gmail dot com
Summary:Relax syntax by skipping ";" at end of line
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: all
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Semicolons were invented not by stupid people...
It's interesting how would you write without semicolons the following:
from($categories)
->orderBy('$v["name"]')
->groupJoin(
from($products)
->where('$v["quantity"] > 0')
->orderByDescending('$v["quantity"]')
->thenBy('$v["name"]'),
'$v["id"]', '$v["catId"]', 'array("name" => $v["name"], "products" =>
$e)'
);
???
Previous Comments:
[2012-07-16 03:36:17] thbley at gmail dot com
Description:
old:
$txt1="Hello World!";
$txt2="What a nice day!";
echo $txt1 . " " . $txt2;
$i = 1; $j = 2; $k = 3;
function hello() { echo "hello world"; }
new:
$txt1="Hello World!"
$txt2="What a nice day!"
echo $txt1 . " " . $txt2
$i = 1; $j = 2; $k = 3
function hello() { echo "hello world" }
Test script:
---
$txt1="Hello World!"
$txt2="What a nice day!"
echo $txt1 . " " . $txt2
$i = 1; $j = 2; $k = 3
function hello() { echo "hello world" }
--
Edit this bug report at https://bugs.php.net/bug.php?id=62572&edit=1
[PHP-BUG] Bug #62583 [NEW]: socket_read(, , PHP_BINARY_READ) never ruturns FALSE when client disconnects
From: zyss at mail dot zp dot ua Operating system: Win32 PHP version: 5.3.14 Package: *General Issues Bug Type: Bug Bug description:socket_read(, , PHP_BINARY_READ) never ruturns FALSE when client disconnects Description: It seems that there is a long-lasting bug in PHP that prevents socket_read (called on a server-side socket returned from socket_accept()) to return false when TCP connection is closed (no matter how - gracefully or not). Here this bug is mention also: http://stackoverflow.com/questions/9085615/php-detecting-remote-host-disconnection Test script: --- https://github.com/zyura/PHPSrv/blob/master/tcpserver.php Expected result: socket_read() returns FALSE when client disconnects and socket_last_error() returns adequate error code. Actual result: -- when client disconnects socket_read() always return empty string '' keeping client socket forever... -- Edit bug report at https://bugs.php.net/bug.php?id=62583&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62583&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62583&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62583&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62583&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62583&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62583&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62583&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62583&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62583&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62583&r=support Expected behavior: https://bugs.php.net/fix.php?id=62583&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62583&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62583&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62583&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62583&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62583&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62583&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62583&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62583&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62583&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62583&r=mysqlcfg
Req #9654 [Com]: Add is_type() function
Edit report at https://bugs.php.net/bug.php?id=9654&edit=1
ID: 9654
Comment by: zyss at mail dot zp dot ua
Reported by:adam at cryptocomm dot com
Summary:Add is_type() function
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: *
PHP Version:*
Block user comment: N
Private report: N
New Comment:
Why not to write your own?
Note, however, that PHP is slow as mud so even a single function call costs
much and it's usually much faster to use native functions for type checking (if
you're concerned about the speed).
Also it's quite easy to mistype a type :) so using native functions is a
preferred option as to me.
http://www.example.com/";, "r");
echo 'res($f): ', is_type($f, 'res') ? 'Y' : 'N', "\n";
echo 'resource($f): ', is_type($f, 'resource') ? 'Y' : 'N', "\n";
fclose($f);
echo 'string("abc"): ', is_type('abc', 'string') ? 'Y' : 'N', "\n";
echo 'object(stdClass): ', is_type(new stdClass(), 'object') ? 'Y' : 'N', "\n";
echo 'array([1, 2, 3]): ', is_type(array(1, 2, 3), 'array') ? 'Y' : 'N', "\n";
echo 'callable(Closure): ', is_type(function() { }, 'callable') ? 'Y' : 'N',
"\n";
echo 'bool(true): ', is_type(true, 'bool') ? 'Y' : 'N', "\n";
echo 'boolean(true): ', is_type(true, 'boolean') ? 'Y' : 'N', "\n";
echo 'dir(__DIR__): ', is_type(__DIR__, 'dir') ? 'Y' : 'N', "\n";
echo 'file(__FILE__): ', is_type(__FILE__, 'file') ? 'Y' : 'N', "\n";
echo 'readable(__FILE__): ', is_type(__FILE__, 'readable') ? 'Y' : 'N', "\n";
echo 'writable(__FILE__): ', is_type(__FILE__, 'writable') ? 'Y' : 'N', "\n";
echo 'writeable(__FILE__): ', is_type(__FILE__, 'writeable') ? 'Y' : 'N', "\n";
$php = $_SERVER['argv'][0];
echo 'exec($php): ', is_type($php, 'exec') ? 'Y' : 'N', "\n";
echo 'executable($php): ', is_type($php, 'executable') ? 'Y' : 'N', "\n";
$link = __FILE__ . '.symlink';
if (function_exists('symlink'))
@symlink(__FILE__, $link);
echo 'link($link): ', is_type($link, 'link') ? 'Y' : 'N', "\n";
@unlink($link);
$upl = @$_FILES['file']['tmp_name'];
echo 'uploaded(__FILE__): ', is_type(__FILE__, 'uploaded') ? 'Y' : 'N', "\n";
echo 'uploaded_file(__FILE__): ', is_type(__FILE__, 'uploaded_file') ? 'Y' :
'N', "\n";
$client = new
SoapClient('http://graphical.weather.gov/xml/DWMLgen/wsdl/ndfdXML.wsdl',
array('exceptions' => 0));
$result = $client->SomeFunction();
echo 'soap_fault($result): ', is_type($result, 'soap_fault') ? 'Y' : 'N', "\n";
Previous Comments:
[2001-03-09 09:57:24] adam at cryptocomm dot com
It would be much more clean and
quick to consolidate all the "is"
functions into like is_type($variable, "int")
and have it return the true or false
based on if the value of $variable is
the datatype you specified as the second
paramter. This makes more sense to
me then having like 20 is_whatever functions.
--
Edit this bug report at https://bugs.php.net/bug.php?id=9654&edit=1
[PHP-BUG] Req #62029 [NEW]: Allow expressions for const
From: Operating system: All PHP version: 5.3.13 Package: *General Issues Bug Type: Feature/Change Request Bug description:Allow expressions for const Description: Currently PHP supports global constant definition using keyword const instead of ugly define() function call. The problem is that const definition doesn't allow expressions to be used to define a constant. So please implement the ability to use expressions when using const keyword. Test script: --- https://bugs.php.net/bug.php?id=62029&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62029&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62029&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62029&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62029&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62029&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62029&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62029&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62029&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62029&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62029&r=support Expected behavior: https://bugs.php.net/fix.php?id=62029&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62029&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62029&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62029&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62029&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62029&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62029&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62029&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62029&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62029&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62029&r=mysqlcfg
Req #60364 [Opn]: Implement ability to recover from fatal errors in eval()'d code
Edit report at https://bugs.php.net/bug.php?id=60364&edit=1
ID: 60364
User updated by:zyss at mail dot zp dot ua
Reported by:zyss at mail dot zp dot ua
Summary:Implement ability to recover from fatal errors in
eval()'d code
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: All
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
> This could be solved more straight forward solved by making fatal errors an
> Exception in PHP
Yes, that would be ideal (this is how Java handles missing classes and methods
and it works just fine).
PHP borrowed from Java many features (classes, interfaces, "instanceof", ...),
why not to implement one more useful thing â not to kill scripts when
something is missing?
Previous Comments:
[2011-12-20 03:46:08] hanskrentel at yahoo dot de
Why specific for eval and not include and/or overal?
This could be solved more straight forward solved by making fatal errors an
Exception in PHP, like suggested in #28331 (which names eval in a comment as a
use-case).
----
[2011-11-23 13:27:35] zyss at mail dot zp dot ua
Description:
Sometimes eval() is used as a way to execute PHP code within a shell (legal
remote access for debugging purposes) or to execute code compiled to PHP from
higher-level scripting language or the code stored in the database etc.
The common problem is that a call of non-existing function (or object
instantiation) results in termination of the whole script, not just eval'd code.
I think that it's not correct in such cases.
The obvious way to implement it would be adding flags to eval() function (as a
second argument) one of which could indicate that eval() should not terminate
the script but just return an error or raise an exception.
Such flags could be:
EVAL_FATAL_DIE// current behavior
EVAL_FATAL_ERROR // return FALSE
EVAL_FATAL_EXCEPTION // raise an exception of a predefined class (e.g.
EvalException)
Test script:
---
try {
eval('non_existing_function()', EVAL_FATAL_EXCEPTION);
}
catch (EvalException $e) {
Logger::log('Error in eval\'d code', $e);
}
Expected result:
Exception being logged and script continued its execution.
Actual result:
--
Fatal error: Call to undefined function non_existing_function() in ... :
eval()'d code(1) on line 1
--
Edit this bug report at https://bugs.php.net/bug.php?id=60364&edit=1
Req #55872 [Com]: Zero filled right-shift
Edit report at https://bugs.php.net/bug.php?id=55872&edit=1
ID: 55872
Comment by: zyss at mail dot zp dot ua
Reported by:dsnytkine at ultralogistics dot com
Summary:Zero filled right-shift
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: any
PHP Version:5.4.0beta1
Block user comment: N
Private report: N
New Comment:
You can use this function meantime (performance sucks anyway):
// 32-bit zero-filled right-shift
function zrsh($a, $n) {
if ($n <= 0) return $a;
$b = 0x8000;
return ($a >> $n) & ~($b >> ($n - 1));
}
Previous Comments:
[2011-10-08 13:27:00] dsnytkine at ultralogistics dot com
Description:
Please implement a zero-filled right-shift similar to Java and JavaScript >>>
operator. It is really useful in some situations.
--
Edit this bug report at https://bugs.php.net/bug.php?id=55872&edit=1
Req #42116 [Com]: Safe eval()
Edit report at https://bugs.php.net/bug.php?id=42116&edit=1
ID: 42116
Comment by: zyss at mail dot zp dot ua
Reported by:kripper3 at hotmail dot com
Summary:Safe eval()
Status: Open
Type: Feature/Change Request
Package:*General Issues
Operating System: Irrelevant
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
You should use arithmetic expressions parser instead of using eval() for such
purposes, IMHO.
There are tons of such parsers for PHP and nothing prevents you from writing
your own.
Exposing eval() to users is a very bad thing whatever filters are there.
Previous Comments:
[2007-07-26 20:56:47] kripper3 at hotmail dot com
Description:
eval($code) makes it possible to execute PHP code.
It becames usefull when $code is provided dynamically (by the user of the
application).
For example, in order to compute a math expression provided by the user via a
Web Interface.
A lot of applications are using eval() this way.
The problem is that eval() is not safe, and makes it possible to inject code.
For example, instead of providing a math expression, I could provide code for
listing files, get the content of the scripts and obtain hardcoded passwords.
On http://www.php.net/manual/en/function.eval.php#75389 someone proposed a
parser to detect disallowed PHP functions, but since the evaled code can be
very flexible (ie. "$a = 'un' . 'link'; $a('')"), it seems the solution
must be implemented in the engine.
In other words, there should be a secure sandbox eval() function, let's say
"save_eval()".
I guess this could be difficult to implement.
Besides, the definition of "save" may be subjective.
I would define "save" as, at least, to not allow someone to do I/O operations
(ie. read/write files, access URL's, etc.) and not access the applications code
space (ie. change $GLOBALS, $_SESSION, $_SERVER, etc).
To day, to use eval() implies a security risk in almost any app. that uses this
function. Besides, we are missing a BIG RED WARNING BOX in the documentation
page to inform our PHP users. Therefore, it is a social bug.
Related "Bug":
http://bugs.php.net/bug.php?id=40722&edit=2
IMO, it's no serious answer, since OS privileges cannot avoid reading passwords
in PHP scripts or inyecting:
$_SESSION['isAdmin'] = 'ok...let_me_hack_your_php_app')
Reproduce code:
---
eval()
or
save_eval()
Expected result:
ERROR: Evaled code cannot execute function ''
Actual result:
--
Irrelevant.
--
Edit this bug report at https://bugs.php.net/bug.php?id=42116&edit=1
[PHP-BUG] Req #60364 [NEW]: Implement ability to recover from fatal errors in eval()'d code
From:
Operating system: All
PHP version: 5.3.8
Package: *General Issues
Bug Type: Feature/Change Request
Bug description:Implement ability to recover from fatal errors in eval()'d code
Description:
Sometimes eval() is used as a way to execute PHP code within a shell (legal
remote access for debugging purposes) or to execute code compiled to PHP
from higher-level scripting language or the code stored in the database
etc.
The common problem is that a call of non-existing function (or object
instantiation) results in termination of the whole script, not just eval'd
code.
I think that it's not correct in such cases.
The obvious way to implement it would be adding flags to eval() function
(as a second argument) one of which could indicate that eval() should not
terminate the script but just return an error or raise an exception.
Such flags could be:
EVAL_FATAL_DIE// current behavior
EVAL_FATAL_ERROR // return FALSE
EVAL_FATAL_EXCEPTION // raise an exception of a predefined class (e.g.
EvalException)
Test script:
---
try {
eval('non_existing_function()', EVAL_FATAL_EXCEPTION);
}
catch (EvalException $e) {
Logger::log('Error in eval\'d code', $e);
}
Expected result:
Exception being logged and script continued its execution.
Actual result:
--
Fatal error: Call to undefined function non_existing_function() in ... :
eval()'d code(1) on line 1
--
Edit bug report at https://bugs.php.net/bug.php?id=60364&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60364&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60364&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60364&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60364&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60364&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60364&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60364&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60364&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60364&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60364&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60364&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60364&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60364&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60364&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60364&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60364&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60364&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60364&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60364&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60364&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60364&r=mysqlcfg
#48278 [Bgs]: $ variable prefix is unneeded in most cases
ID: 48278
User updated by: zyss at mail dot zp dot ua
Reported By: zyss at mail dot zp dot ua
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5.2.9
New Comment:
It is just one of arguments, another one is that it will improve code
readability. While it is not so evident in simple examples: who cares
what to write
$foo = $bar
or
foo = bar
and all of these seems to be clear and readable. But consider more
complicated code:
while (TRUE) {
$k = strpos( $sql, $quoteChar, $j );
$escaped = false;
if ($k === false) {
break;
}
$l = $k - 1;
while ($l >= 0 && $sql{$l} == '\\') {
$l--;
$escaped = !$escaped;
}
if ($escaped) {
$j = $k + 1;
continue;
}
break;
}
Isn't it more readable without $:
while (TRUE) {
k = strpos( sql, quoteChar, j );
escaped = false;
if (k === false) {
break;
}
l = k - 1;
while (l >= 0 && sql{l} == '\\') {
l--;
escaped = !escaped;
}
if (escaped) {
j = k + 1;
continue;
}
break;
}
?
Previous Comments:
[2009-05-14 22:06:04] ras...@php.net
Minimizing keystrokes never has and never will be a priority.
----------------
[2009-05-14 22:01:10] zyss at mail dot zp dot ua
It is a matter of programmer's personal attentiveness. In your example
there is a mix of using $ and not using it. Most developers will not do
it. Besides in other languages this theoretical problem is even not
discussed. For example, as you know in C/C++ there is a de facto
standard of using CAPITAL LETTERS for constants which is enough to
distinguish them from variables. Many PHP developers follow this
concept.
>From the other side if one wanted to calculate how many key strokes
will it save to allow not to use $ prefix in a PHP project with 10
lines of code - this number would be huge. No one will argue that PHP is
derived from C. It is evident that C language itself was created to
minimize typing (as one of its primary goals, comparing to academic
Pascal is enough to see this). So why not to follow the original path -
to avoid unneeded typing while leaving a possibility to use $ for
compatibility and in some special cases?
The same arguments can be applied to { } arrays and "in" operator.
[2009-05-14 19:59:52] ras...@php.net
There are also edge cases like
$a['foo'] = 1;
$foo = 2;
echo $a[foo];
That would behave differently with optional $'s
And I like the obvious separation between constants and variables. It
avoids side-effects if someone somewhere suddenly creates a constant
that then goes and changes behaviour all over the place because of this
constants-over-variables approach.
--------------------
[2009-05-14 19:43:25] zyss at mail dot zp dot ua
It will not break stuff if defined constants will have higher priority.
In such case developer can just leave $ prefix.
It would be really great if PHP developers have an option to choose
whether to use the prefix or not. Eventually all new code will be
written without $ and there will be no conflicts.
[2009-05-14 18:24:04] ras...@php.net
And it will most definitely break stuff since removing the $ would
clash with any defined constants.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/48278
--
Edit this bug report at http://bugs.php.net/?id=48278&edit=1
#48278 [Bgs]: $ variable prefix is unneeded in most cases
ID: 48278
User updated by: zyss at mail dot zp dot ua
Reported By: zyss at mail dot zp dot ua
Status: Bogus
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5.2.9
New Comment:
It is a matter of programmer's personal attentiveness. In your example
there is a mix of using $ and not using it. Most developers will not do
it. Besides in other languages this theoretical problem is even not
discussed. For example, as you know in C/C++ there is a de facto
standard of using CAPITAL LETTERS for constants which is enough to
distinguish them from variables. Many PHP developers follow this
concept.
>From the other side if one wanted to calculate how many key strokes
will it save to allow not to use $ prefix in a PHP project with 10
lines of code - this number would be huge. No one will argue that PHP is
derived from C. It is evident that C language itself was created to
minimize typing (as one of its primary goals, comparing to academic
Pascal is enough to see this). So why not to follow the original path -
to avoid unneeded typing while leaving a possibility to use $ for
compatibility and in some special cases?
The same arguments can be applied to { } arrays and "in" operator.
Previous Comments:
[2009-05-14 19:59:52] ras...@php.net
There are also edge cases like
$a['foo'] = 1;
$foo = 2;
echo $a[foo];
That would behave differently with optional $'s
And I like the obvious separation between constants and variables. It
avoids side-effects if someone somewhere suddenly creates a constant
that then goes and changes behaviour all over the place because of this
constants-over-variables approach.
--------
[2009-05-14 19:43:25] zyss at mail dot zp dot ua
It will not break stuff if defined constants will have higher priority.
In such case developer can just leave $ prefix.
It would be really great if PHP developers have an option to choose
whether to use the prefix or not. Eventually all new code will be
written without $ and there will be no conflicts.
[2009-05-14 18:24:04] ras...@php.net
And it will most definitely break stuff since removing the $ would
clash with any defined constants.
[2009-05-14 11:07:12] scott...@php.net
Fork away, it is open source after all.
--------
[2009-05-14 09:04:20] zyss at mail dot zp dot ua
Description:
$ character is one of the most widely used in PHP code, in most cases
its use is unreasonable. I understand its historical roots, it came from
Unix shell scripts (such as bash) where it was required to make
interpreters "life" easier. But today's most powerful languages do not
require use of variable prefix to distinguish between variable and other
identifiers.
There are some cases where use of $ if reasonable, for example inside
strings and when calling function by name stored in a variable. In all
other cases programmers are dazzled by it.
I do not propose to remove $ prefix, it would be a major improvement to
make it OPTIONAL (this change will not break any existing code but many
people will breathe a sigh of relief).
P.S. If you will continue to prefer PHP-interpreter developers'
convenience over PHP-code developers' we will start our own fork of PHP
to be able to add required functionality to it.
--
Edit this bug report at http://bugs.php.net/?id=48278&edit=1
#48278 [Bgs]: $ variable prefix is unneeded in most cases
ID: 48278 User updated by: zyss at mail dot zp dot ua Reported By: zyss at mail dot zp dot ua Status: Bogus Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5.2.9 New Comment: It will not break stuff if defined constants will have higher priority. In such case developer can just leave $ prefix. It would be really great if PHP developers have an option to choose whether to use the prefix or not. Eventually all new code will be written without $ and there will be no conflicts. Previous Comments: [2009-05-14 18:24:04] ras...@php.net And it will most definitely break stuff since removing the $ would clash with any defined constants. [2009-05-14 11:07:12] scott...@php.net Fork away, it is open source after all. [2009-05-14 09:04:20] zyss at mail dot zp dot ua Description: $ character is one of the most widely used in PHP code, in most cases its use is unreasonable. I understand its historical roots, it came from Unix shell scripts (such as bash) where it was required to make interpreters "life" easier. But today's most powerful languages do not require use of variable prefix to distinguish between variable and other identifiers. There are some cases where use of $ if reasonable, for example inside strings and when calling function by name stored in a variable. In all other cases programmers are dazzled by it. I do not propose to remove $ prefix, it would be a major improvement to make it OPTIONAL (this change will not break any existing code but many people will breathe a sigh of relief). P.S. If you will continue to prefer PHP-interpreter developers' convenience over PHP-code developers' we will start our own fork of PHP to be able to add required functionality to it. -- Edit this bug report at http://bugs.php.net/?id=48278&edit=1
#48278 [NEW]: $ variable prefix is unneeded in most cases
From: zyss at mail dot zp dot ua Operating system: Irrelevant PHP version: 5.2.9 PHP Bug Type: Feature/Change Request Bug description: $ variable prefix is unneeded in most cases Description: $ character is one of the most widely used in PHP code, in most cases its use is unreasonable. I understand its historical roots, it came from Unix shell scripts (such as bash) where it was required to make interpreters "life" easier. But today's most powerful languages do not require use of variable prefix to distinguish between variable and other identifiers. There are some cases where use of $ if reasonable, for example inside strings and when calling function by name stored in a variable. In all other cases programmers are dazzled by it. I do not propose to remove $ prefix, it would be a major improvement to make it OPTIONAL (this change will not break any existing code but many people will breathe a sigh of relief). P.S. If you will continue to prefer PHP-interpreter developers' convenience over PHP-code developers' we will start our own fork of PHP to be able to add required functionality to it. -- Edit bug report at http://bugs.php.net/?id=48278&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48278&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48278&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48278&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48278&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48278&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48278&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48278&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48278&r=needscript Try newer version: http://bugs.php.net/fix.php?id=48278&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48278&r=support Expected behavior: http://bugs.php.net/fix.php?id=48278&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48278&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48278&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48278&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48278&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48278&r=dst IIS Stability: http://bugs.php.net/fix.php?id=48278&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48278&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48278&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48278&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48278&r=mysqlcfg
#48268 [NEW]: Special case of a function with single array argument
From: zyss at mail dot zp dot ua
Operating system: Irrelevant
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: Special case of a function with single array argument
Description:
I propose to add a special syntax (simplification) for a function declared
with just one argument. The idea is to remove array with its brackets ( )
in the function call to improve readability and get rid of unneeded array
keyword. This feature is expected by many people who use such type of
functions as a replacement of the PHP's missing feature to specify
function's arguments by name.
For example:
function setParams(array $params) { /*...*/ }
Current call:
setParams(array('name' => 'foo', 'width' => 300, 'height' => 150));
Proposed call:
setParams('name' => 'foo', 'width' => 300, 'height' => 150);
--
Edit bug report at http://bugs.php.net/?id=48268&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48268&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48268&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48268&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48268&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48268&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48268&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48268&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48268&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48268&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48268&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48268&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48268&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48268&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48268&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48268&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48268&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48268&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48268&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48268&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48268&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48268&r=mysqlcfg
#48267 [NEW]: new "in" keyword as an alias of array_search
From: zyss at mail dot zp dot ua
Operating system: Irrelevant
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: new "in" keyword as an alias of array_search
Description:
Please add new keyword "in" to improve readability of a PHP code that is
an inline alias to array_search function.
For example:
if (array_search($item, $array)) { ... }
would be:
if ($item in $array) { ... }
Another example:
if (array_search($item, array('first', 'second', 'third'))) { ... }
would be:
if ($item in array('first', 'second', 'third')) { ... }
or ideally:
if ($item in {'first', 'second', 'third'}) { ... }
--
Edit bug report at http://bugs.php.net/?id=48267&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48267&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48267&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48267&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48267&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48267&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48267&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48267&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48267&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48267&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48267&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48267&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48267&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48267&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48267&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48267&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48267&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48267&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48267&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48267&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48267&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48267&r=mysqlcfg
#48266 [NEW]: shorthand for array keryword
From: zyss at mail dot zp dot ua
Operating system: Irrelevant
PHP version: 5.2.9
PHP Bug Type: Feature/Change Request
Bug description: shorthand for array keryword
Description:
One of the most frequently used keywords in PHP is "array".
It would be great to adopt just another construct from C/C++, namely array
constructor using curly brackets { }.
These are cases when PHP code is oversaturated with "array" word.
In this way it would be much easier to write and read PHP code.
I am aware of case #3928 and http://wiki.php.net/rfc/shortsyntaxforarrays,
but I think that curly brackets would be more suitable than square
brackets.
Noone seems to complain of how C/C++ arrays are constructed.
--
Edit bug report at http://bugs.php.net/?id=48266&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48266&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48266&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48266&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48266&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48266&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=48266&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=48266&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=48266&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=48266&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=48266&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=48266&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=48266&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=48266&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=48266&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48266&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=48266&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=48266&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=48266&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=48266&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=48266&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=48266&r=mysqlcfg
#47355 [NEW]: Official x64 build
From: zyss at mail dot zp dot ua Operating system: Windows Server 2008 x64 PHP version: 5.3.0beta1 PHP Bug Type: Feature/Change Request Bug description: Official x64 build Description: Most part of the recently sold Windows servers are equipped with 64-bit versions of the OS but there is no official binary build of PHP for x64 platform. Taking into account the existance of x64 server version at least for 5 years it is very strange why there is no binary builds for it. Unofficial bulids are very unstable and they cannot be used in production environment. Also there is no fastcgi support for IIS 7, it is only available for version 6 (http://www.iis.net/downloads/default.aspx?tabid=34&g=6&i=1521). What are you waiting for? -- Edit bug report at http://bugs.php.net/?id=47355&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47355&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47355&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47355&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47355&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47355&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47355&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47355&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47355&r=needscript Try newer version: http://bugs.php.net/fix.php?id=47355&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47355&r=support Expected behavior: http://bugs.php.net/fix.php?id=47355&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47355&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47355&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47355&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47355&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47355&r=dst IIS Stability: http://bugs.php.net/fix.php?id=47355&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47355&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47355&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47355&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47355&r=mysqlcfg
#46949 [Com]: New "property" keyword token
ID: 46949
Comment by: zyss at mail dot zp dot ua
Reported By: fatih at tullab dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Windows+Linux
PHP Version: 5.3.0alpha3
New Comment:
Agree, much more convenient. Delphi rules :-)
Previous Comments:
[2008-12-26 23:29:23] fatih at tullab dot com
Description:
Hi,
It is hard to write and read this getter and setter codes:
private $_aProperty = "";
public getAProperty(){
return $this->_aProperty;
}
public setAProperty($value){
$this->_aProperty = $value;
}
And if we want to use this getter and setter, we will write like this:
$value = $anObject->getAProperty();
$anObject->setAProperty("something");
It is hard to read and confusing because of "set" and "get" prefixes.
But if we have a "property" keyword, we can use same name without "get"
and "set" prefixes.
class AClass
{
private $_name;
protected getName(){
return $this->_name;
}
protected setName($value){
$this->_name = $value
}
/*/
public property Name get getName set setName;
/*/
}
anObject = new AClass();
anObject->Name = "something"; //triggering setName function.
echo anObject->Name; //triggering getName function.
Regards..
--
Edit this bug report at http://bugs.php.net/?id=46949&edit=1
#46899 [Com]: Typed function arguments should allow nulls
ID: 46899
Comment by: zyss at mail dot zp dot ua
Reported By: zyss at mail dot zp dot ua
Status: Open
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5.2.8
New Comment:
Example in more readable form:
class ExElement extends Exception { };
class Element {
// each element references document for fast access
protected /* Document */ $document;
protected /* Element */ $parent;
function __construct(
Document $document,
Element $parent = null) /* throws ExElement */
{
// is still checked to be valid Document object reference
$this->document = $document;
if ($parent && ($parent->getDocument() != $document))
throw new ExElement("Parent's document doesn't match " .
"Element constructor's argument", 1);
$this->parent = $parent;
}
function getDocument() {
return $this->document;
}
}
Previous Comments:
--------------------
[2008-12-18 13:33:55] zyss at mail dot zp dot ua
Description:
Currently class type can be specified as function argument type, but it
is frequently required to pass null instead of object reference when
there is a default argument value set and it is null. In the following
example constructor's $parent argument can be null for the top-level
objects, but current PHP version doesn't allow it to be null forcing to
remove type declaration that is very undesirable:
class ExElement extends Exception { };
class Element {
protected /* Document */ $document; // each element references
document for fast access
protected /* Element */ $parent;
function __construct(Document $document, Element $parent = null) /*
throws ExElement */ {
$this->document = $document; // is still checked by PHP to be
valid Document object reference
if ($parent && ($parent->getDocument() != $document))
throw new ExElement("Parent's document doesn't match Element
constructor's argument", 1);
$this->parent = $parent;
}
function getDocument() {
return $this->document;
}
}
--
Edit this bug report at http://bugs.php.net/?id=46899&edit=1
#46899 [NEW]: Typed function arguments should allow nulls
From: zyss at mail dot zp dot ua
Operating system: Irrelevant
PHP version: 5.2.8
PHP Bug Type: Feature/Change Request
Bug description: Typed function arguments should allow nulls
Description:
Currently class type can be specified as function argument type, but it is
frequently required to pass null instead of object reference when there is
a default argument value set and it is null. In the following example
constructor's $parent argument can be null for the top-level objects, but
current PHP version doesn't allow it to be null forcing to remove type
declaration that is very undesirable:
class ExElement extends Exception { };
class Element {
protected /* Document */ $document; // each element references
document for fast access
protected /* Element */ $parent;
function __construct(Document $document, Element $parent = null) /*
throws ExElement */ {
$this->document = $document; // is still checked by PHP to be valid
Document object reference
if ($parent && ($parent->getDocument() != $document))
throw new ExElement("Parent's document doesn't match Element
constructor's argument", 1);
$this->parent = $parent;
}
function getDocument() {
return $this->document;
}
}
--
Edit bug report at http://bugs.php.net/?id=46899&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46899&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46899&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46899&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46899&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46899&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46899&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46899&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46899&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46899&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46899&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46899&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46899&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46899&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46899&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46899&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46899&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46899&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46899&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46899&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46899&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46899&r=mysqlcfg
#46648 [Com]: Cannot redeclare declared function
ID: 46648
Comment by: zyss at mail dot zp dot ua
Reported By: satovey at yahoo dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: Win98
PHP Version: 5.2.6
New Comment:
include_once can be used instead of include (in this case) - file will
not be included twice so there will be no errors about the function
redeclaration.
Previous Comments:
[2008-11-25 15:21:25] satovey at yahoo dot com
112508
Last night while trying to create a stripped down
version of my script so that you guys could recreate
the bug, I discovered what was actually causing it and
it was not anything that was suggested.
This turns out to not be an issue with the interpreter
or zend framework but the way errors are reported.
To recreate this error you need to do the following:
1) You will need three files.
testbug.php, testincl1.php, testincl2.php
create a directory called testdir and put
testincl1.php and testincl2.php within it.
2) Within testbug.php put the following code:
//error reporting
ini_set('display_errors', '1');
error_reporting(E_ALL);
include("testdir/testincl1.php");
include("testdir/testincl2.php");
3) Within testincl1.php put the following code.
echo "testincl1.php";
include ("testincl2.php");
At this point, you may already see the problem.
If not step 4 will enlighten you :)
4) Within testincl2.php put the following code.
echo "testincl2.php";
function testfunc(){echo "testfunction";}
testfunc();
The reason I didn't immediately catch this is due to the
fact that in my main file which calls include2.php the
second time is that the command is on line 161
So the real issue is not an engine bug but an error reporting
bug.
*** Solutions ***
Because the error does not refer to the two seperate
include commands for testincl2.php,
the error is obscure and hard to find.
There are three ways to handle this issue.
1) Do nothing as it is a bug in the programmers code and
has nothing to do with PHP. That's the easy way out but
you'll keep getting these bugs reported when they for
apparent reason occur.
2) Change the debugger so that it refers to both include
commands and where they are located.
3) The best approach is to implement a new
programming rule for includes. As no two functions
can have the same name, neither should any two
directory/includefile.php bare the same name.
Under this rule
** Allowed **
/dir1/includefile.php
and
/dir2/includefile.php
would be allowed because they reside under two
different directories. This is desirable as it
is necessary for templates and themes to work
properly.
** Not Allowed **
include ("dir/includefile.php")
include ("dir/includefile.php")
would not be allowed as they are the same file
within the same directory.
include ("dir/includefile2.php")
within the index.php file
and
/dir2/includefile.php which contains
include ("includefile2.php")
would not be allowed as they are the same file
within the same directory.
In this way, an error message would point to
both include instances and what line they
occur on.
If the same bug in other versions have not been found out, this
is most likely what caused them. Following either suggestion two
or three and patching previous versions to correct the issue
will take care of it permanently.
Take care.
Scott
[2008-11-23 15:14:01] crrodriguez at opensuse dot org
XAMMP includes Zend Optimizer and possible other zend extensions,
please disable all zend extensions and report back if the problem still
exists.
[2008-11-22 22:57:20] lbarn...@php.net
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonst
#46742 [Com]: is_numeric function not working as per "common sense"
ID: 46742
Comment by: zyss at mail dot zp dot ua
Reported By: ben at ajmadison dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: any
PHP Version: 5.2.6
New Comment:
It shouldn't.
is_numeric() works just in the same way as in other languages,
specifically as described in PHP docs:
"Numeric strings consist of optional sign, any number of digits,
optional decimal part and optional exponential part. Thus +0123.45e6 is
a valid numeric value. Hexadecimal notation (0xFF) is allowed too but
only without sign, decimal and exponential part."
This doesn't prevent one from implementing his own algorithm with a
custom function.
Previous Comments:
[2008-12-03 17:54:02] ben at ajmadison dot com
Description:
is_numeric("1343.32") returns true, but is_numeric("1,343.32") returns
false. Since the comma is used just for visual representation, the
number represented is still numeric and is_numeric function should
return true.
Reproduce code:
---
echo is_numeric("1,343.32");
Expected result:
true
Actual result:
--
false
--
Edit this bug report at http://bugs.php.net/?id=46742&edit=1
#46865 [NEW]: Typed variables and class members
From: zyss at mail dot zp dot ua
Operating system: Linux, Windows
PHP version: 5.2.8
PHP Bug Type: Feature/Change Request
Bug description: Typed variables and class members
Description:
Currently it is possible to specify class types for function arguments. It
would be very helpful to also add an ability to set types for function
return values, variables (local and global) and especially for class
members. In general - to improve types checking when it is required by
programmer, it will help to eliminate hidden errors that are sometimes hard
to find now. For example:
class Foo {
private Foo $next;
function Foo getNext() {
return $this->next;
}
}
class Bar {
private Foo $foo;
function doo(Foo $prevFoo) {
Foo $newFoo = $prevFoo->getNext();
$this->foo = $newFoo;
}
}
--
Edit bug report at http://bugs.php.net/?id=46865&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46865&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46865&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46865&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46865&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46865&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46865&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46865&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46865&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46865&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46865&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46865&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46865&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46865&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46865&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46865&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46865&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46865&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46865&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46865&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46865&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46865&r=mysqlcfg
#46384 [Opn]: expr() or continue;
ID: 46384
User updated by: zyss at mail dot zp dot ua
Reported By: zyss at mail dot zp dot ua
Status: Open
Bug Type: Feature/Change Request
Operating System: RHEL4, WinXP
PHP Version: 5.2.6
New Comment:
Yes, that's pretty obvious, but PHP could be modified to be able to do
that. This change will make code more clear (like ?: operator) therefore
it is worth implementing.
Previous Comments:
[2008-10-27 16:58:47] info at netmosfera dot it
because "break" and "continue" can't represents boolean values :)
----
[2008-10-25 21:11:06] zyss at mail dot zp dot ua
try
----
[2008-10-25 13:08:22] zyss at mail dot zp dot ua
Description:
Why it is possible to write:
foo() or die("Can't foo");
but impossible to write:
foreach ($bars as $bar) {
foo($bar) or contine; // or break
do_something($bar);
}
Having this functionality would be very convenient as a short form of
the following:
if (!foo($bar)) continue; // or break
--
Edit this bug report at http://bugs.php.net/?id=46384&edit=1
#46384 [Opn]: expr() or continue;
ID: 46384
User updated by: zyss at mail dot zp dot ua
Reported By: zyss at mail dot zp dot ua
Status: Open
Bug Type: Feature/Change Request
Operating System: RHEL4, WinXP
PHP Version: 5.2.6
New Comment:
try
Previous Comments:
[2008-10-25 13:08:22] zyss at mail dot zp dot ua
Description:
Why it is possible to write:
foo() or die("Can't foo");
but impossible to write:
foreach ($bars as $bar) {
foo($bar) or contine; // or break
do_something($bar);
}
Having this functionality would be very convenient as a short form of
the following:
if (!foo($bar)) continue; // or break
--
Edit this bug report at http://bugs.php.net/?id=46384&edit=1
#46384 [NEW]: expr() or continue;
From: zyss at mail dot zp dot ua
Operating system: RHEL4, WinXP
PHP version: 5.2.6
PHP Bug Type: Feature/Change Request
Bug description: expr() or continue;
Description:
Why it is possible to write:
foo() or die("Can't foo");
but impossible to write:
foreach ($bars as $bar) {
foo($bar) or contine; // or break
do_something($bar);
}
Having this functionality would be very convenient as a short form of the
following:
if (!foo($bar)) continue; // or break
--
Edit bug report at http://bugs.php.net/?id=46384&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46384&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46384&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46384&r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=46384&r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=46384&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=46384&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=46384&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=46384&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=46384&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=46384&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=46384&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46384&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46384&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=46384&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46384&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=46384&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=46384&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=46384&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=46384&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=46384&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=46384&r=mysqlcfg
#43236 [NEW]: "if set" and "if not set" functions (ifset, ifnset)
From: zyss at mail dot zp dot ua Operating system: All PHP version: 5.2.5 PHP Bug Type: Feature/Change Request Bug description: "if set" and "if not set" functions (ifset, ifnset) Description: PHP programmers often need to check if certain variable is set when assigning its value to other variable or using it in expression. For example: $item_id = isset($_POST['item_id']) ? $_POST['item_id'] : null; which is quite unreadable. It would be much easier to write such things if there are function ifnset(mixed $value, mixed $alt) (If Not Set) which returns $value if $valus is set or $alt otherwise. Example above could be replaced with: $item_id = ifnset($_POST['item_id'], null); or, if another function is added - ifset - which returns null if its argument is not set or not defined: $item_id = ifset($_POST['item_id']); Similar function exists in MySQL (http://dev.mysql.com/doc/refman/5.1/en/control-flow-functions.html#function_ifnull) which makes life much easier when working with MySQL. It is not possible to implement this function in PHP because when undefined or unset variable is passed as function argument PHP emits warning. Although warnings could be suppressed with @ it significantly slows down performance when such situation happens. Besides debugger catches all suppressed warnings anyway. Thanks. -- Edit bug report at http://bugs.php.net/?id=43236&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=43236&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=43236&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=43236&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=43236&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=43236&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=43236&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=43236&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=43236&r=needscript Try newer version:http://bugs.php.net/fix.php?id=43236&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=43236&r=support Expected behavior:http://bugs.php.net/fix.php?id=43236&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=43236&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=43236&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=43236&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43236&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=43236&r=dst IIS Stability:http://bugs.php.net/fix.php?id=43236&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=43236&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=43236&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=43236&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=43236&r=mysqlcfg
#22216 [Com]: Named Arguments
ID: 22216
Comment by: zyss at mail dot zp dot ua
Reported By: tim dot lokot at printsoft dot com
Status: Open
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 4.3.0
New Comment:
It is really needef feature to have in PHP. I miss this feature very
much when function has many arguments or when there are several boolean
arguments that require true/false values or when there are several
arguments with default value set and you want to use only, say, last
argument it would be very helpful to have named arguments support.
Having this feature would dramatically increase code readability.
Even standard functions will be easier to read having this feature. for
example:
in_array($needle, $haystack, $strict => true);
is much easier to read that just
in_array($needle, $haystack, true);
It would be more native to PHP to use named arguments with => like
foo(var2 => $value);
or
foo($var2 => $value);
Previous Comments:
[2006-06-14 11:48:29] jason at godsey dot net
$value) {
if(!isset($args["$key"])) {
if ($value == REQUIRED) {
$backtrace = debug_backtrace();
$function = $backtrace[1]["function"];
throw new Exception("function: $function var: \$$key not
defined");
}
$args[$key] = $value;
}
}
return 0;
}
function debugging ($args)
{
$defaults = array(
"name"=>"Lanny Jason Godsey",
"text"=>"This is the default text!",
"date"=>REQUIRED
);
parseRequired($defaults, $args);
print "($args[date]) Welcome $args[name], text entered:
$args[text]\n";
}
debugging(array("name"=>"L. Jason Godsey","date"=>date("Y-m-d")));
?>
[2003-02-13 16:59:47] tim dot lokot at printsoft dot com
I know this can be accomplished in other way and also know this has
been brought up before, but they are messy and require code from the
developer to handle this which seems to go against the php ethos of easy
and fast to develop.
If named arguments could be passed to functions and actually processed
by the php parser, then this would be really great. Especially where
function prototypes have default values in them and you only want to set
one of them. The proposed syntax would be something like this:
function foo ($var1="some value", $var2, $var3="some other value")
{
// function code
}
then to call the function would be like this
foo (var2:="value for argument 2 only");
This would also be great if this feature would extend to the existing
functions in the extensions as well.
mail (to:="[EMAIL PROTECTED]", message:="no message", subject:="subject");
This in my opinion makes the function calls more readable in some
circumstances, particularly when you have to keep going back to the
prototype to figure out what the order of the arguments is. It's kind
of self documenting really when you look at code written in this way.
Bug #2285: default arguments skipping
(http://bugs.php.net/bug.php?id=2285) was filed with a similar
suggestion and the solution suggested was to use associative arrays.
Becuase it was never explained in any of the other reports as to why
this wasn't going to be implemented, why the above not more preferable
to have than always have to implement the same code this:
function foo ($args)
{
// Named Argument Checks
$var1 = "some value";
$var3 = "some other value";
foreach ($args as $key => $value)
{
$$key = $value;
}
// Do function code here
}
foo (array ("var2"=>"some other value again","var1"=>"variable 1"));
Surely forcing developers into using this messy syntax goes against one
of the main strengths of php which is simple code that's easy to read,
understand and develop.
I'm in no wasy saying the above code was hard, just the first example
of named arguments seems to fit more into the php way than the second
example.
If this is to be rejected like the other requests for it, can you
please provide a reason why the array method is more preferable?
--
Edit this bug report at http://bugs.php.net/?id=22216&edit=1
