#34341 [NEW]: No warning for $a['zz'] if $a is not an assoc array

[herve dot pages at laposte dot net]

From: herve dot pages at laposte dot net
Operating system: Fedorac Core 3
PHP version:  4.4.0
PHP Bug Type: Feature/Change Request
Bug description:  No warning for $a['zz'] if $a is not an assoc array

Description:

PHP doesn't output any warning for $a['zz'] if $a is not an assoc array.
This problem has been reported in Bug #33879 in the particular case where
$a is a string. Since individual chars in a string can be accessed using
the $a[] syntax, and since the key 'zz' will be automatically cast to 0,
then I can understand why PHP will accept $a['zz'] without complaining.
But when $a is an integer, or a bool, or anything else that has nothing to
do with an array (or a string), I don't see any reason why PHP should
accept $a['zz'] without complaining! It would make some bugs much easier
to find...

Reproduce code:
---
 Display NULL

$not_an_assoc = "85";
$test = $not_an_assoc['zz']; // No warning issued!
echo $test; // -> Display 8
?>

Expected result:

It would be nice if PHP could tell me I'm doing something wrong with a
warning or an error (that's why I'm using error_reporting(E_ALL) after
all).


-- 
Edit bug report at http://bugs.php.net/?id=34341&edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=34341&r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=34341&r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=34341&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34341&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34341&r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=34341&r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=34341&r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=34341&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34341&r=support
Expected behavior:   http://bugs.php.net/fix.php?id=34341&r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=34341&r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=34341&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34341&r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=34341&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34341&r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=34341&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34341&r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=34341&r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=34341&r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=34341&r=mysqlcfg

#28072 [NEW]: static array with some constant keys will be incorrectly ordered

[pages at inrp dot fr]

From: pages at inrp dot fr
Operating system: Fedora 2 test 2
PHP version:  4.3.6
PHP Bug Type: Scripting Engine problem
Bug description:  static array with some constant keys will be incorrectly ordered

Description:

Initialising a static associative array using constants as keys will give
an incorrectly ordered array. Apparently, elements with constant keys will
always appear AFTER elements without constant keys.

Reproduce code:
---
 "111",
"b" => "222",
THIRD_KEY => "333",
"d" => "444"
);
print_r($arr);
}
  
   
test();
?>


Expected result:

Array
(
[a] => 111
[b] => 222
[c] => 333
[d] => 444
)


Actual result:
--
Array
(
[b] => 222
[d] => 444
[a] => 111
[c] => 333
)


-- 
Edit bug report at http://bugs.php.net/?id=28072&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=28072&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=28072&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=28072&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=28072&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28072&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=28072&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=28072&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28072&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=28072&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28072&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28072&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=28072&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28072&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=28072&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=28072&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28072&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28072&r=float

#27070 [Bgs]: preg_match() crashes Apache on VERY SIMPLE pattern but large subject size

[pages at inrp dot fr]

 ID:   27070
 User updated by:  pages at inrp dot fr
 Reported By:  pages at inrp dot fr
 Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: Fedora Core 1 (Linux)
 PHP Version:  5.0.0b3 (beta3)
 New Comment:

I agree every function has its own limitations. And if you
know them, then you can do some checkings on the values of
the parameters you want to pass to the function BEFORE to
call it.
So let's see what http://www.pcre.org/pcre.txt says
about the PCRE library limitations :

 1. "The maximum length of a compiled pattern is 65539".

   The length of my pattern is 4. I suppose the
   "compiled pattern" will be OK. (But what is exactly
   a "compiled pattern" ? And how can I know in advance
   the length it will have ?)

 2. "All values in repeating quantifiers must be less
than 65536".

   I don't use any repeating quantifiers. OK.

 3. "The maximum number of capturing subpatterns is 65535".

   I have only one. OK.

 4. "The maximum depth of nesting parenthesized subpattern
is 200".

   Here the depth is 1. OK.

 5. "The maximum length of a subject string is the largest
positive number that an integer variable can hold".

   My subject has a length of 13800 so it's OK.

 6. "However, PCRE uses recursion to handle subpatterns
