[PHP-BUG] Req #61727 [NEW]: Extend array assignment operator ('=')
From:
Operating system: N/A
PHP version: Irrelevant
Package: Arrays related
Bug Type: Feature/Change Request
Bug description:Extend array assignment operator ('=')
Description:
This feature would allow one to define a value to be used for creating
multiple
array indexes (think of it as an array fill with a tad more flexibility).
The
flexibility is that rather than using a numerical starting index value
and a
length parameter, this new syntax would set the same value for each value
in a
1-dimensional array of scalars (used as keys).
This syntax is essentially a more convenient/concise way of doing something
like:
foreach($array_of_keys as $key)
$the_array[$key] = $value_for_keys;
with the added bonus that it would work both when defining an entire array
or
just
modifying an existing array. These two use case scenarios are modeled below
as
Use
Case #1 and #2, respectively.
Test script:
---
?php
/* -- Use Case #1 -- */
// set/clear appropriate bits at intialization/definition
$binary = array(
range( 0, 0) = 1,
range( 1, 1) = 0,
range( 2, 3) = 1,
range( 4, 11) = 0,
range(12, 15) = 1
);
/* -- Use Case #2 -- */
// initialize array representation of 16-bit binary number to 0
$binary = array_fill(0, 16, 0);
// set appropriate bits
$binary[range( 0, 0)] = 1;
$binary[range( 2, 3)] = 1;
$binary[range(12, 15)] = 0;
?
--
Edit bug report at https://bugs.php.net/bug.php?id=61727edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61727r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61727r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61727r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61727r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61727r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61727r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61727r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61727r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61727r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61727r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61727r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61727r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61727r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61727r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61727r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61727r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61727r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61727r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61727r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61727r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61727r=mysqlcfg
[PHP-BUG] Req #61455 [NEW]: Warn when ini_set()'ing certain directives
From:
Operating system: N/A
PHP version: 5.3.10
Package: PHP options/info functions
Bug Type: Feature/Change Request
Bug description:Warn when ini_set()'ing certain directives
Description:
If ini_set() is called to set any PHP directive whose 'Changeable'
attribute (e.g.
as per man page http://php.net/ini.list) is not 'PHP_INI_USER' or
'PHP_INI_ALL',
an error message could be generated to advise the developer that the
statement
will have no effect. In other words, don't quietly allow directives to be
changed
when they've already taken effect by the time the script is executed (thus
changing them via ini_set() won't ever do anything).
Test script:
---
?php
ini_set('allow_url_fopen', '1');
Expected result:
Warning: Changing PHP directive at runtime has no effect in code on line
3
--
Edit bug report at https://bugs.php.net/bug.php?id=61455edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61455r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61455r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61455r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61455r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61455r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61455r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61455r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61455r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61455r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61455r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61455r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61455r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61455r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61455r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61455r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61455r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61455r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61455r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61455r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61455r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61455r=mysqlcfg
Req #61455 [Opn]: Warn when ini_set()'ing certain directives
Edit report at https://bugs.php.net/bug.php?id=61455edit=1
ID: 61455
User updated by:brad at njoe dot com
Reported by:brad at njoe dot com
Summary:Warn when ini_set()'ing certain directives
Status: Open
Type: Feature/Change Request
Package:PHP options/info functions
Operating System: N/A
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Errata #1 - Looks like PHP is intelligent enough to report the unchanged values
for such directives when doing a phpinfo() (e.g. you can't ini_set() the
'allow_url_fopen' directive and see the Local Value change on the phpinfo()
page).
Thus, the don't quietly allow directives to be changed above should probably
have been don't quietly accept requests to change directives or something of
the
sort.
Previous Comments:
[2012-03-20 13:56:55] brad at njoe dot com
Description:
If ini_set() is called to set any PHP directive whose 'Changeable' attribute
(e.g.
as per man page http://php.net/ini.list) is not 'PHP_INI_USER' or
'PHP_INI_ALL',
an error message could be generated to advise the developer that the statement
will have no effect. In other words, don't quietly allow directives to be
changed
when they've already taken effect by the time the script is executed (thus
changing them via ini_set() won't ever do anything).
Test script:
---
?php
ini_set('allow_url_fopen', '1');
Expected result:
Warning: Changing PHP directive at runtime has no effect in code on line 3
--
Edit this bug report at https://bugs.php.net/bug.php?id=61455edit=1
Req #60625 [Opn]: Emit notice for NOP statement
Edit report at https://bugs.php.net/bug.php?id=60625edit=1
ID: 60625
User updated by:brad at njoe dot com
Reported by:brad at njoe dot com
Summary:Emit notice for NOP statement
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: N/A
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Another example I recently thought of that could elicit the proposed notice
would be:
--
?php
function returnHello() {
return Hello, world!;
}
/* Function return value discarded; this is essentially
equivalent to line #3 in the above test script (just
wrapped in a function return) */
returnHello();
?
--
Previous Comments:
[2011-12-29 19:22:33] brad at njoe dot com
Description:
As a matter of convenience for PHP programmers, would it be possible to somehow
detect NOP-type statements (see example below) and create a new notice to
notify
the programmer of their presence?
When writing embedded code, NOP statements are often handy (or even required).
However, in something as high-level as PHP, I can't see any situation where one
would need such statements. Thus, whenever they DO occur it's most likely by
accident (again see example below).
Test script:
---
?php
This string was meant to be sent as output, but I forgot to echo it!;
1+1;
$variable;
?
Expected result:
Notice: Statement has no effect in (path) on line 3
Notice: Statement has no effect in (path) on line 4
Notice: Statement has no effect in (path) on line 5
--
Edit this bug report at https://bugs.php.net/bug.php?id=60625edit=1
[PHP-BUG] Req #60625 [NEW]: Emit notice for NOP statement
From: Operating system: N/A PHP version: Irrelevant Package: Scripting Engine problem Bug Type: Feature/Change Request Bug description:Emit notice for NOP statement Description: As a matter of convenience for PHP programmers, would it be possible to somehow detect NOP-type statements (see example below) and create a new notice to notify the programmer of their presence? When writing embedded code, NOP statements are often handy (or even required). However, in something as high-level as PHP, I can't see any situation where one would need such statements. Thus, whenever they DO occur it's most likely by accident (again see example below). Test script: --- ?php This string was meant to be sent as output, but I forgot to echo it!; 1+1; $variable; ? Expected result: Notice: Statement has no effect in (path) on line 3 Notice: Statement has no effect in (path) on line 4 Notice: Statement has no effect in (path) on line 5 -- Edit bug report at https://bugs.php.net/bug.php?id=60625edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60625r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60625r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60625r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60625r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60625r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60625r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60625r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60625r=needscript Try newer version: https://bugs.php.net/fix.php?id=60625r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60625r=support Expected behavior: https://bugs.php.net/fix.php?id=60625r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60625r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60625r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60625r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60625r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60625r=dst IIS Stability: https://bugs.php.net/fix.php?id=60625r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60625r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60625r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60625r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60625r=mysqlcfg
Bug #60108 [Com]: GD cannot be compiled with system libgd
Edit report at https://bugs.php.net/bug.php?id=60108edit=1 ID: 60108 Comment by: brad at njoe dot com Reported by:ond...@php.net Summary:GD cannot be compiled with system libgd Status: Open Type: Bug Package:GD related Operating System: Linux PHP Version:5.4.0beta2 Block user comment: N Private report: N New Comment: Confirmed the same build errors against the latest snapshot (php5.4- 201160530) with a system-wide libgd installed (version 2.0.36 versus the bundled 2.0.35). I also noted that the standard libgd version 2.0.35 doesn't include the 'void *data' member in the gdIOCtx struct. Modifying my /usr/include/gd_io.h to include this struct member seems to have also fixed(?) the build error, but that made me wonder... ... Why is the bundled libgd more of a bundled+customized-for-PHP library? It would seem that the 'void *data' member was introduced by the PHP dev team, unless I'm mistaken. Is this member's data important, and, if so, why is the bundled library modified to contain it (meaning that you really don't have an option between using the bundled library or your own system-wide version). Previous Comments: [2011-10-21 12:13:35] ond...@php.net Description: When compiled with system-wide (not embedded) libgd library the compilation fails with: In file included from /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd.c:103:0: /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd_ctx.c: In function '_php_image_stream_putc': /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd_ctx.c:51:41: error: 'struct gdIOCtx' has no member named 'data' /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd_ctx.c: In function '_php_image_stream_putbuf': /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd_ctx.c:58:41: error: 'struct gdIOCtx' has no member named 'data' /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd_ctx.c: In function '_php_image_stream_ctxfree': /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd_ctx.c:67:8: error: 'struct gdIOCtx' has no member named 'data' /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd_ctx.c:68:3: error: 'struct gdIOCtx' has no member named 'data' /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd_ctx.c:69:6: error: 'struct gdIOCtx' has no member named 'data' In file included from /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd.c:103:0: /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd_ctx.c: In function '_php_image_output_ctx': /tmp/buildd/php5-5.4.0~beta2/ext/gd/gd_ctx.c:153:6: error: 'gdIOCtx' has no member named 'data' You need to wrap the _stream_ stuff inside the #ifdef HAVE_GD_BUNDLED -- Edit this bug report at https://bugs.php.net/bug.php?id=60108edit=1
Bug #53608 [Com]: mktime() produces invalid results under 64-bit
Edit report at http://bugs.php.net/bug.php?id=53608edit=1 ID: 53608 Comment by: brad at njoe dot com Reported by:jer_826 at yahoo dot com Summary:mktime() produces invalid results under 64-bit Status: Open Type: Bug Package:Unknown/Other Function Operating System: Linux 2.6.35.7 x86_64 PHP Version:5.2.16 Block user comment: N Private report: N New Comment: Confirmed on Ubuntu 10.10 (Linux 2.6.35-24-server x86_64). Also tested a Win32 build and all three var_dumps() show bool(false) as expected/documented. Previous Comments: [2010-12-24 22:19:04] jer_826 at yahoo dot com Description: It appears that when the PHP binary was compiled against 64-bit libraries, mktime() seems to only do minimal error checking of parms. After some additional testing, if found the following results: PHP Code: $t=mktime(0,0,0,12,3,292277026596); var_dump($t); $t=mktime(0,0,0,12,3,292277026597); var_dump($t); $t=mktime(9000,9000,9000,9000,9000,9 000); var_dump($t); int(9223372036854655200) int(-9223372036823360416) int(-6044405109589065632) It appears that once the parm value exceeds the value limit of a long var, the function returns a negative value. No warnings are produced. Instead of returning FALSE for an error, the function just returns an invalid result. Some additional info here: http://phpbuilder.com/board/showthread.php? p=10971046#post10971046 Test script: --- $t=mktime(0,0,0,12,3,292277026596); var_dump($t); $t=mktime(0,0,0,12,3,292277026597); var_dump($t); $t=mktime(9000,9000,9000,9000,9000,9000); var_dump($t); int(9223372036854655200) int(-9223372036823360416) int(-6044405109589065632) Expected result: Return FALSE if parms are invalid. Actual result: -- Invalid values. Does not return FALSE. -- Edit this bug report at http://bugs.php.net/bug.php?id=53608edit=1
Bug #52302 [Com]: mysqli_fetch_all does not work with MYSQLI_USE_RESULT
Edit report at http://bugs.php.net/bug.php?id=52302edit=1 ID: 52302 Comment by: brad at njoe dot com Reported by: brianlm...@php.net Summary: mysqli_fetch_all does not work with MYSQLI_USE_RESULT Status: Assigned Type: Bug Package: MySQLi related Operating System: Linux PHP Version: 5.3.2 Assigned To: mysql New Comment: Confirmed on Windows build as well using: PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13). Even SELECT'ing a static string (e.g. SELECT 'This is a test.') exhibits this behavior. Previous Comments: [2010-07-10 10:39:32] brianlm...@php.net Description: When using MYSQLI_USE_RESULT as the second parameter to mysqli_query, fetch_all returns null. Test script: --- ?php $m = new MySQLi(, root, , information_schema); $sql = show tables; $res = $m-query($sql, MYSQLI_USE_RESULT); $rows = $res-fetch_all(); var_dump($rows); ? Expected result: An array of the table data. Actual result: -- NULL -- Edit this bug report at http://bugs.php.net/bug.php?id=52302edit=1
Bug #48337 [Fbk-Csd]: Parse error messages getting less descriptive
Edit report at http://bugs.php.net/bug.php?id=48337edit=1 ID: 48337 User updated by: brad at njoe dot com Reported by: brad at njoe dot com Summary: Parse error messages getting less descriptive -Status: Feedback +Status: Closed Type: Bug Package: Scripting Engine problem Operating System: win32 only PHP Version: 5.2.9 New Comment: The URL http://windows.php.net/snapshots/ resulted in a page listing no binaries/sources available for download. Clicked the Download link at the top (taking me to /download/) and I downloaded VC6 x86 Thread Safe (2010-Feb-24 15:33:12) and VC6 x86 Non Thread Safe (2010-Feb-24 15:38:53). Both versions now correctly produced the expected result noted above. Thanks for looking into this! Previous Comments: [2010-06-08 15:37:30] tony2...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-05-20 19:13:12] brad at njoe dot com as I have proper build tools I get proper error messages as well. -- Does this mean that those who are building the Windows binaries don't have the 'proper build tools' that were used in the 5.2.7 and earlier releases? [2009-05-20 08:33:04] j...@php.net Yes, I try things only on *nix and as I have proper build tools I get proper error messages as well. :) [2009-05-19 23:07:44] brad at njoe dot com No, I don't build PHP myself; all of the versions I tried this with were the binaries available from PHP.net. I'm also not 100% sure if it's just with the Windows builds (unless you've tried it on PHP 5.2.9 on a 'nix box - I just don't have access to one at the moment). [2009-05-19 21:43:55] j...@php.net Must be something with the windows build. Propably some bison version issue or something like that. Do you build PHP yourself? 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/bug.php?id=48337 -- Edit this bug report at http://bugs.php.net/bug.php?id=48337edit=1
[PHP-BUG] Req #51629 [NEW]: CURLOPT_FOLLOWLOCATION error message is misleading
From:
Operating system: N/A
PHP version: 5.3.2
Package: Safe Mode/open_basedir
Bug Type: Feature/Change Request
Bug description:CURLOPT_FOLLOWLOCATION error message is misleading
Description:
The following error message is semantically wrong (and for the newbies
that
aren't familiar with PHP, very misleading/confusing):
Warning: curl_setopt() [function.curl-setopt]: CURLOPT_FOLLOWLOCATION can
not be
activated when in safe_mode or an open_basedir is set in file on line
line
From a purely grammatical standpoint, that error message is saying that one
of
the following conditions caused the error: either you're in safe_mode, or
an
open_basedir option was set in file. The in file on line line that
directly follows the open_basedir bit makes it sound like one should look
for
something dealing with open_basedir in file in order to resolve the
error
(assuming they aren't in safe mode).
This situation actually happened on a PHP support community I'm a member
of. I
only mention this to show that I'm not simply quibbling over
semantics/grammar
but rather trying to clarify a misleading error message.
Test script:
---
?php
ini_set('open_basedir', '/'); // for testing purposes
$ch = curl_init();
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, 1);
Expected result:
No output.
Actual result:
--
PHP Warning: curl_setopt(): CURLOPT_FOLLOWLOCATION cannot be activated
when in
safe_mode or an open_basedir is set in G:\php\test.php on line 6
--
Edit bug report at http://bugs.php.net/bug.php?id=51629edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=51629r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=51629r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=51629r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=51629r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=51629r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=51629r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=51629r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=51629r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=51629r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=51629r=support
Expected behavior:
http://bugs.php.net/fix.php?id=51629r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=51629r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=51629r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=51629r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=51629r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=51629r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=51629r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=51629r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=51629r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=51629r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=51629r=mysqlcfg
#48423 [NEW]: ksort applied with array_walk not working consistently
From: brad at njoe dot com
Operating system: Windows *nix
PHP version: 5.2.9
PHP Bug Type: Arrays related
Bug description: ksort applied with array_walk not working consistently
Description:
While using array_walk() to apply ksort() to a multidimensional array, I
experienced some unusual results. I expected that since each sub-array
contained identical keys and values that they would all be sorted in the
same manner. See the example code/expected output below for more
information.
I've tried this on Windows (ver. 5.2.9-2) as well as a Linux box (ver.
5.2.6) and both yielded the same results. If I manually walk ksort()
through the array, i.e.:
ksort($test[0]);
ksort($test[1]);
ksort($test[2]);
ksort($test[3]);
ksort($test[4]);
ksort($test[5]);
then the results are as expected. I've tried with varying number of array
elements in the parent array as well as changing the keys around; no matter
what I did, the array in $test[1] was always sorted incorrectly (and
unpredictably at that).
Reproduce code:
---
?php
$test = array(
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6'),
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6'),
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6'),
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6'),
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6'),
array('key' = 'value1', 'this' = 'value2', 'word' = 'value3', 'blah'
= 'value4', 'foo' = 'value5', 'bar' = 'value6')
);
array_walk($test, 'ksort');
print_r($test);
?
Expected result:
Array
(
[0] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
[1] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
[2] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
[3] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
[4] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
[5] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
)
Actual result:
--
Array
(
[0] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
[1] = Array
(
[foo] = value5
[bar] = value6
[blah] = value4
[word] = value3
[this] = value2
[key] = value1
)
[2] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
[3] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
[4] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
[5] = Array
(
[bar] = value6
[blah] = value4
[foo] = value5
[key] = value1
[this] = value2
[word] = value3
)
)
--
Edit bug report at http://bugs.php.net/?id=48423edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=48423r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=48423r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=48423r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=48423r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=48423r=needdocs
Fixed in release:
http
#48337 [Opn]: Parse error messages getting less descriptive
ID: 48337 User updated by: brad at njoe dot com Reported By: brad at njoe dot com Status: Open Bug Type: Scripting Engine problem Operating System: win32 only PHP Version: 5.2.9 New Comment: as I have proper build tools I get proper error messages as well. -- Does this mean that those who are building the Windows binaries don't have the 'proper build tools' that were used in the 5.2.7 and earlier releases? Previous Comments: [2009-05-20 08:33:04] j...@php.net Yes, I try things only on *nix and as I have proper build tools I get proper error messages as well. :) [2009-05-19 23:07:44] brad at njoe dot com No, I don't build PHP myself; all of the versions I tried this with were the binaries available from PHP.net. I'm also not 100% sure if it's just with the Windows builds (unless you've tried it on PHP 5.2.9 on a 'nix box - I just don't have access to one at the moment). [2009-05-19 21:43:55] j...@php.net Must be something with the windows build. Propably some bison version issue or something like that. Do you build PHP yourself? [2009-05-19 21:29:14] brad at njoe dot com Description: Something has changed in the way the PHP parser reports errors during parsing - it has become slightly less descriptive in certain cases. As far as I can tell, this change happened sometime AFTER the release of PHP version 5.2.6 (in this version, the error message was as expected) - this includes the latest development releases (including PHP 6.0.0-dev). Reproduce code: --- ?php echo ; 'Error! Error!'; ? Expected result: Parse error: syntax error, unexpected ';' in (file) on line 3 Actual result: -- Parse error: parse error in (file) on line 3 -- Edit this bug report at http://bugs.php.net/?id=48337edit=1
#48337 [NEW]: Parse error messages getting less descriptive
From: brad at njoe dot com Operating system: Windows PHP version: 5.2.9 PHP Bug Type: Scripting Engine problem Bug description: Parse error messages getting less descriptive Description: Something has changed in the way the PHP parser reports errors during parsing - it has become slightly less descriptive in certain cases. As far as I can tell, this change happened sometime AFTER the release of PHP version 5.2.6 (in this version, the error message was as expected) - this includes the latest development releases (including PHP 6.0.0-dev). Reproduce code: --- ?php echo ; 'Error! Error!'; ? Expected result: Parse error: syntax error, unexpected ';' in (file) on line 3 Actual result: -- Parse error: parse error in (file) on line 3 -- Edit bug report at http://bugs.php.net/?id=48337edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=48337r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=48337r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=48337r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=48337r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=48337r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=48337r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=48337r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=48337r=needscript Try newer version: http://bugs.php.net/fix.php?id=48337r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=48337r=support Expected behavior: http://bugs.php.net/fix.php?id=48337r=notwrong Not enough info: http://bugs.php.net/fix.php?id=48337r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=48337r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=48337r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=48337r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=48337r=dst IIS Stability: http://bugs.php.net/fix.php?id=48337r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=48337r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=48337r=float No Zend Extensions: http://bugs.php.net/fix.php?id=48337r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=48337r=mysqlcfg
#48337 [Fbk-Opn]: Parse error messages getting less descriptive
ID: 48337 User updated by: brad at njoe dot com Reported By: brad at njoe dot com -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: win32 only PHP Version: 5.2.9 New Comment: No, I don't build PHP myself; all of the versions I tried this with were the binaries available from PHP.net. I'm also not 100% sure if it's just with the Windows builds (unless you've tried it on PHP 5.2.9 on a 'nix box - I just don't have access to one at the moment). Previous Comments: [2009-05-19 21:43:55] j...@php.net Must be something with the windows build. Propably some bison version issue or something like that. Do you build PHP yourself? [2009-05-19 21:29:14] brad at njoe dot com Description: Something has changed in the way the PHP parser reports errors during parsing - it has become slightly less descriptive in certain cases. As far as I can tell, this change happened sometime AFTER the release of PHP version 5.2.6 (in this version, the error message was as expected) - this includes the latest development releases (including PHP 6.0.0-dev). Reproduce code: --- ?php echo ; 'Error! Error!'; ? Expected result: Parse error: syntax error, unexpected ';' in (file) on line 3 Actual result: -- Parse error: parse error in (file) on line 3 -- Edit this bug report at http://bugs.php.net/?id=48337edit=1