and indefinite  repetition.  This  means  that the
available stack space may limit the size of a subject
string that can be processed  by certain patterns."

   So this could be the reason why I get a segmentation
   fault? That's why I tried to set memory_limit to
   64M in php.ini so my script should have enough
   available stack space. But it still crashes !
   (with the same subject size i.e. 13800)
   Anyway, shouldn't we get something like :

 Fatal error: Allowed memory size of 8388608 bytes
 exhausted (tried to allocate 13801 bytes) in
 crashme.php on line 5

   instead of a seg fault + crash ?


Previous Comments:


[2004-01-29 00:29:12] [EMAIL PROTECTED]

This is PCRE limitation. See also: http://www.pcre.org/pcre.txt




[2004-01-28 07:58:41] [EMAIL PROTECTED]

Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php

Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.



[2004-01-28 06:16:59] pages at inrp dot fr

Description:

After running the script bellow, /var/log/httpd/error_log
says:

 [Wed Jan 28 00:19:30 2004] [notice] child pid 13744 exit signal
Segmentation fault (11)

It has been tested on 3 different system :
 - Red Hat 8.0 + Apache 2.0.40 + PHP 4.2.2
 - Red Hat 9 + Apache 2.0.40 + PHP 4.2.2
 - Fedora Core 1 + Apache 2.0.48 + 5.0.0b3

Some statistics :
  - with pattern "/(a)*/", it crashes with a subject
length > 13800
  - with pattern "/((a))*/", it crashes with a subject
length > 9200
  - with pattern "/(((a)))*/", it crashes with a subject
length > 6900
  - with pattern "/a*/", it crashes with a subject
length > 5600
  - with pattern "/(a)*/", it crashes with a
subject length > 4600
  - with pattern "/((a))*/", it crashes with a
subject length > 4000
  - etc...


Reproduce code:
---



Expected result:

No crash

Actual result:
--
Crash :-(





-- 
Edit this bug report at http://bugs.php.net/?id=27070&edit=1

#27070 [NEW]: preg_match() crashes Apache on VERY SIMPLE pattern but large subject size

[pages at inrp dot fr]

From: pages at inrp dot fr
Operating system: Fedora Core 1 (Linux)
PHP version:  5.0.0b3 (beta3)
PHP Bug Type: Reproducible crash
Bug description:  preg_match() crashes Apache on VERY SIMPLE pattern but large subject 
size

Description:

After running the script bellow, /var/log/httpd/error_log
says:

 [Wed Jan 28 00:19:30 2004] [notice] child pid 13744 exit signal
Segmentation fault (11)

It has been tested on 3 different system :
 - Red Hat 8.0 + Apache 2.0.40 + PHP 4.2.2
 - Red Hat 9 + Apache 2.0.40 + PHP 4.2.2
 - Fedora Core 1 + Apache 2.0.48 + 5.0.0b3

Some statistics :
  - with pattern "/(a)*/", it crashes with a subject
length > 13800
  - with pattern "/((a))*/", it crashes with a subject
length > 9200
  - with pattern "/(((a)))*/", it crashes with a subject
length > 6900
  - with pattern "/a*/", it crashes with a subject
length > 5600
  - with pattern "/(a)*/", it crashes with a
subject length > 4600
  - with pattern "/((a))*/", it crashes with a
subject length > 4000
  - etc...


Reproduce code:
---



Expected result:

No crash

Actual result:
--
Crash :-(

-- 
Edit bug report at http://bugs.php.net/?id=27070&edit=1
-- 
Try a CVS snapshot (php4):  http://bugs.php.net/fix.php?id=27070&r=trysnapshot4
Try a CVS snapshot (php5):  http://bugs.php.net/fix.php?id=27070&r=trysnapshot5
Fixed in CVS:   http://bugs.php.net/fix.php?id=27070&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=27070&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27070&r=needtrace
Need Reproduce Script:  http://bugs.php.net/fix.php?id=27070&r=needscript
Try newer version:  http://bugs.php.net/fix.php?id=27070&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=27070&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=27070&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=27070&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=27070&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=27070&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27070&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=27070&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=27070&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=27070&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=27070&r=float

#22321 [NEW]: Execute Bit and XBitHack seems to breaks PHP

[osw at ld dot pages dot de]

From: osw at ld dot pages dot de
Operating system: Linux (SuSE 8.0)
PHP version:  4.3.0
PHP Bug Type: Apache2 related
Bug description:  Execute Bit and XBitHack seems to breaks PHP

Dear PHP-Developers!

I got a very, very strange problem with PHP 4.3.0, Apache 2.0.44  (see
typscript #3 below) and XBitHack on.

If I set the eXecute flag on PHP-parsed files (for example file with
ending .php) PHP don't work correctly any more:

Simple PHP scripts work perfectly (see typescript #2 below) but more
complex  don't work (the PHP code don't get parsed, see typescript #1
below).

In the httpd.conf I set the XBitHack to on. If I turn it off anything
works fine. Or if I remove the x bit from the files it works fine too.

So I'm not really sure whether this is an Apache problem or a PHP
problem.

Hoping it's a real bug and not just a problem with my installation.

Greetings and many thanks in advance,
Kai Seidler




Small typescript #1:

htdocs # cat test.php





htdocs # ls -l test.php
-rw-r--r--1 root root 60 Feb 20 10:55 test.php
htdocs # lynx -source -dump http://localhost/test.php


hello world!


htdocs # chmod a+x test.php
htdocs # lynx -source -dump http://localhost/test.php





htdocs # 



Small typescript #2:

htdocs # cat test2.php

htdocs # ls -l test2.php 
-rw-r--r--1 root root 30 Feb 20 11:01 test2.php
htdocs # lynx -source -dump http://localhost/test2.php
hello world!
htdocs # chmod a+x test2.php
htdocs # lynx -source -dump http://localhost/test2.php
hello world!
htdocs # 



Small typescript #3:

htdocs # telnet localhost 80
Trying ::1...
Connected to localhost.
Escape character is '^]'.
xxx


501 Method Not Implemented

Method Not Implemented
xxx to /index.html not supported.


Apache/2.0.44 (Unix) mod_perl/1.99_08 Perl/v5.8.0 mod_ssl/2.0.44
OpenSSL/0.9.7 PHP/4.3.0 DAV/2 Server at localhost Port 80

Connection closed by foreign host.



-- 
Edit bug report at http://bugs.php.net/?id=22321&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22321&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=22321&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=22321&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22321&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=22321&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22321&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=22321&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22321&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22321&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=22321&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22321&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=22321&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=22321&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22321&r=gnused

#20796 [NEW]: Overridden Get, Post and Cookie data with register_globals turned on

[pages]

From: [EMAIL PROTECTED]
Operating system: Red Hat 8.0
PHP version:  4.2.2
PHP Bug Type: Variables related
Bug description:  Overridden Get, Post and Cookie data with register_globals turned on

With register_globals turned on, if 3 variables WITH THE
SAME NAME are defined in your script (one as a Get
variable, one as a Post variable and one as a Cookie
variable) and if this name is an ARRAY ELEMENT (let's
say foo[ab]), then $_GET["foo"]["ab"] and
$_POST["foo"]["ab"] will both be set to $_COOKIE["foo"]["ab"].

Let's try it.

First, write the script "print_gpc.php" :

";
print_r($_GET);
echo "";

echo '$_POST';
echo "";
print_r($_POST);
echo "";

echo '$_COOKIE';
echo "";
print_r($_COOKIE);
echo "";
?>

Then call the form below ("test.php") in your browser :






and clic on the OK button.

If you have register_globals turned off, you will see
what you expect :

$_GET

Array
(
[foo] => Array
(
[ab] => I_am_a_get_value
)

)

$_POST

Array
(
[foo] => Array
(
[ab] => OK
)

)

$_COOKIE

Array
(
[foo] => Array
(
[ab] => I_am_a_cookie
)

)

but if you have register_globals turned on,
you will have $_GET["foo"]["ab"] == "I_am_a_cookie"
and $_POST["foo"]["ab"] == "I_am_a_cookie".

Strangly, this problem does not occur if the cookie name
is NOT an array element EVEN if register_globals is
turned On. (Try to replace "foo[ab]" by "foo" in the
"test.php" form.)


-- 
Edit bug report at http://bugs.php.net/?id=20796&edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20796&r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=20796&r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=20796&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20796&r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=20796&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20796&r=support
Expected behavior:  http://bugs.php.net/fix.php?id=20796&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20796&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20796&r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=20796&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20796&r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=20796&r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=20796&r=isapi