#34079 [Opn-Bgs]: using __toString with . causes the object id to be printed
ID: 34079
Updated by: [EMAIL PROTECTED]
Reported By: mbneto at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 5.1.0b3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
.
Previous Comments:
[2005-08-11 04:50:01] mbneto at gmail dot com
Description:
When using a echo/print with an object that has a __toString method
defined it behaves strange depending on the usage.
echo $obj is fine
echo $obj.\n is not
Reproduce code:
---
class TestClass
{
public $foo;
public function __construct($foo) {
$this-foo = $foo;
}
public function __toString() {
return $this-foo;
}
}
$n = new TestClass(test) ;
echo $n ; // works - shows test
echo $n.\n ; // does not - show Object id #1
Expected result:
Test
Actual result:
--
Object id #1
--
Edit this bug report at http://bugs.php.net/?id=34079edit=1
#34069 [Bgs]: Named variable array not correctly returned from within member function
ID: 34069
User updated by: davydm at gmail dot com
Reported By: davydm at gmail dot com
Status: Bogus
Bug Type: Class/Object related
Operating System: Linux
PHP Version: 4.4.0
New Comment:
The oddity is that the strange behaviour only occurs when referring to
the variable from within the class. If i had:
$mvarname = arrFoo;
$obj = new Foo();
I can get a reference to an array item with:
var_dump($obj-$mvarname);
but not with
var_dump($this-$mvarname);
from within the class (assuming of course, that $mvarname was set
within the function attempting to do this in the class).
The behaviour is inconsistent, and not at all what was expected, since
the exepected behaviour is shown when accessing the member variable
from outside of the class.
The report is most definitely not bogus -- it's an inconsistency in the
engine. If you want to leave it as such, that's fine with me -- I just
wanted to bring it to your attention, since inconsistent behaviour in a
language / engine is normally considered a bug.
Previous Comments:
[2005-08-10 16:51:30] [EMAIL PROTECTED]
Doesn't matter, I got it.
Use $this-{$name}[$idx] syntax in this case, as the Engine can't guess
what are you referring to:
to $this-{$name[0]} or to $this-{$name}[0].
If you set error_reporting to E_ALL, you'll see appropriate notices.
[2005-08-10 16:46:16] [EMAIL PROTECTED]
And add please expected and actual results of this code.
[2005-08-10 16:36:04] davydm at gmail dot com
I'm afraid that the giant 25 lines below is the smallest I can get a
full example of what I'm talking about, since the problem is a little
complex.
// begin php code
class Foo {
function Foo() {
$this-arrFoo = array(one, two, three);
}
function getFoo($name, $idx) {
if (array_key_exists($idx, $this-$name)) {
return $this-$name[$idx];
} else {print(no $name here of that $idx);}
}
function getBar($name, $idx) {
if (array_key_exists($idx, $this-$name)) {
foreach ($this-$name as $fidx = $val) {
if ($fidx == $idx) return $val;
}
} else {print(no $name here of that $idx);}
}
}
$myfoo = new Foo();
$badret = $myfoo-getFoo(arrFoo, 0); // bad return example
$goodret = $myfoo-getBar(arrFoo, 0); // kludged good return
var_dump($ret);
print(br);
var_dump($myfoo-arrFoo[0]); // direct access works ok
print(br);
var_dump($goodret);
// end php code
[2005-08-10 16:13:03] [EMAIL PROTECTED]
If I can supply more code, please let me know.
No, thanks.
Could you plz provide a short but complete script max 20 lines long
that can be copy/pasted to reproduce the problem?
Thanks.
[2005-08-10 16:07:08] davydm at gmail dot com
Description:
I have a class which maintains heirachical data, as would be (and,
indeed, is) represented with xml. The class basically provides a
programmable interface to an xml data transport, allowing for data to
be transported from php to a tcl middleware server to be parsed and
used. So far, so good.
The best way to explain is to demonstrate:
If I were to load an instance of the object with the following xml:
data
nameFoo/name
descrBar/descr
child
nameChildname/name
descrChilddescr/descr
/child
/data
I would get an object which has:
$obj-name == Foo
$obj-descr == Bar
$obj-child[0]-name == Childname
$obj-child[0]-descr == Childdescr
and so forth. The class allows for nodes with the same name, which are
then placed into an an array, hence the array notation on the child
node above.
The oddity I have hit upon seems to be a PHP bug, but I'm well open to
suggestions. In programming the class, I wanted a consistent interface
with the TCL class I have that handles the same functionality, so there
are times when I have replicated interface functions even when they are
not necessairly required (for the sake of completeness). One such
interface mirroring is the get_child function, which takes in the
following arguments:
$childname (string)
$idx (integer)
and returns a reference to the child named by the $childname and
pointed to by the $idx (if there is one).
The wierdness is that in the original implementation of get_child,
where I just checked that the child name was known and the key existed
in the array, I did:
return $this-$childname[$idx];
once I had verified with array_key_exists that the element actually
existed, I *always* got back null. If I referenced the child from
outside of the class
#33210 [Com]: getimagesize() fails to detect width/height on certain JPEGs
ID: 33210
Comment by: web at tiffanymarket dot com
Reported By: polone at townnews dot com
Status: No Feedback
Bug Type: GetImageSize related
Operating System: RedHat Linux 7.3
PHP Version: 4.3.11
New Comment:
Stained Glass, Tiffany Lamp, ornament, Glass Crafts, Chess--More
The stained glass will bring the light into the color feeling, The
stained glass can make the normal products in to the art crafts, The
stained glass can bring the beautiful into elegance, The Stained glass
make the surface of the room, stare, hall, windows, door, and the
furniture, furnishings, ornament, upholster lamp into spiritualism.
Feeling the beautiful multiformity of the stained glass, make our live
into colorful
URL:http://www.glass-products.org
Previous Comments:
[2005-08-06 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-07-29 01:54:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-07-27 23:18:21] polone at townnews dot com
This is NOT fixed. Raising the limit to 25 0xFF markers doesn't fix
this issue - it merely fixes certain JPEGs that have less than 25 0xFF
markers, but not all.
[2005-06-02 00:29:29] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2005-06-01 07:54:18] polone at townnews dot com
Description:
The getimagesize() function fails on specific JPEG files. The reason is
that php_next_marker() in:
ext/standard/image.c
has an artificial limit of 10 imposed on the number of 0xFF records
that are found in sequential order. As far as I can tell ... the JPEG
file format standards impose no such limit (see,
http://www.jpeg.org/public/jfif.pdf). The proper behaviour should be to
continue to read for the next marker until:
(1) M_SOS is found, in which case, image data has begun and no more
headers will occur
(2) M_EOI has occurred (End of Image header) - this is the proper
behavior in a properly encoded image
(3) EOF - something's wrong - but, at least it's not getimagesize()
I've provided an example of a JPEG file that will fail using
getimagesize() online at:
http://www.townnews.com/contrib/premature.jpg
A fix is easily added by removing the artificial limit and just
incrementing a in the marker's main loop around line 404:
if (++a 10)
{
/* who knows the maxim amount of 0xff? though 7 */
/* but found other implementations */
return M_EOI;
}
I realize this may be in place to prevent infinite loops, but the
reality is EOF will do that for us anyway. To fix the problem, just
switch that code hunk too:
a++;
Reproduce code:
---
?php
$sURL = http://www.townnews.com/contrib/premature.jpg;;
print_r(getimagesize($sURL));
?
Expected result:
Array
(
[0] = 350
[1] = 603
[2] = 2
[3] = width=350 height=603
[bits] = 8
[channels] = 3
[mime] = image/jpeg
)
--
Edit this bug report at http://bugs.php.net/?id=33210edit=1
#31618 [Opn-Bgs]: is_readable() results based on ownership of calling script, not file
ID: 31618 Updated by: [EMAIL PROTECTED] Reported By: kibab at icehouse dot net -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: redhat enterprise PHP Version: 5CVS-2005-03-14 New Comment: Did you read something about safe_mode before turning it On? By default, Safe Mode does a UID compare check when opening files. If you want to relax this to a GID compare, then turn on safe_mode_gid. Whether to use UID (FALSE) or GID (TRUE) checking upon file access. (c) http://www.php.net/manual/en/features.safe-mode.php So, it's perfectly fine to have these errors and to have FALSE in is_readable() because you turned safe_mode yourself. This is expected behaviour. Previous Comments: [2005-08-11 01:59:45] kibab at icehouse dot net Ok. It says (see http://www.ewu.edu/web/tools/bug31618_3.php): Warning: fopen() [function.fopen]: SAFE MODE Restriction in effect. The script whose uid/gid is 687/694 is not allowed to access /usr/share/pear/commonfile.php owned by uid/gid 0/0 in /var/www/sites/web/tools/bug31618_3.php on line 3 Warning: fopen(/usr/share/pear/commonfile.php) [function.fopen]: failed to open stream: Resource temporarily unavailable in /var/www/sites/web/tools/bug31618_3.php on line 3 [2005-08-10 20:44:05] [EMAIL PROTECTED] Of course, I meant this: ?php $myfilename = '/usr/share/pear/commonfile.php'; fopen($myfilename, 'r'); ? [2005-08-10 20:36:39] [EMAIL PROTECTED] Could you plz also try this: ?php fopen($myfilename, 'r'); ? And post the error message here. Thanks. [2005-08-10 20:24:48] kibab at icehouse dot net Ok, here's a new complete example for you. First, we need to do some setup as this is based on permissions, ownership, and safe mode: cd some directory in safe_mode_include_dir # note, I used cd /usr/share/pear echo TESTING commonfile.php chmod a+r commonfile.php Then: $ ls -l commonfile* -rw-rw-r--1 root root8 Aug 10 10:54 commonfile.php And, permissions on the source PHP file in use: $ ls -l bug31618.php -rw-rw-r--1 kpederson financialaid 576 Aug 10 10:50 bug31618.php I used the following relevant settings: $ grep -iE safe|include /etc/php.ini | grep -v ^; safe_mode = On safe_mode_gid = On safe_mode_include_dir = /usr/share/pear safe_mode_exec_dir = /usr/local/php_exe/bin safe_mode_allowed_env_vars = PHP_ safe_mode_protected_env_vars = LD_LIBRARY_PATH include_path = .:/usr/share/pear/:/usr/share/pear/ewu_lib:/var/lib/php_secure sql.safe_mode = Off Now, grab my PHP script from the following URL: http://www.ewu.edu/web/tools/bug31618.php.txt It's output looks like the following (as can be seen from http://www.ewu.edu/web/tools/bug31618.php): is_readable: /usr/share/pear/commonfile.php (false) TESTING Now, if I change the ownership to root:root (as I did for bug31618_2.php, eg. as seen by http://www.ewu.edu/web/tools/bug31618_2.php): is_readable: /usr/share/pear/commonfile.php (true) TESTING Thus, the results are based on ownership of the calling php script, not the file attempting to be read, despite being in safe_mode_include_dir. [2005-08-08 19:56:08] [EMAIL PROTECTED] 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 ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. 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/31618 -- Edit this bug report at http://bugs.php.net/?id=31618edit=1
#34067 [Bgs-Opn]: can not get correct result in some cases
ID: 34067 User updated by: syre at citiz dot net Reported By: syre at citiz dot net -Status: Bogus +Status: Open Bug Type: MySQL related Operating System: win2000 PHP Version: 5.0.3 New Comment: see bug #31044 even phpmyadmin can not get the correct result Previous Comments: [2005-08-10 13:59:36] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . [2005-08-10 13:57:54] syre at citiz dot net Description: mysql extension can not get correct result in some cases Reproduce code: --- ( SELECT '' AS Code FROM test1£¬type as Type WHERE 1 ) UNION ALL ( SELECT code AS Code,'' as Type FROM test2 WHERE 1 ) Expected result: just as the result in mysql console Actual result: -- field Code will always be empty. if uses ( SELECT code AS Code,'' as Type FROM test2 WHERE 1 ) UNION ALL ( SELECT '' AS Code FROM test1£¬type as Type WHERE 1 ) that will ok. -- Edit this bug report at http://bugs.php.net/?id=34067edit=1
#34075 [Opn-Fbk]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Feedback -Bug Type: Unknown/Other Function +Bug Type: *General Issues Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: The problem is with TEST_PHP_EXECUTABLE environment variable being set to something wrong? Are you setting it yourself? What shell are you using? What is it set to in Makefile ? Have you tried latest CVS snapshot? Previous Comments: [2005-08-11 01:41:40] RVaughn at pheedo dot com I have run this test with 'make test' as part of the whole suite, and also directly with: # ./sapi/cli/php -c /etc/php.ini ext/standard/tests/file/bug22414.phpt and # ./sapi/cli/php ext/standard/tests/file/bug22414.phpt Fails in all three cases for PHP 4.4, 4.3.11, and 4.3.8. The first test works, the second one which uses md5_file() to create a hash over the php executable itself, fails with the errors I reported. I suspect it's something particular to RHEL 3.0 but have not had a chance to test on a Fedora Core 2 system yet. [2005-08-10 23:34:21] [EMAIL PROTECTED] How do you run this test? [2005-08-10 23:22:20] RVaughn at pheedo dot com Description: The ext/standard/tests/file/bug22414.phpt script in the test suite always fails on Red Hat Enterprise 3.0. I didn't report this originally as I thought it was a configuration or installation problem with our system when working on PHP 4.4 but I'm trying to run it under PHP 4.3.8 and 4.3.11 and it also fails in the same manner, which leads me to believe it's either got a bug or isn't written correctly to work on RHEL 3.0. I've read Bug #22582: Problem with bug22414.phpt and while those changes are incorporated they do not address the problem on RHEL 3.0. Other bug reports also do not address the problem. I tried making a link from /usr/local/php/bin/php to the new executable but that didn't solve the problem. Reproduce code: --- Please see the ext/standard/tests/file/bug22414.phpt from the PHP 4.4, 4.3.8, or 4.3.11 distributions, it fails on all three. Expected result: EXPECTED OUTPUT HELLO Works Actual result: -- ACTUAL OUTPUT HELLO sh: line 1: /usr/local/php/bin/php: No such file or directory Does not work This fails exactly this way under PHP 4.3.8, 4.3.11 and 4.4 on RHEL 3.0 which is why I believe it's a bug with the script. The script is identical in all three PHP source code distributions. I tried to fix the problem by copying the new php executable # mkdir -p /usr/local/php/bin # cp sapi/cli/php /usr/local/php/bin/php This causes this error on RHEL 3.0 for PHP 4.4, 4.3.11 and 4.3.8: --FILE-- sh: line 1: -n: command not found sh: line 1: -n: command not found Warning: md5_file(): Unable to open file in /usr/src/redhat/SOURCES/php-4.3.8/ext/standard/tests/file/bug22414.phpt on line 24 Does not work Please don't yell at me, I'm just trying to report what I'm guessing is a potential bug particular to RHEL 3.0 and have written my own passthru() function tests which seem to work just fine. Cheers, Rob V. -- Edit this bug report at http://bugs.php.net/?id=34075edit=1
#34067 [Opn-Bgs]: can not get correct result in some cases
ID: 34067 Updated by: [EMAIL PROTECTED] Reported By: syre at citiz dot net -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: win2000 PHP Version: 5.0.3 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. Previous Comments: [2005-08-11 11:17:33] syre at citiz dot net see bug #31044 even phpmyadmin can not get the correct result [2005-08-10 13:59:36] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . [2005-08-10 13:57:54] syre at citiz dot net Description: mysql extension can not get correct result in some cases Reproduce code: --- ( SELECT '' AS Code FROM test1£¬type as Type WHERE 1 ) UNION ALL ( SELECT code AS Code,'' as Type FROM test2 WHERE 1 ) Expected result: just as the result in mysql console Actual result: -- field Code will always be empty. if uses ( SELECT code AS Code,'' as Type FROM test2 WHERE 1 ) UNION ALL ( SELECT '' AS Code FROM test1£¬type as Type WHERE 1 ) that will ok. -- Edit this bug report at http://bugs.php.net/?id=34067edit=1
#27156 [Com]: OCIFetchInto returns false as column value when column contains 1 umlaut
ID: 27156
Comment by: max at pict dot lviv dot ua
Reported By: sanjok at pict dot lviv dot ua
Status: No Feedback
Bug Type: OCI8 related
Operating System: Linux SuSE 7.38.1
PHP Version: 4.3.4
Assigned To: tony2001
New Comment:
We have this problem on multiple configurations, everywhere situation
is the same.
Case1:
DB Server Compaq Tru64Unix + Oracle 10.1.0.3.0
Client machines:
A. SuSE 7.3 + Oracle Client 9.0.1
B. SLES 9 + Oracle Instant Client 10
Case2:
DB Server SuSE 8.1 + Oracle 9.0.1
Oracle Client 9.0.1 running on the same machine.
We have tried PHP 4.3.10 and 4.3.11, and this doesn't change the
situation, problem persists.
In SQLPlus I see data correctly saved from a web application, but when
using OCIFetchInto in PHP script I receive FALSE instead of column
value when column contains more than one umlaut character.
Some details:
NLS_LANG = GERMAN_AUSTRIA.UTF8;
Database encoding is WE8DEC.
Previous Comments:
[2005-04-02 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-03-25 01:42:42] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2004-02-11 04:13:23] sanjok at pict dot lviv dot ua
P.S.: Feedback was sent on Thu, 5 Feb 2004 15:25:01 (+0200) to mr.
Anatoly Dovgal, but there was no response from him.
[2004-02-11 04:06:06] sanjok at pict dot lviv dot ua
?php
/*
Oracle 9.0.1i
database internal encoding WE8DEC
database client encoding specified by NLS_LANG parameter
is GERMAN_AUSTRIA.UTF8, so Oracle automatically converts
characters to client encoding.
CREATE TABLE TEST (
NAME CHAR(10)
);
insert into test values ('ü');
insert into test values ('üü');
NOTE: this error doesn't occur when we use
column type VARCHAR2 insted of CHAR
*/
ociinternaldebug(true);
$connection = OCILogon(DB_USER, DB_PASS, DB_NAME);
$query = SELECT * FROM TEST;
$statement = OCIParse ($connection, $query);
OCIExecute($statement);
while (OCIFetchInto ($statement, $row, OCI_ASSOC+OCI_RETURN_NULLS))
{
var_dump($row);
}
?
result of ociinternaldebug.
OCIDebug: oci_do_connect: id=3
OCIDebug: oci_parse SELECT * FROM TEST id=4 conn=3
array(1) { [NAME]= string(11) u } OCIDebug: _oci_make_zval:
NAME,retlen = 11,retlen4 = 0,storage_size4 =
11,indicator 10, retcode = 1406
array(1) { [NAME]= bool(false) } OCIDebug: START php_rshutdown_oci
OCIDebug: END php_rshutdown_oci
OCIDebug: START _oci_stmt_list_dtor: id=4 last_query=SELECT * FROM
TEST
OCIDebug: START _oci_column_hash_dtor: NAME
OCIDebug: END _oci_column_hash_dtor: NAME
OCIDebug: START _oci_conn_list_dtor: id=3
OCIDebug: nothing to do..
OCIDebug: END _oci_conn_list_dtor: id=3
OCIDebug: END _oci_stmt_list_dtor: id=4
[2004-02-05 05:31:08] sanjok at pict dot lviv dot ua
Description:
OCIFetchInto returns false as column value if table column contains
more than one umlaut character while combination of OCIFetch and
OCIResult functions returns correct result.
Environment:
OS: Linux SuSE 7.3/8.1;
DB: Oracle 8.1.7/9.0.1i;
PHP: 4.3.4 release
Oracle NLS_LANG is set to GERMAN_AUSTRIA.UTF8
--
Edit this bug report at http://bugs.php.net/?id=27156edit=1
#34078 [Opn-Asn]: Reflection API problems in methods with boolean or null default values
ID: 34078
Updated by: [EMAIL PROTECTED]
Reported By: leon at lost dot co dot nz
-Status: Open
+Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Debian Sarge (2.6.12 kernel)
PHP Version: 5CVS-2005-08-11 (dev)
-Assigned To:
+Assigned To: tony2001
New Comment:
The fix is ready, but we have to wait for Andrey Dmitry to finish
merging of Unicode patches.
Previous Comments:
[2005-08-11 03:37:24] leon at lost dot co dot nz
Description:
This problem came up when moving our homebrew 'PHPDoc' type class to
PHP5.1. When built with --enable-debug PHP throws up warnings up when
the class to be documented ('A' below) contains methods with default
values that are either NULL or boolean
In the code snippet below we get two warnings, one for each default
parameter. Changing the default values to a string or number (even
zero) eliminates the warnings.
This is a serious problem for us. When documenting some of our bigger
classes we have seen lots of 'odd' behaviour, including permanent 100%
CPU usage by Apache! It has taken *days* to track down the problem to
the snippet below. If there is anything elso I can do to help fix it
please let me know...
Reproduce code:
---
$r = new ReflectionClass('A');
$methods = $r-getMethods();
foreach($methods as $method)
{
$parameters = $method-getParameters();
foreach($parameters as $p)
{
if($p-isDefaultValueAvailable())
$p-getDefaultValue();
}
}
class A
{
function foo($p=null, $q=false)
{
}
}
Expected result:
No output at all -- I've trimed all the output code out.
Actual result:
--
$ php bug2.php
Warning: String is not zero-terminated (ZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x08514F30
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
5 bytes)
End: OK
---
Warning: String is not zero-terminated (ZZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x085150C8
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
6 bytes)
End: OK
---
--
Edit this bug report at http://bugs.php.net/?id=34078edit=1
#34080 [NEW]: recordset crash on trim and on fields with value null
From: mihkel at art dot tartu dot ee
Operating system: MS-Win2000 SP4
PHP version: 5.0.4
PHP Bug Type: Unknown/Other Function
Bug description: recordset crash on trim and on fields with value null
Description:
Database: MS-SQL Server 2000 (in case it is important)
See code below.
Expecting it to NOT hang forever and produce some output.
Unfortunately - if ANY of the lines with crash comment behind them is
present it will hang forever (until web-server timeout).
'user' - is a present field of type char(20) and value is never NULL.
'kursjuh' - is a present field of type char(1) and will result a crash
only if field value is NULL.
PHP fails to produce error log - so, no info there.
Reproduce code:
---
$db=new COM(ADODB.Connection);
$db-Open(Driver={SQL Server};Server=***;Database=***;);
$dta=$db-Execute(SELECT * FROM Qigus);
while(!$dta-EOF) {
echo $dta-Fields['kursjuh']-Value; // crash
echo $dta['kursjuh']; // crash
echo $dta['user']; // works fine
echo trim($dta['user']); // crash
$dta-MoveNext(); }
--
Edit bug report at http://bugs.php.net/?id=34080edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34080r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=34080r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=34080r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34080r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34080r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=34080r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=34080r=needscript
Try newer version: http://bugs.php.net/fix.php?id=34080r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34080r=support
Expected behavior: http://bugs.php.net/fix.php?id=34080r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=34080r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=34080r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34080r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34080r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34080r=dst
IIS Stability: http://bugs.php.net/fix.php?id=34080r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34080r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=34080r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=34080r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=34080r=mysqlcfg
#34080 [Opn-Fbk]: recordset crash on trim and on fields with value null
ID: 34080
Updated by: [EMAIL PROTECTED]
Reported By: mihkel at art dot tartu dot ee
-Status: Open
+Status: Feedback
Bug Type: COM related
Operating System: MS-Win2000 SP4
PHP Version: 5.0.4
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Previous Comments:
[2005-08-11 13:15:04] mihkel at art dot tartu dot ee
Description:
Database: MS-SQL Server 2000 (in case it is important)
See code below.
Expecting it to NOT hang forever and produce some output.
Unfortunately - if ANY of the lines with crash comment behind them is
present it will hang forever (until web-server timeout).
'user' - is a present field of type char(20) and value is never NULL.
'kursjuh' - is a present field of type char(1) and will result a crash
only if field value is NULL.
PHP fails to produce error log - so, no info there.
Reproduce code:
---
$db=new COM(ADODB.Connection);
$db-Open(Driver={SQL Server};Server=***;Database=***;);
$dta=$db-Execute(SELECT * FROM Qigus);
while(!$dta-EOF) {
echo $dta-Fields['kursjuh']-Value; // crash
echo $dta['kursjuh']; // crash
echo $dta['user']; // works fine
echo trim($dta['user']); // crash
$dta-MoveNext(); }
--
Edit this bug report at http://bugs.php.net/?id=34080edit=1
#15324 [Com]: CGI version (php.exe) times out
ID: 15324 Comment by: nagashankarp at yahoo dot com Reported By: isitlive at altavista dot com Status: No Feedback Bug Type: IIS related Operating System: Win2K PHP Version: 4.1.1 New Comment: I get the same error, i am using the PHP Verion 4.3.9 after 5 minutes of this error, my IIS would hang, and i have to restart IIS, if you have a soluton let me know at the earliest. -Nagashankar Previous Comments: [2002-07-19 01:00:10] php-bugs at lists dot php dot net No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2002-06-18 05:39:53] [EMAIL PROTECTED] Is this fixed with PHP 4.2.1? Derick [2002-03-15 20:08:54] max at artco dot com I had the same problem running php 4.04 as CGI on WinNT 4.0. I found that if the registry key (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\parameters\SynAttackProtect = 2) exists and is set I get the bug that is discussed in this report. By deleteing the SynAttackProtect key, I am no longer get the The script started fromt he URL error and my server no longer crashes. Before removeing the SynAttackProtect key from the registry I would get the above error and then my smpt server and ftp services would stop responding, and my web service would stop after 5-10 minutes after the smtp and ftp untill eventually the server crashed and needed to be restarted. for more info on the SynAttackProtect registry value you can visit microsoft KB# http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q315669 [2002-02-25 21:28:11] WPinegar at healthtech dot net I've seen the same problem. You're right, adding the ISAPI filter does solve the problem. [2002-02-01 18:39:56] isitlive at altavista dot com note: I think we may have isolated the ISAPI problem...4.1.1 seems to crash in IIS (Win2K) after some period of dormancy only if it is *not* installed as an ISAPI filter as well as an ISAPI application, contrary to the advice given in the installation notes. 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/15324 -- Edit this bug report at http://bugs.php.net/?id=15324edit=1
#27156 [Com]: OCIFetchInto returns false as column value when column contains 1 umlaut
ID: 27156
Comment by: max at pict dot lviv dot ua
Reported By: sanjok at pict dot lviv dot ua
Status: No Feedback
Bug Type: OCI8 related
Operating System: Linux SuSE 7.38.1
PHP Version: 4.3.4
Assigned To: tony2001
New Comment:
One more investigation:
If I simply convert column from char to varchar2 using ALTER TABLE
statement, it doesn't help. OCIFetchInto behaves correctly only if
table was created with varchar2 type. But even with varchar2 column, if
I fill entire column with umlauts, OCIFetchInto and OCIFetch fail.
Sample:
SQL desc test;
Name Null?Typ
-
NAME VARCHAR2(10)
SQL select name, length(name) from test order by name;
NAME LENGTH(NAME)
--
ü 1
üü2
ü 5
üü6
üü 10
--So you see that Oracle shows length correctly.
Now I use the following php script:
ociinternaldebug(true);
$connection = OCILogon(, , );
$query = SELECT * FROM TEST order by name;
$statement = OCIParse ($connection, $query);
OCIExecute($statement);
while (OCIFetchInto ($statement, $row, OCI_ASSOC+OCI_RETURN_NULLS))
{
var_dump($row);
}
OCIExecute($statement);
while(OCIFetch($statement)) {
var_dump (OCIResult($statement, NAME));
}
And here's result of ociinternaldebug:
OCIDebug: _oci_open_server new conn=0 dname=br /
OCIDebug: _oci_open_session new sess=5 user=br /
OCIDebug: oci_do_connect: id=6br /
OCIDebug: oci_parse SELECT * FROM TEST order by name id=7 conn=6br
/
array(1) {
[NAME]=
string(2) ü
}
array(1) {
[NAME]=
string(4) üü
}
array(1) {
[NAME]=
string(10) ü
}
OCIDebug: _oci_make_zval: NAME,retlen = 10,retlen4 =
0,storage_size4 = 11,indicator6, retcode = 1406br /
array(1) {
[NAME]=
bool(false)
}
OCIDebug: _oci_make_zval: NAME,retlen = 10,retlen4 =
0,storage_size4 = 11,indicator 10, retcode = 1406br /
array(1) {
[NAME]=
bool(false)
}
string(2) ü
string(4) üü
string(10) ü
OCIDebug: _oci_make_zval: NAME,retlen = 10,retlen4 =
0,storage_size4 = 11,indicator6, retcode = 1406br /
bool(false)
OCIDebug: _oci_make_zval: NAME,retlen = 10,retlen4 =
0,storage_size4 = 11,indicator 10, retcode = 1406br /
bool(false)
OCIDebug: START php_rshutdown_ocibr /
OCIDebug: END php_rshutdown_ocibr /
OCIDebug: START _oci_stmt_list_dtor: id=7 last_query=SELECT * FROM
TEST order by namebr /
OCIDebug: START _oci_column_hash_dtor: NAMEbr /
OCIDebug: END _oci_column_hash_dtor: NAMEbr /
OCIDebug: START _oci_conn_list_dtor: id=6br /
OCIDebug: nothing to do..br /
OCIDebug: END _oci_conn_list_dtor: id=6br /
OCIDebug: END _oci_stmt_list_dtor: id=7br /
OCIDebug: START _oci_close_session: logging-off sess=5br /
OCIDebug: START _oci_close_server: detaching conn=4 dbname=br /
OCIDebug: START php_mshutdown_ocibr /
OCIDebug: END php_mshutdown_ocibr /
-
Some thoughts on this error:
Combination of OCIFetch+OCIResult has the same problem.
The error occurs when length of column value in bytes exceeds length of
column defined in oracle + 1 byte. Length of column value differs from
length of field for multi-byte encodings like UTF8, so probably there's
an error with memory allocation (it's just a guess).
And P.S.: By the way, when I change environment variable NLS_LANG to
GERMAN_AUSTRIA.WE8DEC, everything's selected fine!
Previous Comments:
[2005-08-11 12:40:21] max at pict dot lviv dot ua
We have this problem on multiple configurations, everywhere situation
is the same.
Case1:
DB Server Compaq Tru64Unix + Oracle 10.1.0.3.0
Client machines:
A. SuSE 7.3 + Oracle Client 9.0.1
B. SLES 9 + Oracle Instant Client 10
Case2:
DB Server SuSE 8.1 + Oracle 9.0.1
Oracle Client 9.0.1 running on the same machine.
We have tried PHP 4.3.10 and 4.3.11, and this doesn't change the
situation, problem persists.
In SQLPlus I see data correctly saved from a web application, but when
using OCIFetchInto in PHP script I receive FALSE instead of column
value when column contains more than one umlaut character.
Some details:
NLS_LANG = GERMAN_AUSTRIA.UTF8;
Database encoding is WE8DEC.
[2005-04-02 01:00:04] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug
#34080 [Fbk-Opn]: recordset crash on trim and on fields with value null
ID: 34080
User updated by: mihkel at art dot tartu dot ee
Reported By: mihkel at art dot tartu dot ee
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: MS-Win2000 SP4
PHP Version: 5.0.4
New Comment:
The crash is gone now. (for both trim and null fields)
BUT. fields with the value NULL return now 'Object id #4' which doesn't
sound right. Am i missing somethig and it is suposed to do so?
(i would prefer 'NULL' or '' as return value)
Previous Comments:
[2005-08-11 13:22:38] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-08-11 13:15:04] mihkel at art dot tartu dot ee
Description:
Database: MS-SQL Server 2000 (in case it is important)
See code below.
Expecting it to NOT hang forever and produce some output.
Unfortunately - if ANY of the lines with crash comment behind them is
present it will hang forever (until web-server timeout).
'user' - is a present field of type char(20) and value is never NULL.
'kursjuh' - is a present field of type char(1) and will result a crash
only if field value is NULL.
PHP fails to produce error log - so, no info there.
Reproduce code:
---
$db=new COM(ADODB.Connection);
$db-Open(Driver={SQL Server};Server=***;Database=***;);
$dta=$db-Execute(SELECT * FROM Qigus);
while(!$dta-EOF) {
echo $dta-Fields['kursjuh']-Value; // crash
echo $dta['kursjuh']; // crash
echo $dta['user']; // works fine
echo trim($dta['user']); // crash
$dta-MoveNext(); }
--
Edit this bug report at http://bugs.php.net/?id=34080edit=1
#34080 [Opn]: recordset crash on trim and on fields with value null
ID: 34080
User updated by: mihkel at art dot tartu dot ee
Reported By: mihkel at art dot tartu dot ee
Status: Open
Bug Type: COM related
Operating System: MS-Win2000 SP4
PHP Version: 5.0.4
New Comment:
Update:
$x=$rs['kursjuh'];
echo 'x'.$x;
echo 'x'.$rs['kursjuh'];
gives me 'Object id #4Object id #5' - this can't be normal.
Previous Comments:
[2005-08-11 14:35:38] mihkel at art dot tartu dot ee
The crash is gone now. (for both trim and null fields)
BUT. fields with the value NULL return now 'Object id #4' which doesn't
sound right. Am i missing somethig and it is suposed to do so?
(i would prefer 'NULL' or '' as return value)
[2005-08-11 13:22:38] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-08-11 13:15:04] mihkel at art dot tartu dot ee
Description:
Database: MS-SQL Server 2000 (in case it is important)
See code below.
Expecting it to NOT hang forever and produce some output.
Unfortunately - if ANY of the lines with crash comment behind them is
present it will hang forever (until web-server timeout).
'user' - is a present field of type char(20) and value is never NULL.
'kursjuh' - is a present field of type char(1) and will result a crash
only if field value is NULL.
PHP fails to produce error log - so, no info there.
Reproduce code:
---
$db=new COM(ADODB.Connection);
$db-Open(Driver={SQL Server};Server=***;Database=***;);
$dta=$db-Execute(SELECT * FROM Qigus);
while(!$dta-EOF) {
echo $dta-Fields['kursjuh']-Value; // crash
echo $dta['kursjuh']; // crash
echo $dta['user']; // works fine
echo trim($dta['user']); // crash
$dta-MoveNext(); }
--
Edit this bug report at http://bugs.php.net/?id=34080edit=1
#34080 [Opn]: recordset crash on trim and on fields with value null
ID: 34080
User updated by: mihkel at art dot tartu dot ee
Reported By: mihkel at art dot tartu dot ee
Status: Open
Bug Type: COM related
Operating System: MS-Win2000 SP4
PHP Version: 5.0.4
New Comment:
Correction:
'xObject id #4xObject id #5'
(where is the edit button when you need one? :/ )
Previous Comments:
[2005-08-11 14:47:39] mihkel at art dot tartu dot ee
Update:
$x=$rs['kursjuh'];
echo 'x'.$x;
echo 'x'.$rs['kursjuh'];
gives me 'Object id #4Object id #5' - this can't be normal.
[2005-08-11 14:35:38] mihkel at art dot tartu dot ee
The crash is gone now. (for both trim and null fields)
BUT. fields with the value NULL return now 'Object id #4' which doesn't
sound right. Am i missing somethig and it is suposed to do so?
(i would prefer 'NULL' or '' as return value)
[2005-08-11 13:22:38] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-08-11 13:15:04] mihkel at art dot tartu dot ee
Description:
Database: MS-SQL Server 2000 (in case it is important)
See code below.
Expecting it to NOT hang forever and produce some output.
Unfortunately - if ANY of the lines with crash comment behind them is
present it will hang forever (until web-server timeout).
'user' - is a present field of type char(20) and value is never NULL.
'kursjuh' - is a present field of type char(1) and will result a crash
only if field value is NULL.
PHP fails to produce error log - so, no info there.
Reproduce code:
---
$db=new COM(ADODB.Connection);
$db-Open(Driver={SQL Server};Server=***;Database=***;);
$dta=$db-Execute(SELECT * FROM Qigus);
while(!$dta-EOF) {
echo $dta-Fields['kursjuh']-Value; // crash
echo $dta['kursjuh']; // crash
echo $dta['user']; // works fine
echo trim($dta['user']); // crash
$dta-MoveNext(); }
--
Edit this bug report at http://bugs.php.net/?id=34080edit=1
#34080 [Opn-Bgs]: recordset crash on trim and on fields with value null
ID: 34080
Updated by: [EMAIL PROTECTED]
Reported By: mihkel at art dot tartu dot ee
-Status: Open
+Status: Bogus
Bug Type: COM related
Operating System: MS-Win2000 SP4
PHP Version: 5.0.4
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Previous Comments:
[2005-08-11 14:49:05] mihkel at art dot tartu dot ee
Correction:
'xObject id #4xObject id #5'
(where is the edit button when you need one? :/ )
[2005-08-11 14:47:39] mihkel at art dot tartu dot ee
Update:
$x=$rs['kursjuh'];
echo 'x'.$x;
echo 'x'.$rs['kursjuh'];
gives me 'Object id #4Object id #5' - this can't be normal.
[2005-08-11 14:35:38] mihkel at art dot tartu dot ee
The crash is gone now. (for both trim and null fields)
BUT. fields with the value NULL return now 'Object id #4' which doesn't
sound right. Am i missing somethig and it is suposed to do so?
(i would prefer 'NULL' or '' as return value)
[2005-08-11 13:22:38] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2005-08-11 13:15:04] mihkel at art dot tartu dot ee
Description:
Database: MS-SQL Server 2000 (in case it is important)
See code below.
Expecting it to NOT hang forever and produce some output.
Unfortunately - if ANY of the lines with crash comment behind them is
present it will hang forever (until web-server timeout).
'user' - is a present field of type char(20) and value is never NULL.
'kursjuh' - is a present field of type char(1) and will result a crash
only if field value is NULL.
PHP fails to produce error log - so, no info there.
Reproduce code:
---
$db=new COM(ADODB.Connection);
$db-Open(Driver={SQL Server};Server=***;Database=***;);
$dta=$db-Execute(SELECT * FROM Qigus);
while(!$dta-EOF) {
echo $dta-Fields['kursjuh']-Value; // crash
echo $dta['kursjuh']; // crash
echo $dta['user']; // works fine
echo trim($dta['user']); // crash
$dta-MoveNext(); }
--
Edit this bug report at http://bugs.php.net/?id=34080edit=1
#31618 [Bgs-Opn]: is_readable() results based on ownership of calling script, not file
ID: 31618 User updated by: kibab at icehouse dot net Reported By: kibab at icehouse dot net -Status: Bogus +Status: Open Bug Type: Filesystem function related Operating System: redhat enterprise PHP Version: 5CVS-2005-03-14 New Comment: Yes. I read docs, although I sometimes misunderstand them: Note in my previous post: safe_mode_include_dir = /usr/share/pear Also note that per the documentation (http://www.php.net/manual/en/features.safe-mode.php): safe_mode_include_dir string UID/GID checks are bypassed when including files from this directory and its subdirectories (directory must also be in include_path or full path must including). Certainly $myfilename = '/usr/share/pear/commonfile.php'; is in safe_mode_include dir. Thus, the error message is incorrect and *is* a PHP bug. Previous Comments: [2005-08-11 11:10:57] [EMAIL PROTECTED] Did you read something about safe_mode before turning it On? By default, Safe Mode does a UID compare check when opening files. If you want to relax this to a GID compare, then turn on safe_mode_gid. Whether to use UID (FALSE) or GID (TRUE) checking upon file access. (c) http://www.php.net/manual/en/features.safe-mode.php So, it's perfectly fine to have these errors and to have FALSE in is_readable() because you turned safe_mode yourself. This is expected behaviour. [2005-08-11 01:59:45] kibab at icehouse dot net Ok. It says (see http://www.ewu.edu/web/tools/bug31618_3.php): Warning: fopen() [function.fopen]: SAFE MODE Restriction in effect. The script whose uid/gid is 687/694 is not allowed to access /usr/share/pear/commonfile.php owned by uid/gid 0/0 in /var/www/sites/web/tools/bug31618_3.php on line 3 Warning: fopen(/usr/share/pear/commonfile.php) [function.fopen]: failed to open stream: Resource temporarily unavailable in /var/www/sites/web/tools/bug31618_3.php on line 3 [2005-08-10 20:44:05] [EMAIL PROTECTED] Of course, I meant this: ?php $myfilename = '/usr/share/pear/commonfile.php'; fopen($myfilename, 'r'); ? [2005-08-10 20:36:39] [EMAIL PROTECTED] Could you plz also try this: ?php fopen($myfilename, 'r'); ? And post the error message here. Thanks. [2005-08-10 20:24:48] kibab at icehouse dot net Ok, here's a new complete example for you. First, we need to do some setup as this is based on permissions, ownership, and safe mode: cd some directory in safe_mode_include_dir # note, I used cd /usr/share/pear echo TESTING commonfile.php chmod a+r commonfile.php Then: $ ls -l commonfile* -rw-rw-r--1 root root8 Aug 10 10:54 commonfile.php And, permissions on the source PHP file in use: $ ls -l bug31618.php -rw-rw-r--1 kpederson financialaid 576 Aug 10 10:50 bug31618.php I used the following relevant settings: $ grep -iE safe|include /etc/php.ini | grep -v ^; safe_mode = On safe_mode_gid = On safe_mode_include_dir = /usr/share/pear safe_mode_exec_dir = /usr/local/php_exe/bin safe_mode_allowed_env_vars = PHP_ safe_mode_protected_env_vars = LD_LIBRARY_PATH include_path = .:/usr/share/pear/:/usr/share/pear/ewu_lib:/var/lib/php_secure sql.safe_mode = Off Now, grab my PHP script from the following URL: http://www.ewu.edu/web/tools/bug31618.php.txt It's output looks like the following (as can be seen from http://www.ewu.edu/web/tools/bug31618.php): is_readable: /usr/share/pear/commonfile.php (false) TESTING Now, if I change the ownership to root:root (as I did for bug31618_2.php, eg. as seen by http://www.ewu.edu/web/tools/bug31618_2.php): is_readable: /usr/share/pear/commonfile.php (true) TESTING Thus, the results are based on ownership of the calling php script, not the file attempting to be read, despite being in safe_mode_include_dir. 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/31618 -- Edit this bug report at http://bugs.php.net/?id=31618edit=1
#27792 [Asn]: Functions fail on large files (filesize,is_file,is_dir)
ID: 27792 Updated by: [EMAIL PROTECTED] Reported By: kode at kodekrash dot com Status: Assigned Bug Type: Filesystem function related Operating System: * (LFS) PHP Version: 5.1* Assigned To: wez New Comment: Well, looks like it will be fixed in 6.x instead. Previous Comments: [2005-07-01 12:04:08] no at spam dot net is_link also fails on large files 2GB [2005-06-30 06:40:29] dan at baximus dot com Gee I hope it's included in PHP 5.1. IMHO this is a pretty important feature to have. But then, not everyone is in the business of serving up such large files from a PHP-driven website. [2004-03-31 07:14:18] [EMAIL PROTECTED] PHP does not currently support LFS. This is something to be addressed in PHP 5.1 [2004-03-31 03:27:56] kode at kodekrash dot com Description: Error: (errno=75 - Value too large for defined data type) Functions: is_file is_dir filesize Premise: size of file is greater than 2GB. -- I have been able to reproduce this error on 4 different PHP installations (all on RedHat 7.3 machines), using 12 different files for each test. -- This bug has been submitted before, but is marked as BOGUS, which it is certainly not. Reproduce code: --- filesize( $fname ); or is_file( $fname ) or is_dir( $fname ) where filesize( $fname ) 2GB Expected result: Function: filesize Expected: numeric value matching size of file Function: is_file Expected: boolean value Function: is_dir Expected: boolean value Actual result: -- (errno=75 - Value too large for defined data type) -- Edit this bug report at http://bugs.php.net/?id=27792edit=1
#28038 [Asn-Opn]: Sent incorrect RCPT TO commands to SMTP server
ID: 28038 Updated by: [EMAIL PROTECTED] Reported By: jordi at jcanals dot net -Status: Assigned +Status: Open Bug Type: Mail related Operating System: win32 PHP Version: 5CVS, 4CVS (2005-08-08) Assigned To: wez New Comment: Not sure how this ended up on my plate, but I'm not going to look at it anytime soon. Previous Comments: [2005-08-08 00:14:40] [EMAIL PROTECTED] See also: #32600 (rpath set wrong too) [2005-01-25 00:26:34] [EMAIL PROTECTED] The above patch is wrong. Only acceptable form for RCPT TO: is: RCPT TO:[EMAIL PROTECTED] Notice the brackets. Do not confuse yourself with RFC2822.. It does not obsolete 2821 as it talks about different thing. So the fix is to drop the outside brackets stuff out of the addresses. [2004-08-06 01:59:45] papercrane at reversefold dot com Here's a possible patch for it. It's pretty simplistic, bit it should work: http://www.reversefold.com/sendmail.c.patch Full file: http://www.reversefold.com/sendmail.c NOTE: I haven't actually *tested* this, it may not even compile. If it doesn't, please send me a note and I'll try to fix it. [2004-04-17 19:14:01] jordi at jcanals dot net Description: In windows, and using an SMTP server, when you try to send a mail using the mail function the SMTP transaction will fail if you include recipient names. When including any recipient header in the following format (wich follows the RFC 2822), the mail function does not handle it properly: To: User Name [EMAIL PROTECTED] Cc: Other User [EMAIL PROTECTED] Bcc: Third User [EMAIL PROTECTED] Loking at the SMTP transaction, the PHP mail layer sends this RCPT commands wich do not folow the SMTP standard stated on RFC 2821: RCPT TO:User Name [EMAIL PROTECTED] RCPT TO:Other User [EMAIL PROTECTED] RCPT TO:Third User [EMAIL PROTECTED] Fails always with this environments: Tested on Windows XP, Apache 2.0.49, PHP 4.3.6 (Also in 4.3.4) Tested also on Windows 2000, IIS, PHP 4.3.6 Tested Using SMTP servers on Linux with Exim and Sendmail. Tested also using the default Windows 2000 SMTP server. Reproduce code: --- // SAMPLE 1: $to_recipient = User Name [EMAIL PROTECTED]; $header = Cc: Other User [EMAIL PROTECTED]\r\n; $header .= Bcc: Third User [EMAIL PROTECTED]\r\n; mail($to_recipient, $subject, $body, $header); // FAILS with SMTP errors for all three recipients. SAMPLE 2: $to_recipient = [EMAIL PROTECTED]; $header = To: User Name [EMAIL PROTECTED]\r\n; $header .= Cc: Other User [EMAIL PROTECTED]\r\n; $header .= Bcc: Third User [EMAIL PROTECTED]\r\n; mail($to_recipient, $subject, $body, $header); FAILS on with SMTP error on the three recipients passed on the $header field. Expected result: Expected that the mail layer exctracts only the mail address from recipients to send the SMTP commands: As seen on the RFC's 2821 and 2822, when sending a mail with the recipient headers formed like above, it is expected the mail layer to extract ONLY the email address to send the RCPT commands, and pass the headers without any change in the DATA command during the SMTP transaction. Example of the correct SMTP transaction for the above headers: RCPT TO:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] DATA To: User Name [EMAIL PROTECTED] Cc: Other User [EMAIL PROTECTED] Bcc: Third User [EMAIL PROTECTED] Actual result: -- You get that error for all recipients with the recipient name: Warning: mail(): SMTP server response: 501 SomeOne Name [EMAIL PROTECTED]: @ or . expected after SomeOne in mail.class.php on line 333 This error is produced when the mail layer is sending a wrong formed RCPT TO: command in the SMTP transaction. -- Edit this bug report at http://bugs.php.net/?id=28038edit=1
#31327 [Asn-Fbk]: chinese char and word problem
ID: 31327
Updated by: [EMAIL PROTECTED]
Reported By: vtsuper1 at mail dot hongkong dot com
-Status: Assigned
+Status: Feedback
Bug Type: COM related
Operating System: windowXP
PHP Version: 5.1
Assigned To: wez
New Comment:
Make sure you're setting up the code page properly.
From the manual:
com.code_page
It controls the default character set code-page to use when passing
strings to and from COM objects. If set to an empty string, PHP will
assume that you want CP_ACP, which is the default system ANSI code
page.
If the text in your scripts is encoded using a different
encoding/character set by default, setting this directive will save you
from having to pass the code page as a parameter to the COM class
constructor. Please note that by using this directive (as with any PHP
configuration directive), your PHP script becomes less portable; you
should use the COM constructor parameter whenever possible.
Consult MSDN for more information on code pages.
Previous Comments:
[2005-08-08 11:21:52] bmcrowley at lcwarriormail dot com
I am experiencing the same bug with Arabic - I pull a UTF-8 character
from a database, and push it into Word with UTF-8 for the characterset.
I get meaningless characters (the box) appearing after (to the right of)
the arabic text. Also, the arabic text gets mangled - words out of
order...
I would try to post the input/output here, but it would be
meaningless...
[2005-08-03 07:51:25] [EMAIL PROTECTED]
Assigned to the maintainer of COM extension.
[2005-08-03 05:17:34] vtsuper1 at mail dot hongkong dot com
Dear sir,
Thanks for your help. I have test it in a php 5.1.X version. But the
bug doesn't fixed. The meaningless space change to a square characters
only...
Anyway, thanks for your help. (This problem hasn't exist in Excel, it
only happened in Word only)
From Victor
[2005-08-02 23:49:10] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2004-12-28 20:46:49] vtsuper1 at mail dot hongkong dot com
Description:
I have try this code in
php 5.0.3 and 4.3
I'm using Chinese winXP and Chinese Office XP
apache 2
both version of php also have the same problem
When I use Chinese character in the string, the output of the word file
will have some meaningless spaces after the words I expected(my expected
string is ok, no problem). There are no problem if I using English. And
this problem will not occurs in excel.
Reproduce code:
---
?php
// starting word
$word = new COM(word.application) or die(Unable to instantiate
Word);
echo Loaded Word, version {$word-Version}\n;
//bring it to front
$word-Visible = 1;
//open an empty document
$word-Documents-Add();
//do some weird stuff
$word-Selection-TypeText(§A¦n¶Ü);
$word-Documents[1]-SaveAs(Useless test.doc);
//closing word
$word-Quit();
//free the object
$word = null;
?
Expected result:
§A¦n¶Ü
Actual result:
--
§A¦n¶Ü
(there are some spaces occurs, I use the underline to repersent the
spaces)
--
Edit this bug report at http://bugs.php.net/?id=31327edit=1
#32371 [Asn]: [PATCH] php://input sometimes returns dupl data
ID: 32371
Updated by: [EMAIL PROTECTED]
Reported By: phpint-bkrrym at skrt dot org
Status: Assigned
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-03-19)
-Assigned To: wez
+Assigned To: pollita
New Comment:
Sara, could you take a look at this?
It seems ok, but I don't have time to verify it.
Previous Comments:
[2005-03-19 02:25:49] phpint-bkrrym at skrt dot org
Description:
Full description and PATCH for 5-CVS and 4.3.10 are here:
http://thepathetic.com/jozef/php_input_stream_patch.html
http://thepathetic.com/jozef/php-5.0.3-input_stream.patch
http://thepathetic.com/jozef/php-4.3.10-input_stream.patch
Both 5 and 4.3.10 have the problem (same code).
Because of a subtle buffer index bug, in some cases, the php://input
stream returns incorrect data.
Symptoms:
If the php://input is parsed in 4000-byte chunks, the first corruption
occurs at byte number 8193 (1-based). A chunk of the previous 192 bytes
repeats there. The same corruption happens periodically in the data if
it is long enough.
The problem was discovered when directly parsing a POSTed XML with a
long text-node.
Interestingly enough, reading the contents of php://input with
file_get_contents and parsing the string works around the symptoms.
Reproduce code:
---
$s = simplexml_load_file('php://input');
sees the text node corrupted, whereas
$d = file_get_contents('php://input');
$s = simplexml_load_string($d);
does not.
Expected result:
should be the same in both cases
Actual result:
--
difference at byte number 8193 (1-based) from the begining of the xml.
--
Edit this bug report at http://bugs.php.net/?id=32371edit=1
#32771 [Asn-Bgs]: is_dir() returns false for absolute path. Even if it is a folder
ID: 32771
Updated by: [EMAIL PROTECTED]
Reported By: silkensedai at online dot fr
-Status: Assigned
+Status: Bogus
Bug Type: Directory function related
Operating System: GNU/Linux Ubuntu 5.4
PHP Version: 5.0.4
Assigned To: wez
New Comment:
Sounds like expected behaviour in safe_mode.
Previous Comments:
[2005-04-19 22:06:28] [EMAIL PROTECTED]
is_file() does the same thing when the owner of the file is not the
owner of the script.
IMO that's how safe_mode works.
Wez, is this the expected behaviour or am I wrong?
[2005-04-19 17:56:46] silkensedai at online dot fr
Also: safe mode is enabled
[2005-04-19 17:31:26] silkensedai at online dot fr
Description:
is_dir() does not work when the folder is an absolute path.
For example is_dir('/mnt') won't work (return false).
But it works for relative path.
Example:
$ php -r 'clearstatcache();var_dump(is_dir(/mnt/));' bool(false)
$ php -r 'clearstatcache();var_dump(is_dir(./Templates));'
bool(true)
$ test -d /mnt/ echo dir || echo not_dir
dir
$ test -d ./Templates echo dir || echo not_dir
dir
From phpinfo(): PHP Version 5.0.4
System: Linux louve 2.6.10-5-386 #1 Tue Apr 5 12:12:40 UTC 2005 i686
Configure Command: './configure' '--quiet' '--enable-cli'
'--enable-cgi' '--disable-all' '--disable-rpath' '--disable-debug'
'--disable-path-info-check' '--disable-magic-quotes' '--disable-posix'
'--disable-short-tags' '--enable-ipv6' '--disable-static'
'--disable-pcntl' '--without-pear' '--with-apxs2=/usr/bin/apxs2'
'--with-mysql=/usr' '--with-mysqli=/usr/bin/mysql_config' '--with-zlib'
'--with-bz2' '--with-dbx' '--with-ctype' '--with-openssl'
'--with-pcre-regex' '--with-gettext' '--with-mcrypt' '--with-mhash'
'--with-iconv' '--with-sqlite' '--with-sqlite-utf8' '--with-gd'
'--with-jpeg-dir' '--with-png-dir' '--with-zlib-dir' '--with-xpm-dir'
'--with-ttf' '--with-xsl' '--with-tsrm-pthreads' '--with-tidy'
'--with-freetype-dir' '--enable-gd-native-ttf' '--enable-safe-mode'
'--enable-calendar' '--enable-mbstring' '--enable-spl' '--enable-ftp'
'--enable-bcmath' '--enable-sockets' '--enable-dom' '--enable-xml'
'--enable-soap' '--enable-libxml' '--enable-session'
'--enable-simplexml' '--enable-memory-limit'
Server API Apache 2.0 Handler
PHP API 20031224
PHP Extension 20041030
Zend Extension 220040412
Reproduce code:
---
print is_dir('/')?dir: /:not_dir: /;
Expected result:
dir: /
Actual result:
--
not_dir: /
--
Edit this bug report at http://bugs.php.net/?id=32771edit=1
#6305 [Ana-Asn]: when string contains at, wrong time returned
ID: 6305 Updated by: [EMAIL PROTECTED] Reported By: elkan at cs dot ucsd dot edu -Status: Analyzed +Status: Assigned Bug Type: Feature/Change Request Operating System: linux PHP Version: 4.0.1pl2 -Assigned To: +Assigned To: derick New Comment: This still happens in PHP 5.1, but I'm not sure if it is fixable. Previous Comments: [2000-08-27 11:58:20] [EMAIL PROTECTED] Oops. Typo. It should have read #5041.. --Jani [2000-08-27 06:45:19] [EMAIL PROTECTED] Well, I see no relation here to #5401... The problem seems to be that at is seen as Azores timezone, not as time delimiter... [2000-08-25 13:12:13] [EMAIL PROTECTED] See #5401. --Jani [2000-08-22 22:21:21] elkan at cs dot ucsd dot edu When given this date: Tuesday, 22 Aug 2000 at 5:06 PM EDT strtotime returns 2000-08-22 15:06:00 i.e. 5pm is converted to 15:00, which is 3pm. This does not appear to be a time zone problem. strtotime works correctly when at is deleted from the input string. -- Edit this bug report at http://bugs.php.net/?id=6305edit=1
#6343 [Opn-Csd]: enable pass by reference to be optional
ID: 6343
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4.0 Latest CVS (24/08/2000)
New Comment:
This works in PHP 5.1.
Previous Comments:
[2003-03-23 20:40:39] rainmaker at omenmedia dot com
This was submitted almost three years ago, is still open, and there are
no additional comments on this report? This particular issue is a major
one and needs urgent attention.
[2003-03-23 20:40:38] rainmaker at omenmedia dot com
This was submitted almost three years ago, is still open, and there are
no additional comments on this report? This particular issue is a major
one and needs urgent attention.
[2000-08-24 23:24:19] [EMAIL PROTECTED]
It would quite fine if zend would support this syntax...
function ref($var='') {}
To enable optional references. If no parameter is supplied,
set $var to standard value, as usual.
--
Edit this bug report at http://bugs.php.net/?id=6343edit=1
#9035 [Opn-Csd]: Need a PHP_AUTH_REALM built-in variable
ID: 9035 Updated by: [EMAIL PROTECTED] Reported By: lurker at shadowtech dot org -Status: Open +Status: Closed Bug Type:Feature/Change Request PHP Version: 4.0.4pl1 New Comment: Added to PHP 5.1.0. Previous Comments: [2001-01-31 13:45:01] lurker at shadowtech dot org For querying the current status of http authentication, PHP has the built-in variables PHP_AUTH_USER, PHP_AUTH_PW, and even PHP_AUTH_TYPE. The last piece of the puzzle is missing however since there is no PHP_AUTH_REALM. -- Edit this bug report at http://bugs.php.net/?id=9035edit=1
#6305 [Asn-WFx]: when string contains at, wrong time returned
ID: 6305 Updated by: [EMAIL PROTECTED] Reported By: elkan at cs dot ucsd dot edu -Status: Assigned +Status: Wont fix Bug Type: Feature/Change Request Operating System: linux PHP Version: 4.0.1pl2 Assigned To: derick Previous Comments: [2005-08-11 17:47:02] [EMAIL PROTECTED] This still happens in PHP 5.1, but I'm not sure if it is fixable. [2000-08-27 11:58:20] [EMAIL PROTECTED] Oops. Typo. It should have read #5041.. --Jani [2000-08-27 06:45:19] [EMAIL PROTECTED] Well, I see no relation here to #5401... The problem seems to be that at is seen as Azores timezone, not as time delimiter... [2000-08-25 13:12:13] [EMAIL PROTECTED] See #5401. --Jani [2000-08-22 22:21:21] elkan at cs dot ucsd dot edu When given this date: Tuesday, 22 Aug 2000 at 5:06 PM EDT strtotime returns 2000-08-22 15:06:00 i.e. 5pm is converted to 15:00, which is 3pm. This does not appear to be a time zone problem. strtotime works correctly when at is deleted from the input string. -- Edit this bug report at http://bugs.php.net/?id=6305edit=1
#7132 [Opn-Asn]: fsockopen doesn't report dns lookup failure
ID: 7132 Updated by: [EMAIL PROTECTED] Reported By: kaufmann at cyland dot com -Status: Open +Status: Assigned Bug Type: Feature/Change Request Operating System: SuSE Linux 6.4 PHP Version: 4.0.2 -Assigned To: +Assigned To: wez New Comment: Wez, can you please take a look at my patch? http://mega.ist.utl.pt/~ncpl/php_7132_patch.txt test script: ? $bogus = 'www.aasa.net'; fsockopen($bogus, 80, $errno, $errstr); echo $errno, \n; var_dump($errstr); ? This patch also fixes the problem of having two warnings generated, instead of just one. Previous Comments: [2000-10-11 06:36:14] kaufmann at cyland dot com fsockopen doesn't report dns lookup failure in errno and errstr. It would be nice if this error was passed including a hint what is wrong with the call to fsockopen. Debugging of skripts using sockets would become easier. -- Edit this bug report at http://bugs.php.net/?id=7132edit=1
#34075 [Fbk-Opn]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: Shell is RHEL 3.0 /bin/bash. # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php # ls -al `echo $TEST_PHP_EXECUTABLE` -rwxr-xr-x1 root root 6254005 Aug 10 21:50 /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php From the Makefile: TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) top_builddir = /usr/src/redhat/SOURCES/php-4.3.8 SAPI_CLI_PATH = sapi/cli/php The Makefile matches this, which is where the unstriped executable is: # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php As per Tony's suggestion (thanks, but doesn't work, sorry I forgot that I also tried 'run-tests.php'): # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/src/redhat/SOURCES/php-4.3.8 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.8 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/imap.ini,/etc/php.d/ldap.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] Output from this run is the same: # more ext/standard/tests/file/bug22414.out HELLO Does not work I haven't tried the CVS snapshot because we've given up on getting PHP 4.4 to build and work on RHEL 3.0 for now. The fact that this test fails on three different RHEL 3.0 servers w/three different PHP versions (4.3.8, 4.3.11, 4.4) is what makes me think there's a problem with this script on RHEL 3.0. The test script is the same in all three distributions, and it fails in the same way on all three, and I've written some simple passthru() tests myself and the function seems to work just fine, it's the test script. Could be that passthru() is failing on RHEL 3.0 for all these versions as my own tests are pretty simple. Thanks! Previous Comments: [2005-08-11 11:24:51] [EMAIL PROTECTED] ./sapi/cli/php ext/standard/tests/file/bug22414.phpt Ugh..Don't do it, please. These tests should not be run directly. You must use run-tests.php for running them. Please try to this: TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt [2005-08-11 11:22:30] [EMAIL PROTECTED] The problem is with TEST_PHP_EXECUTABLE environment variable being set to something wrong? Are you setting it yourself? What shell are you using? What is it set to in Makefile ? Have you tried latest CVS snapshot? [2005-08-11 01:41:40] RVaughn at pheedo dot com I have run this test with 'make test' as part of the whole suite, and also directly with: # ./sapi/cli/php -c /etc/php.ini ext/standard/tests/file/bug22414.phpt and # ./sapi/cli/php ext/standard/tests/file/bug22414.phpt Fails in all three cases for PHP 4.4, 4.3.11, and 4.3.8. The first test works, the second one which uses md5_file() to create a hash over the php executable itself, fails with the errors I reported. I suspect it's something particular to RHEL 3.0 but have not had a chance to test on a Fedora Core 2 system yet. [2005-08-10 23:34:21] [EMAIL PROTECTED] How do you run this test? [2005-08-10 23:22:20] RVaughn at pheedo dot com Description: The ext/standard/tests/file/bug22414.phpt script in the test suite always fails on Red Hat Enterprise 3.0. I didn't report this originally as I thought it was a configuration or installation problem with our system when working on PHP 4.4 but I'm trying to run it under PHP 4.3.8 and 4.3.11 and it also fails in the same manner, which leads me to believe it's either got a bug or isn't written correctly to work on RHEL 3.0. I've read Bug #22582: Problem with bug22414.phpt and while those changes are incorporated they do not address the problem on RHEL 3.0. Other bug reports also do not address the problem. I tried making a link from /usr/local/php/bin/php to the new executable but that didn't solve the problem. Reproduce code: --- Please see the ext/standard/tests/file/bug22414.phpt from the PHP 4.4, 4.3.8, or 4.3.11 distributions, it fails on all three. Expected result:
#7132 [Asn]: fsockopen doesn't report dns lookup failure
ID: 7132 Updated by: [EMAIL PROTECTED] Reported By: kaufmann at cyland dot com Status: Assigned Bug Type: Feature/Change Request Operating System: SuSE Linux 6.4 PHP Version: 4.0.2 Assigned To: wez New Comment: BTW, the script I've provided leaks with or without my patch (with zend mm disabled)! The problematic part is the simple echo $errno;. Previous Comments: [2005-08-11 18:43:41] [EMAIL PROTECTED] Wez, can you please take a look at my patch? http://mega.ist.utl.pt/~ncpl/php_7132_patch.txt test script: ? $bogus = 'www.aasa.net'; fsockopen($bogus, 80, $errno, $errstr); echo $errno, \n; var_dump($errstr); ? This patch also fixes the problem of having two warnings generated, instead of just one. [2000-10-11 06:36:14] kaufmann at cyland dot com fsockopen doesn't report dns lookup failure in errno and errstr. It would be nice if this error was passed including a hint what is wrong with the call to fsockopen. Debugging of skripts using sockets would become easier. -- Edit this bug report at http://bugs.php.net/?id=7132edit=1
#13199 [Opn-WFx]: Punctuation of month abbreviation in date()
ID: 13199 Updated by: [EMAIL PROTECTED] Reported By: mail at scottbrinker dot com -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: Red Hat Linux 7.1 PHP Version: 4.0.6 New Comment: This is too magic, IMHO. Previous Comments: [2001-09-07 14:07:52] mail at scottbrinker dot com When calling date with format character M, the three-letter abbreviation is returned; however, when one wants to place a period after this three letter abbreviation, there is trouble in May... For example: date(M., $january_date) Jan. date(M., $february_date) === Feb. date(M., $may_date) May. (not an abbreviation!) I know all of this can be fixed with a few lines of code that checks to see if the month is May before adding the period, but it seems to me that an abbreviated three-letter textual month format character could be valuable. But, then the subject of AP-style abbreviations comes up... Their the list of months and abbreviations (or lack-thereof) reads: Jan., Feb., March, April, May, June, July, Aug., Sept., Oct., Nov., Dec. -- Edit this bug report at http://bugs.php.net/?id=13199edit=1
#14399 [Opn-Bgs]: eregi_replace does not handle upercase scandinavian characters
ID: 14399 Updated by: [EMAIL PROTECTED] Reported By: jonas at israelsson dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.1.0 New Comment: duplicate of #6680. BTW, you can always use the PCRE extension. Previous Comments: [2001-12-20 15:10:02] jonas at israelsson dot com i have tryed setlocale(LC_ALL, swedish); setlocale(LC_ALL, sv_SE); setlocale(LC_ALL, se); none affects eregi_replace behaivor If it was a localize problem why then would lowercase caracters work ?? Kindest Regards Jonas Isaelsson [2001-12-11 17:14:55] [EMAIL PROTECTED] Try setting your locale first with setlocale() Feedback. [2001-12-10 05:39:51] jonas at israelsson dot com It seem to be so that eregi_replace can´t handle uppercase scandinavian characters (ÅÄÖ). Lowercase works fine. -- Edit this bug report at http://bugs.php.net/?id=14399edit=1
#15184 [Opn-Asn]: Calculate the quarter with date('Q')?
ID: 15184
Updated by: [EMAIL PROTECTED]
Reported By: j-f at gmx dot net
-Status: Open
+Status: Assigned
Bug Type: Feature/Change Request
Operating System: -
PHP Version: 4.1.1
-Assigned To:
+Assigned To: derick
New Comment:
One more for you, Derick :)
Previous Comments:
[2002-01-23 11:44:26] j-f at gmx dot net
I added a note how to calculate the quarter:
ceil(date('n')/3);
But I suggest extending date() with the option 'Q' or 'q'.
--
Edit this bug report at http://bugs.php.net/?id=15184edit=1
#17075 [Opn-Csd]: Prevent cookies being rawurlencoded
ID: 17075 Updated by: [EMAIL PROTECTED] Reported By: csaba at alum dot mit dot edu -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: All PHP Version: 4.2.0 New Comment: A setrawcookie() was added in PHP 5.0.0 Previous Comments: [2002-05-07 12:29:30] csaba at alum dot mit dot edu setcookie rawurlencodes all cookies before going out, which precludes being able to set certain cookies. For example, suppose I want '=' or '' in a cookie. I have to use Header and manually construct the cookie. Perhaps we could get a rawsetcookie(...) function which behaves the same except that it does not do any encoding and fails if it is passed an illegal character. (related report http://bugs.php.net/bug.php?id=17050) -- Edit this bug report at http://bugs.php.net/?id=17075edit=1
#19583 [Opn-Csd]: Remove is_dst parameter from gmmktime?
ID: 19583
Updated by: [EMAIL PROTECTED]
Reported By: at217 at chebucto dot ns dot ca
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: Linux
PHP Version: 4.2.3
New Comment:
This mess is fixed with the new date handling, introduced with PHP 5.1.
The 'is_dst' parameter became also deprecated.
Previous Comments:
[2002-09-24 16:50:22] at217 at chebucto dot ns dot ca
Here's one way to make the suggested change, if anyone cares to commit
it:
*** datetime.c-orig Tue Sep 24 16:18:27 2002
--- datetime.c Tue Sep 24 18:35:03 2002
***
*** 83,93
struct tm *ta, tmbuf;
time_t t;
int i, gmadjust, seconds, arg_count = ZEND_NUM_ARGS();
- int is_dst = -1;
if (arg_count 7 || zend_get_parameters_array_ex(arg_count,
arguments) == FAILURE) {
WRONG_PARAM_COUNT;
}
/* convert supplied arguments to longs */
for (i = 0; i arg_count; i++) {
convert_to_long_ex(arguments[i]);
--- 83,97
struct tm *ta, tmbuf;
time_t t;
int i, gmadjust, seconds, arg_count = ZEND_NUM_ARGS();
if (arg_count 7 || zend_get_parameters_array_ex(arg_count,
arguments) == FAILURE) {
WRONG_PARAM_COUNT;
}
+ if (gm arg_count == 7) {
+ // TO DO: issue a warning here, but keep going (so
WRONG_PARAM_COUNT won't work)
+ arg_count--;
+ }
+
/* convert supplied arguments to longs */
for (i = 0; i arg_count; i++) {
convert_to_long_ex(arguments[i]);
***
*** 119,125
*/
switch(arg_count) {
case 7:
! ta-tm_isdst = is_dst = Z_LVAL_PP(arguments[6]);
/* fall-through */
case 6:
/* special case:
--- 123,129
*/
switch(arg_count) {
case 7:
! ta-tm_isdst = Z_LVAL_PP(arguments[6]);
/* fall-through */
case 6:
/* special case:
***
*** 169,176
}
seconds = mktime(ta);
- if (is_dst == -1)
- is_dst = ta-tm_isdst;
if (gm) {
#if HAVE_TM_GMTOFF
--- 173,178
***
*** 185,193
** the value of timezone - 3600 seconds.
*/
#ifdef __CYGWIN__
! gmadjust = -(is_dst ? _timezone - 3600 : _timezone);
#else
! gmadjust = -(is_dst ? timezone - 3600 : timezone);
#endif
#endif
seconds += gmadjust;
--- 187,195
** the value of timezone - 3600 seconds.
*/
#ifdef __CYGWIN__
! gmadjust = -(ta-tm_isdst ? _timezone - 3600 : _timezone);
#else
! gmadjust = -(ta-tm_isdst ? timezone - 3600 : timezone);
#endif
#endif
seconds += gmadjust;
***
*** 197,203
}
/* }}} */
! /* {{{ proto int mktime(int hour, int min, int sec, int mon, int day,
int year)
Get UNIX timestamp for a date */
PHP_FUNCTION(mktime)
{
--- 199,205
}
/* }}} */
! /* {{{ proto int mktime(int hour, int min, int sec, int mon, int day,
int year, int is_dst)
Get UNIX timestamp for a date */
PHP_FUNCTION(mktime)
{
[2002-09-24 16:39:48] at217 at chebucto dot ns dot ca
Passing anything but -1 for the is_dst argument of gmmktime can result
in times that are off by an hour, if the system's local time zone uses
DST. For example, I assumed that passing 0 would the right thing to do
(not in DST), but if the date falls within my local DST range, the time
I get back is an hour ahead. This is because, internally, PHP calls
mktime and then tries to adjust the local time to GMT.
Of course, this is easy enough to work around, and I will put a note on
the manual page, but I still think the parameter is irrelevant for
gmmktime, and since its use can cause errors, it would be nice if it
were removed, or at least ignored (if one wants to avoid breaking
existing code; although a warning would probably be good).
/* Demostrate problem with gmmktime() */
// These should produce the same value, as GMT has no DST.
echo gmmktime(0, 0, 0, 7, 23, 2002, 0) .\n;
echo gmmktime(0, 0, 0, 7, 23, 2002) . \n;
--
Edit this bug report at http://bugs.php.net/?id=19583edit=1
#20339 [Opn-Csd]: Magic functions __wakeup __sleep
ID: 20339 Updated by: [EMAIL PROTECTED] Reported By: M dot A dot Dahlhaus at t-online dot de -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: all PHP Version: 4.3.0-pre2 New Comment: Already implemented (PHP 5). Documented here: http://php.net/language.oop5.magic Previous Comments: [2002-11-10 09:07:56] M dot A dot Dahlhaus at t-online dot de this is not a bug post ... it's a request for a feature ... wuldn't it be much nicer in extended classes, when serialize and unserialize calling the magic functions of booth classes ( the base and the derived class in the right order ) ? i think this wuld giv the classes a much cleaner outfit ;o) M.A.Dahlhaus -- Edit this bug report at http://bugs.php.net/?id=20339edit=1
#20835 [Opn-Csd]: Why can't I keep php.ini in PHP's directory?
ID: 20835 Updated by: [EMAIL PROTECTED] Reported By: php-xx-nospam at BrazilianTranslation dot net -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Windows 95/ME PHP Version: 4.2.2 New Comment: The installation process is now fully (I hope) explained. And yes, you can keep the php.ini file in the PHP's dir. Previous Comments: [2002-12-05 13:34:31] php-xx-nospam at BrazilianTranslation dot net Hi, I used a Win 95 as test environment for a long time, always successfully. Now I'm using a Win ME machine, and have problems. I hate Win ME, but this is someone else's machine so I have to accept this fate for now. I just moved my entire PHP laboratory to this machine and, when I try to run my scripts, I get this error: 8 Security Alert! The PHP CGI cannot be accessed directly. This PHP CGI binary was compiled with force-cgi-redirect enabled. This means that a page will only be served up if the REDIRECT_STATUS CGI variable is set, e.g. via an Apache Action directive. For more information as to why this behaviour exists, see the manual page for CGI security. (been there) For more information about changing this behaviour or re-enabling this webserver, consult the installation file that came with this distribution, or visit the manual page. (been there, got the T-shirt) 8 I am not using Apache, I'm using Omni HTTPD. It worked just fine in my Win 95. I thought that setting cgi.force_redirect to 0 in php.ini would do the trick, but it doesn't. Well, after a lot of struggle, I tried another thing: move my php.ini file from PHP's directory to the C:\Windows directory. It works! Why? I want to say that I find it very annoying. I remember once I had a similar problem, I gave up and moved the php.ini file from PHP's directory to C:\Windows, but then later I moved the php.ini file back to PHP's directory and it worked fine (?). I don't see why it refused to work now. I found a previous bug report in which you suggest setting the environment variable PHPRC to the desired directory. Setting environment variables in Windows ME is such a pain! But it works. But it is not intuitive at all. Not until I saw that previous bug report was I able to look for PHPRC in the manual and find mention of this possibility. I find it very convenient being able to leave my ini file in PHP's directory and take the whole directory with me wherever I see fit. I wish you would consider, in the future, changing this behavior, determined at compile time, so that it looks for php.ini in PHP's directory first. Then, if it's not found, in the Windows directory. It sounds a lot more intuitive to me. Also, remember that I had php.ini in PHP's directory for a long time in another machine with no knowledge of the PHPRC env var at all. Considering I've seen it work and fail and not been able to identify any pattern that would explain why it works now and fails then, I'd like someone to tell me whether it is a bug, by design and/or if it surprises you knowing that I have been able to actually keep the php.ini file in PHP's directory and get away with it in another machine. Thanks, Luciano ES Santos, SP - Brasil -- Edit this bug report at http://bugs.php.net/?id=20835edit=1
#21102 [Ana-Bgs]: stat, lstat to support 64 bit variants when available
ID: 21102 Updated by: [EMAIL PROTECTED] Reported By: bonebakker at attbi dot com -Status: Analyzed +Status: Bogus Bug Type: Feature/Change Request Operating System: any with large file support PHP Version: 4.4.0-dev New Comment: Problem tracked in #27792. Previous Comments: [2003-01-12 19:01:08] [EMAIL PROTECTED] PHP does not support 64-bit stat'ing. Additionally, PHP only supports signed 32-bit integers (unless your CPU is 64-bit native). PHP could return large file sizes as floating point numbers, but the infrastructure for 64 bit stat is not in place at this time. I'm changing this to a feature request, as this is the expected behaviour. [2003-01-12 18:22:29] bonebakker at attbi dot com Current OS is Solaris 9u1, 64 bit kernel. Checking types.h and stat.h indicates that Solaris uses an off_t type for the stat structure. off_t is either a long, or a longlong_t, defined as long long. It seems to me that the stat structure in Solaris has the correct type. This is also indicated by the fact that I can use the stat(2) functions to stat the file in a simple C-program without any errors (and get the correct file size), Solaris does not have a shell stat command (AFAIK). [2003-01-11 21:35:05] [EMAIL PROTECTED] What version of Solaris are you running? Many unixes (even current ones) use a signed int (32-bit) for the st_size element of the stat struct used by their c-library's stat() function. Try taking a look in stat.h and/or types.h if you'd like to confirm this on your local system. Does the stat command (from the shell) return sensible output when run against this file? [2003-01-11 20:49:47] [EMAIL PROTECTED] Updating - 4.4.0-dev / open [2003-01-11 20:10:51] bonebakker at attbi dot com [unable to edit bug report] latest CVS tarball does not fix the bug, example still fails with latest release. 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/21102 -- Edit this bug report at http://bugs.php.net/?id=21102edit=1
#24075 [Opn-Csd]: PHP 4.3.2 does not find extensions in a folder with spec ..\php\extensions
ID: 24075 Updated by: [EMAIL PROTECTED] Reported By: Sven dot Schnitzke at t-online dot de -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: WIN98SE PHP Version: 4.3.2 New Comment: The manual installation instructions have been updated to _don't_ advise to copy the files to the windows dir. Previous Comments: [2003-06-10 07:59:38] [EMAIL PROTECTED] fine, let's make this a feature request. [2003-06-10 03:44:27] Sven dot Schnitzke at t-online dot de Before we start flaming (_real_ OS, ...) I would like to turn your attention to the first sentence of my message. I will happily be settling with calling it a feature request: Please base relative path specs for extension dir on the folder the executable resides in (and re-think the decision of packing php-cli into another folder, btw. what's the rationale behind that?). There are bulks of user comments and recommendations to put all the dlls into WINSYS folder which is a _very_ bad startegy when it comes to upgrading. And it is caused by this feature. IMHO program extensions do by all means belong to the program and not to the data (in the sense that for PHP scripts are data). Second: (Just curious) I use Apache with mod_php. How do you get any relevant information on this config out of calling PHP.EXE? Last: Using a PIF to start PHP comes from 2 points: I use the pif to customize the command window and to set the current folder so PHP starts in a defined environment. I don't believe anything discussed around this issue has anything to do with the _flavor_ of WIN (98SE is not the only one I use - it just happens to be the one on the machine I first loaded PHP 4.3.2 on) [2003-06-10 03:04:01] [EMAIL PROTECTED] Can't see any bug here.. [2003-06-10 02:38:12] [EMAIL PROTECTED] Sorry, the problem was in go-pear.php. It tries to invoke php.exe -v to learn something of the returned string. With my inst the cli version of php is supposed to be invoked via PIF and cannot be launched directly via exec. It was this 'inner' call that issued the complaints about the missing dlls. It tries to detect the current SAPI. Why do you use a pif do launch php? Then I do not know what is related with PEAR if php launched with a pif does not find some dlls. Comments? btw, have you think about moving to real OS? like something newer than win98se? win2K? pierre [2003-06-09 08:18:15] [EMAIL PROTECTED] I've no idea what PHP 4.4-dev is..last release is 4.3.2.. Reclassified as pear bug. 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/24075 -- Edit this bug report at http://bugs.php.net/?id=24075edit=1
#29879 [Asn-Csd]: strtotime() should return false instead of -1 on failure
ID: 29879
Updated by: [EMAIL PROTECTED]
Reported By: info at peter-thomassen dot de
-Status: Assigned
+Status: Closed
Bug Type: Feature/Change Request
Operating System: any
-PHP Version: Irrelevant
+PHP Version: 5.1
Assigned To: derick
Previous Comments:
[2004-08-30 08:17:43] [EMAIL PROTECTED]
This is going to be changed for 5.1, which will have new datetime
parse/handling stuff.
[2004-08-29 20:15:11] info at peter-thomassen dot de
That's right, but I think -- since PHP5 is not that
established to avoid any minor changes -- you can keep the
old behaviour if zend.ze1_compatibility_mode is set to On
and otherwise use more meaningful return values, can't
you?
I find it kind of sad if there wouldn't be any possibility
to do proper date calculations, but another would be
overkill ...
[2004-08-29 19:01:48] [EMAIL PROTECTED]
This change would break backwards compatibility.
[2004-08-29 00:50:56] info at peter-thomassen dot de
Description:
If an invalid time is specified, strtotime() returns -1.
Because -1 is ambiguous (it could also mean 1969-12-31
23:59:59 UTC), I request to return (bool)false on failure.
BTW:
http://www.gnu.org/software/tar/manual/html_chapter/tar_7.html#SEC117
which is mentioned in the docs allows a number preceded by
an '@' for the time argument to represent seconds since
the epoch. This results in an error -- shall I report
another bug for that?
Thanks!
Reproduce code:
---
?php
var_dump(strtotime('invalid'));
?
Expected result:
bool(false)
Actual result:
--
int(-1)
--
Edit this bug report at http://bugs.php.net/?id=29879edit=1
#33445 [Asn-Csd]: Support ISO 8601 Year number for Week number
ID: 33445
Updated by: [EMAIL PROTECTED]
Reported By: richard dot quadling at bandvulc dot co dot uk
-Status: Assigned
+Status: Closed
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.0.4
Assigned To: derick
New Comment:
Already implemented in PHP 5.1 as date('o').
Previous Comments:
[2005-06-23 13:32:10] [EMAIL PROTECTED]
This will be re-implemented very soon, so stay tuned!
[2005-06-23 10:44:16] richard dot quadling at bandvulc dot co dot uk
Maybe a better solution would be to make the strftime and date
functions the same and to consolidate the code to remove the dependency
on platform specific libraries (e.g. the Windows strftime function does
not support V,G or g).
Alternatively, amend the documentation to indicate which formats are
supported by which platform.
It does seem that both of these functions do the same job and could be
consilidated though.
Richard.
[2005-06-23 10:17:55] richard dot quadling at bandvulc dot co dot uk
Description:
This could also be a fix for a Will Not Fix bug #22711.
On Windows, the strftime() function does not support %V, %G or %g.
The date() function supports 'W' which deals with %V (if you get what I
mean), but when the week number is 52 or 53 and you are looking at a
January date, getting the correct year also would be useful.
I've included below a CVS diff datetime.c.
I don't know who to send it to.
date('V') emulates strftime('%G');
date('v') emulates strftime('%g');
I've also rewritten the date('W') code to combine with V and v.
Index: datetime.c
===
RCS file: /repository/php-src/ext/standard/datetime.c,v
retrieving revision 1.129
diff -u -r1.129 datetime.c
--- datetime.c 19 Jun 2005 22:15:26 - 1.129
+++ datetime.c 23 Jun 2005 08:00:48 -
@@ -288,7 +288,7 @@
pval **format, **timestamp;
time_t the_time;
struct tm *ta, tmbuf;
- int i, size = 0, length, h, beat, fd, wd, yd, wk;
+ int i, size = 0, length, h, beat, fd, wd, yd, wk, yr;
char tmp_buff[32];
#if !HAVE_TM_GMTOFF
long tzone;
@@ -382,6 +382,7 @@
size += 5;
break;
case 'Y': /* year, numeric, 4 digits */
+ case 'V': /* ISO-8601 year number of
year, numeric, 4 digits */
size += 4;
break;
case 'M': /* month, textual, 3 letters */
@@ -406,6 +407,7 @@
case 'S': /* standard english suffix for
the day of the month
(e.g. 3rd, 2nd, etc) */
case 't': /* days in current month */
case 'W': /* ISO-8601 week number of
year, weeks starting on
Monday */
+ case 'v': /* ISO-8601 year number of
year, numeric, 2 digits */
size += 2;
break;
case '\\':
@@ -641,27 +643,67 @@
strcat(Z_STRVAL_P(return_value), tmp_buff);
break;
case 'W': /* ISO-8601 week number of
year, weeks starting on
Monday */
- wd = ta-tm_wday == 0 ? 6 : ta-tm_wday - 1; /*
weekday */
- yd = ta-tm_yday + 1;
/* days since January 1st */
-
- fd = (7 + wd - yd % 7+ 1) % 7;
/* weekday (1st January) */
-
- /* week is a last year week (52 or 53) */
- if ((yd = 7 - fd) fd 3){
- wk = (fd == 4 || (fd == 5
isleap((ta-tm_year + YEAR_BASE -
1 ? 53 : 52;
- }
- /* week is a next year week (1) */
- else if (isleap((ta-tm_year+YEAR_BASE)) + 365
- yd 3 - wd){
- wk = 1;
+ case 'V': /* ISO-8601 year number of
year, numeric, 4 digits */
+ case 'v': /* ISO-8601 year number of
year, numeric, 2 digits */
+ yr = ta-tm_year + YEAR_BASE;
+ yd = ta-tm_yday;
+ wd = ta-tm_wday;
+ while(1) {
+ int len, bot, top;
+
#33445 [Csd-Asn]: Support ISO 8601 Year number for Week number
ID: 33445
Updated by: [EMAIL PROTECTED]
Reported By: richard dot quadling at bandvulc dot co dot uk
-Status: Closed
+Status: Assigned
Bug Type: Feature/Change Request
Operating System: All
PHP Version: 5.0.4
Assigned To: derick
New Comment:
The fix up of strftime() is not done though - please keep it assigned.
Previous Comments:
[2005-08-11 20:15:14] [EMAIL PROTECTED]
Already implemented in PHP 5.1 as date('o').
[2005-06-23 13:32:10] [EMAIL PROTECTED]
This will be re-implemented very soon, so stay tuned!
[2005-06-23 10:44:16] richard dot quadling at bandvulc dot co dot uk
Maybe a better solution would be to make the strftime and date
functions the same and to consolidate the code to remove the dependency
on platform specific libraries (e.g. the Windows strftime function does
not support V,G or g).
Alternatively, amend the documentation to indicate which formats are
supported by which platform.
It does seem that both of these functions do the same job and could be
consilidated though.
Richard.
[2005-06-23 10:17:55] richard dot quadling at bandvulc dot co dot uk
Description:
This could also be a fix for a Will Not Fix bug #22711.
On Windows, the strftime() function does not support %V, %G or %g.
The date() function supports 'W' which deals with %V (if you get what I
mean), but when the week number is 52 or 53 and you are looking at a
January date, getting the correct year also would be useful.
I've included below a CVS diff datetime.c.
I don't know who to send it to.
date('V') emulates strftime('%G');
date('v') emulates strftime('%g');
I've also rewritten the date('W') code to combine with V and v.
Index: datetime.c
===
RCS file: /repository/php-src/ext/standard/datetime.c,v
retrieving revision 1.129
diff -u -r1.129 datetime.c
--- datetime.c 19 Jun 2005 22:15:26 - 1.129
+++ datetime.c 23 Jun 2005 08:00:48 -
@@ -288,7 +288,7 @@
pval **format, **timestamp;
time_t the_time;
struct tm *ta, tmbuf;
- int i, size = 0, length, h, beat, fd, wd, yd, wk;
+ int i, size = 0, length, h, beat, fd, wd, yd, wk, yr;
char tmp_buff[32];
#if !HAVE_TM_GMTOFF
long tzone;
@@ -382,6 +382,7 @@
size += 5;
break;
case 'Y': /* year, numeric, 4 digits */
+ case 'V': /* ISO-8601 year number of
year, numeric, 4 digits */
size += 4;
break;
case 'M': /* month, textual, 3 letters */
@@ -406,6 +407,7 @@
case 'S': /* standard english suffix for
the day of the month
(e.g. 3rd, 2nd, etc) */
case 't': /* days in current month */
case 'W': /* ISO-8601 week number of
year, weeks starting on
Monday */
+ case 'v': /* ISO-8601 year number of
year, numeric, 2 digits */
size += 2;
break;
case '\\':
@@ -641,27 +643,67 @@
strcat(Z_STRVAL_P(return_value), tmp_buff);
break;
case 'W': /* ISO-8601 week number of
year, weeks starting on
Monday */
- wd = ta-tm_wday == 0 ? 6 : ta-tm_wday - 1; /*
weekday */
- yd = ta-tm_yday + 1;
/* days since January 1st */
-
- fd = (7 + wd - yd % 7+ 1) % 7;
/* weekday (1st January) */
-
- /* week is a last year week (52 or 53) */
- if ((yd = 7 - fd) fd 3){
- wk = (fd == 4 || (fd == 5
isleap((ta-tm_year + YEAR_BASE -
1 ? 53 : 52;
- }
- /* week is a next year week (1) */
- else if (isleap((ta-tm_year+YEAR_BASE)) + 365
- yd 3 - wd){
- wk = 1;
+ case 'V': /* ISO-8601 year number of
year, numeric, 4 digits */
+ case 'v': /* ISO-8601 year number of
year, numeric, 2 digits */
+ yr = ta-tm_year + YEAR_BASE;
+ yd
#24211 [Opn-Bgs]: PHP.ini file installed to improper location.
ID: 24211 Updated by: [EMAIL PROTECTED] Reported By: webmaster at cyberdogtech dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Windows 2000 Server PHP Version: 4.3.2 New Comment: Same as #23980. Previous Comments: [2003-06-16 17:21:06] webmaster at cyberdogtech dot com Description: I just installed the Installshield binary of PHP 4.3.2 on my Windows 2000 server running IIS 5.0. The configuration file (php.ini) should have been placed in the system folder (C:\WINNT). Instead, InstallShield placed it in the folder C:\Documents and Settings\Administrator\WINDOWS. This was problematic as the executable could not find the ini file to read it. Since it was IIS, I could not run phpInfo() to detect this, instead I was presented by the The PHP CGI cannot be accessed directly. error since the default value is set to 1. This made locating the source of the problem (the mislocated ini file) exceedingly difficult. -- Edit this bug report at http://bugs.php.net/?id=24211edit=1
#24411 [Opn-Bgs]: 2 Gb filesize limit
ID: 24411 Updated by: [EMAIL PROTECTED] Reported By: domisse at iap dot fr -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.3.2 New Comment: Problem tracked in #27792. Previous Comments: [2003-07-02 09:09:04] domisse at iap dot fr Need to get one first to install the next php release ! ;) [2003-07-02 08:38:25] [EMAIL PROTECTED] Yup :) Feel free to sponsor me with a 64bit machine :) [2003-07-02 08:27:36] domisse at iap dot fr Do you mean you are still using those old 32bits machine ? ;) [2003-07-02 08:22:06] [EMAIL PROTECTED] Don't expect this to be added in the near future... it will probably wait until we all use 64bit CPUs ;) [2003-07-02 08:04:09] domisse at iap dot fr Thanks your help :) Will check the Changelog file in the next release. 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/24411 -- Edit this bug report at http://bugs.php.net/?id=24411edit=1
#26975 [Opn]: locking support in file_get_contents / file_put_contents
ID: 26975 Updated by: [EMAIL PROTECTED] Reported By: magg at mail dot com Status: Open Bug Type: Feature/Change Request Operating System: Linux -PHP Version: Irrelevant +PHP Version: * New Comment: file_put_contents exclusive lock was implemented (PHP 5.1). not sure about the shared lock in file_get_contents(). Previous Comments: [2004-01-20 06:55:24] magg at mail dot com Description: It would be very nice to have a add a flag like USE_FLOCK or something on these functions. Default shared on get and exclusive on put. -- Edit this bug report at http://bugs.php.net/?id=26975edit=1
#34084 [NEW]: RecursiveFilterIterator causes fatal error
From: [EMAIL PROTECTED] Operating system: FreeBSD 5.3-RELEASE PHP version: 5CVS-2005-08-11 (dev) PHP Bug Type: SPL related Bug description: RecursiveFilterIterator causes fatal error Description: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods... Reproduce code: --- php -v Expected result: PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies Actual result: -- PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies -- Edit bug report at http://bugs.php.net/?id=34084edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34084r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34084r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34084r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34084r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34084r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34084r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34084r=needscript Try newer version: http://bugs.php.net/fix.php?id=34084r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34084r=support Expected behavior: http://bugs.php.net/fix.php?id=34084r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34084r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34084r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34084r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34084r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34084r=dst IIS Stability: http://bugs.php.net/fix.php?id=34084r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34084r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34084r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34084r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34084r=mysqlcfg
#34084 [Opn-Fbk]: RecursiveFilterIterator causes fatal error
ID: 34084 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: SPL related Operating System: FreeBSD 5.3-RELEASE PHP Version: 5CVS-2005-08-11 (dev) New Comment: Works fine here. Try it with clean checkout. Previous Comments: [2005-08-11 19:59:20] [EMAIL PROTECTED] Description: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods... Reproduce code: --- php -v Expected result: PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies Actual result: -- PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=34084edit=1
#34075 [Opn]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com Status: Open Bug Type: Unknown/Other Function Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: More info: === BUILD ENVIRONMENT === OS: Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT \ 2005 i686 Automake: automake (GNU automake) 1.6.3 Written by Tom Tromey [EMAIL PROTECTED]. Copyright 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Autoconf: autoconf (GNU Autoconf) 2.57 Written by David J. MacKenzie and Akim Demaille. Previous Comments: [2005-08-11 19:06:18] RVaughn at pheedo dot com Shell is RHEL 3.0 /bin/bash. # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php # ls -al `echo $TEST_PHP_EXECUTABLE` -rwxr-xr-x1 root root 6254005 Aug 10 21:50 /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php From the Makefile: TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) top_builddir = /usr/src/redhat/SOURCES/php-4.3.8 SAPI_CLI_PATH = sapi/cli/php The Makefile matches this, which is where the unstriped executable is: # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php As per Tony's suggestion (thanks, but doesn't work, sorry I forgot that I also tried 'run-tests.php'): # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/src/redhat/SOURCES/php-4.3.8 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.8 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/imap.ini,/etc/php.d/ldap.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] Output from this run is the same: # more ext/standard/tests/file/bug22414.out HELLO Does not work I haven't tried the CVS snapshot because we've given up on getting PHP 4.4 to build and work on RHEL 3.0 for now. The fact that this test fails on three different RHEL 3.0 servers w/three different PHP versions (4.3.8, 4.3.11, 4.4) is what makes me think there's a problem with this script on RHEL 3.0. The test script is the same in all three distributions, and it fails in the same way on all three, and I've written some simple passthru() tests myself and the function seems to work just fine, it's the test script. Could be that passthru() is failing on RHEL 3.0 for all these versions as my own tests are pretty simple. Thanks! [2005-08-11 11:24:51] [EMAIL PROTECTED] ./sapi/cli/php ext/standard/tests/file/bug22414.phpt Ugh..Don't do it, please. These tests should not be run directly. You must use run-tests.php for running them. Please try to this: TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt [2005-08-11 11:22:30] [EMAIL PROTECTED] The problem is with TEST_PHP_EXECUTABLE environment variable being set to something wrong? Are you setting it yourself? What shell are you using? What is it set to in Makefile ? Have you tried latest CVS snapshot? [2005-08-11 01:41:40] RVaughn at pheedo dot com I have run this test with 'make test' as part of the whole suite, and also directly with: # ./sapi/cli/php -c /etc/php.ini ext/standard/tests/file/bug22414.phpt and # ./sapi/cli/php ext/standard/tests/file/bug22414.phpt Fails in all three cases for PHP 4.4, 4.3.11, and 4.3.8. The first test works, the second one which uses md5_file() to create a hash over the php executable itself, fails with the errors I reported. I suspect it's something particular to RHEL 3.0 but have not had a chance to test on a Fedora Core 2 system yet. [2005-08-10 23:34:21] [EMAIL PROTECTED] How do you run this test? 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/34075 -- Edit this bug report at http://bugs.php.net/?id=34075edit=1
#34084 [Fbk-Opn]: RecursiveFilterIterator causes fatal error
ID: 34084 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: SPL related Operating System: FreeBSD 5.3-RELEASE PHP Version: 5CVS-2005-08-11 (dev) New Comment: $ cvs -d :pserver:[EMAIL PROTECTED]:/repository checkout php-src $ cd php-src/ $ ./buildconf --force $ ./configure --with-zend-vm=GOTO --enable-debug --with-apxs2=/usr/local/sbin/apxs --prefix=/usr/home/dev $ make $ ./sapi/cli/php -v PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 20:55:00) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies Previous Comments: [2005-08-11 20:28:21] [EMAIL PROTECTED] Works fine here. Try it with clean checkout. [2005-08-11 19:59:20] [EMAIL PROTECTED] Description: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods... Reproduce code: --- php -v Expected result: PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies Actual result: -- PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=34084edit=1
#34071 [Fbk-Opn]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071 User updated by: dennis at nocertainty dot com Reported By: dennis at nocertainty dot com -Status: Feedback +Status: Open Bug Type: Output Control Operating System: Windows XP SP2 PHP Version: 5CVS-2005-08-10 (dev) New Comment: I found someone else who has the same problem as me: http://www.sitepoint.com/forums/showpost.php?p=2093119postcount=5 However, I can't find any specific information. I looked through my Apache error log, and the only thing I found was: [Wed Aug 10 18:59:56 2005] [error] [client 127.0.0.1] request failed: erroneous characters after protocol string: \\xff\\xfb\\x1f\\xff\\xfb \\xff\\xfb\\x18\\xff\\xfb'\\xff\\xfd\\x01\\xff\\xfb\\x03\\xff\\xfd\\x03GET /gzip2.php HTTP/1.0 [Wed Aug 10 19:00:21 2005] [error] [client 127.0.0.1] request failed: erroneous characters after protocol string: \\xff\\xfb\\x1f\\xff\\xfb \\xff\\xfb\\x18\\xff\\xfb'\\xff\\xfd\\x01\\xff\\xfb\\x03\\xff\\xfd\\x03GET /gzip2.php HTTP/1.0 But I'm not sure if that's entirely relevant. But there's nothing more that's related to it. Previous Comments: [2005-08-10 20:12:21] [EMAIL PROTECTED] Then provide more info about it; look into the apache logs; try on another server and with another PHP version etc etc. As I've already said, it works perfectly here. [2005-08-10 19:47:05] dennis at nocertainty dot com Also, I disabled PHP4 in my http.conf file, and it still doesn't work properly in PHP5Dev. So I still believe there's a bug in PHP5. [2005-08-10 19:44:50] dennis at nocertainty dot com Rasmus is right. The telnet thing works because ob_gzhandler doesn't do anything. As soon as a specify a Content-Encoding: gzip header, nothing gets displayed again. So it's not my browser that's causing the problem. [2005-08-10 19:21:08] [EMAIL PROTECTED] Not PHP problem then. [2005-08-10 19:20:43] [EMAIL PROTECTED] That's not a very good test since ob_gzhandler checks the request's accept-encoding and since your telnet test didn't specify that you could accept gzip or deflate, then the gzhandler simply didn't do anything. 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/34071 -- Edit this bug report at http://bugs.php.net/?id=34071edit=1
#34084 [Opn-Asn]: RecursiveFilterIterator causes fatal error
ID: 34084 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: SPL related Operating System: FreeBSD 5.3-RELEASE PHP Version: 5CVS-2005-08-11 (dev) -Assigned To: +Assigned To: helly New Comment: Aha, so actually the problem was with my checkout =) Marcus, fix your last patch, please. Previous Comments: [2005-08-11 20:53:16] [EMAIL PROTECTED] $ cvs -d :pserver:[EMAIL PROTECTED]:/repository checkout php-src $ cd php-src/ $ ./buildconf --force $ ./configure --with-zend-vm=GOTO --enable-debug --with-apxs2=/usr/local/sbin/apxs --prefix=/usr/home/dev $ make $ ./sapi/cli/php -v PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 20:55:00) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies [2005-08-11 20:28:21] [EMAIL PROTECTED] Works fine here. Try it with clean checkout. [2005-08-11 19:59:20] [EMAIL PROTECTED] Description: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods... Reproduce code: --- php -v Expected result: PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies Actual result: -- PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=34084edit=1
#34084 [Asn]: RecursiveFilterIterator causes fatal error
ID: 34084 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: SPL related Operating System: FreeBSD 5.3-RELEASE PHP Version: 5CVS-2005-08-11 (dev) Assigned To: helly New Comment: I cannot reproduce. And i had the exact same behavior before i fixed the engine. So please be sure to cvs up your engine. At least zend_compile.c needs to be updated. Previous Comments: [2005-08-11 21:09:19] [EMAIL PROTECTED] Aha, so actually the problem was with my checkout =) Marcus, fix your last patch, please. [2005-08-11 20:53:16] [EMAIL PROTECTED] $ cvs -d :pserver:[EMAIL PROTECTED]:/repository checkout php-src $ cd php-src/ $ ./buildconf --force $ ./configure --with-zend-vm=GOTO --enable-debug --with-apxs2=/usr/local/sbin/apxs --prefix=/usr/home/dev $ make $ ./sapi/cli/php -v PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 20:55:00) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies [2005-08-11 20:28:21] [EMAIL PROTECTED] Works fine here. Try it with clean checkout. [2005-08-11 19:59:20] [EMAIL PROTECTED] Description: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods... Reproduce code: --- php -v Expected result: PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies Actual result: -- PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=34084edit=1
#34084 [Asn]: RecursiveFilterIterator causes fatal error
ID: 34084 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: SPL related -Operating System: FreeBSD 5.3-RELEASE +Operating System: * PHP Version: 5CVS-2005-08-11 (dev) Assigned To: helly New Comment: cvs ci for zend was blocked. Previous Comments: [2005-08-11 22:11:39] [EMAIL PROTECTED] I cannot reproduce. And i had the exact same behavior before i fixed the engine. So please be sure to cvs up your engine. At least zend_compile.c needs to be updated. [2005-08-11 21:09:19] [EMAIL PROTECTED] Aha, so actually the problem was with my checkout =) Marcus, fix your last patch, please. [2005-08-11 20:53:16] [EMAIL PROTECTED] $ cvs -d :pserver:[EMAIL PROTECTED]:/repository checkout php-src $ cd php-src/ $ ./buildconf --force $ ./configure --with-zend-vm=GOTO --enable-debug --with-apxs2=/usr/local/sbin/apxs --prefix=/usr/home/dev $ make $ ./sapi/cli/php -v PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 20:55:00) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies [2005-08-11 20:28:21] [EMAIL PROTECTED] Works fine here. Try it with clean checkout. [2005-08-11 19:59:20] [EMAIL PROTECTED] Description: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods... Reproduce code: --- php -v Expected result: PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies Actual result: -- PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 04:38:23) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies -- Edit this bug report at http://bugs.php.net/?id=34084edit=1
#34084 [Asn-Csd]: RecursiveFilterIterator causes fatal error
ID: 34084 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: SPL related Operating System: * PHP Version: 5CVS-2005-08-11 (dev) Assigned To: helly New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2005-08-11 22:40:04] [EMAIL PROTECTED] cvs ci for zend was blocked. [2005-08-11 22:11:39] [EMAIL PROTECTED] I cannot reproduce. And i had the exact same behavior before i fixed the engine. So please be sure to cvs up your engine. At least zend_compile.c needs to be updated. [2005-08-11 21:09:19] [EMAIL PROTECTED] Aha, so actually the problem was with my checkout =) Marcus, fix your last patch, please. [2005-08-11 20:53:16] [EMAIL PROTECTED] $ cvs -d :pserver:[EMAIL PROTECTED]:/repository checkout php-src $ cd php-src/ $ ./buildconf --force $ ./configure --with-zend-vm=GOTO --enable-debug --with-apxs2=/usr/local/sbin/apxs --prefix=/usr/home/dev $ make $ ./sapi/cli/php -v PHP Fatal error: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in Unknown on line 0 br / bFatal error/b: Class RecursiveFilterIterator contains 1 abstract method and must therefore be declared abstract or implement the remaining methods (FilterIterator::accept) in bUnknown/b on line b0/bbr / PHP 6.0.0-dev (cli) (built: Aug 11 2005 20:55:00) (DEBUG) Copyright (c) 1997-2005 The PHP Group Zend Engine v2.1.0-dev, Copyright (c) 1998-2005 Zend Technologies [2005-08-11 20:28:21] [EMAIL PROTECTED] Works fine here. Try it with clean checkout. 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/34084 -- Edit this bug report at http://bugs.php.net/?id=34084edit=1
#34078 [Asn]: Reflection API problems in methods with boolean or null default values
ID: 34078
User updated by: leon at lost dot co dot nz
Reported By: leon at lost dot co dot nz
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Debian Sarge (2.6.12 kernel)
PHP Version: 5CVS-2005-08-11 (dev)
Assigned To: tony2001
New Comment:
Great work!
I can understand you having to wait to merge into the 5.5/6.0 series,
but it would be great if the fix could be pushed into just the 5.1 tree
before the next release (beta4? rc4?).
We -- like many other companies -- are waiting for the 5.1 release to
move everything from PHP4 to PHP5. Unfortunately this bug is a 'show
stopper' for us right now.
Previous Comments:
[2005-08-11 12:50:22] [EMAIL PROTECTED]
The fix is ready, but we have to wait for Andrey Dmitry to finish
merging of Unicode patches.
[2005-08-11 03:37:24] leon at lost dot co dot nz
Description:
This problem came up when moving our homebrew 'PHPDoc' type class to
PHP5.1. When built with --enable-debug PHP throws up warnings up when
the class to be documented ('A' below) contains methods with default
values that are either NULL or boolean
In the code snippet below we get two warnings, one for each default
parameter. Changing the default values to a string or number (even
zero) eliminates the warnings.
This is a serious problem for us. When documenting some of our bigger
classes we have seen lots of 'odd' behaviour, including permanent 100%
CPU usage by Apache! It has taken *days* to track down the problem to
the snippet below. If there is anything elso I can do to help fix it
please let me know...
Reproduce code:
---
$r = new ReflectionClass('A');
$methods = $r-getMethods();
foreach($methods as $method)
{
$parameters = $method-getParameters();
foreach($parameters as $p)
{
if($p-isDefaultValueAvailable())
$p-getDefaultValue();
}
}
class A
{
function foo($p=null, $q=false)
{
}
}
Expected result:
No output at all -- I've trimed all the output code out.
Actual result:
--
$ php bug2.php
Warning: String is not zero-terminated (ZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x08514F30
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
5 bytes)
End: OK
---
Warning: String is not zero-terminated (ZZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x085150C8
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
6 bytes)
End: OK
---
--
Edit this bug report at http://bugs.php.net/?id=34078edit=1
#34075 [Opn-Fbk]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: All your output here shows version 4.3.8. Please do the tests REALLY with PHP 4.4.0 or rather with the latest CVS snapshot of PHP 5.1 (http://snaps.php.net/php5-latest.tar.gz) Previous Comments: [2005-08-11 20:43:33] RVaughn at pheedo dot com More info: === BUILD ENVIRONMENT === OS: Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT \ 2005 i686 Automake: automake (GNU automake) 1.6.3 Written by Tom Tromey [EMAIL PROTECTED]. Copyright 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Autoconf: autoconf (GNU Autoconf) 2.57 Written by David J. MacKenzie and Akim Demaille. [2005-08-11 19:06:18] RVaughn at pheedo dot com Shell is RHEL 3.0 /bin/bash. # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php # ls -al `echo $TEST_PHP_EXECUTABLE` -rwxr-xr-x1 root root 6254005 Aug 10 21:50 /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php From the Makefile: TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) top_builddir = /usr/src/redhat/SOURCES/php-4.3.8 SAPI_CLI_PATH = sapi/cli/php The Makefile matches this, which is where the unstriped executable is: # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php As per Tony's suggestion (thanks, but doesn't work, sorry I forgot that I also tried 'run-tests.php'): # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/src/redhat/SOURCES/php-4.3.8 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.8 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/imap.ini,/etc/php.d/ldap.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] Output from this run is the same: # more ext/standard/tests/file/bug22414.out HELLO Does not work I haven't tried the CVS snapshot because we've given up on getting PHP 4.4 to build and work on RHEL 3.0 for now. The fact that this test fails on three different RHEL 3.0 servers w/three different PHP versions (4.3.8, 4.3.11, 4.4) is what makes me think there's a problem with this script on RHEL 3.0. The test script is the same in all three distributions, and it fails in the same way on all three, and I've written some simple passthru() tests myself and the function seems to work just fine, it's the test script. Could be that passthru() is failing on RHEL 3.0 for all these versions as my own tests are pretty simple. Thanks! [2005-08-11 11:24:51] [EMAIL PROTECTED] ./sapi/cli/php ext/standard/tests/file/bug22414.phpt Ugh..Don't do it, please. These tests should not be run directly. You must use run-tests.php for running them. Please try to this: TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt [2005-08-11 11:22:30] [EMAIL PROTECTED] The problem is with TEST_PHP_EXECUTABLE environment variable being set to something wrong? Are you setting it yourself? What shell are you using? What is it set to in Makefile ? Have you tried latest CVS snapshot? [2005-08-11 01:41:40] RVaughn at pheedo dot com I have run this test with 'make test' as part of the whole suite, and also directly with: # ./sapi/cli/php -c /etc/php.ini ext/standard/tests/file/bug22414.phpt and # ./sapi/cli/php ext/standard/tests/file/bug22414.phpt Fails in all three cases for PHP 4.4, 4.3.11, and 4.3.8. The first test works, the second one which uses md5_file() to create a hash over the php executable itself, fails with the errors I reported. I suspect it's something particular to RHEL 3.0 but have not had a chance to test on a Fedora Core 2 system yet. The remainder of the comments for this report are too long. To view
#34071 [Opn-Fbk]: buffering is destroyed when using ob_gzhandler and ob_clean
ID: 34071 Updated by: [EMAIL PROTECTED] Reported By: dennis at nocertainty dot com -Status: Open +Status: Feedback Bug Type: Output Control Operating System: Windows XP SP2 PHP Version: 5CVS-2005-08-10 (dev) New Comment: 1) Check your php.ini settings (how they differ to whatever you used as base for your php.ini, -dist or -recommended) 2) Set error_reporting to E_ALL and try again.. Previous Comments: [2005-08-11 20:54:56] dennis at nocertainty dot com I found someone else who has the same problem as me: http://www.sitepoint.com/forums/showpost.php?p=2093119postcount=5 However, I can't find any specific information. I looked through my Apache error log, and the only thing I found was: [Wed Aug 10 18:59:56 2005] [error] [client 127.0.0.1] request failed: erroneous characters after protocol string: \\xff\\xfb\\x1f\\xff\\xfb \\xff\\xfb\\x18\\xff\\xfb'\\xff\\xfd\\x01\\xff\\xfb\\x03\\xff\\xfd\\x03GET /gzip2.php HTTP/1.0 [Wed Aug 10 19:00:21 2005] [error] [client 127.0.0.1] request failed: erroneous characters after protocol string: \\xff\\xfb\\x1f\\xff\\xfb \\xff\\xfb\\x18\\xff\\xfb'\\xff\\xfd\\x01\\xff\\xfb\\x03\\xff\\xfd\\x03GET /gzip2.php HTTP/1.0 But I'm not sure if that's entirely relevant. But there's nothing more that's related to it. [2005-08-10 20:12:21] [EMAIL PROTECTED] Then provide more info about it; look into the apache logs; try on another server and with another PHP version etc etc. As I've already said, it works perfectly here. [2005-08-10 19:47:05] dennis at nocertainty dot com Also, I disabled PHP4 in my http.conf file, and it still doesn't work properly in PHP5Dev. So I still believe there's a bug in PHP5. [2005-08-10 19:44:50] dennis at nocertainty dot com Rasmus is right. The telnet thing works because ob_gzhandler doesn't do anything. As soon as a specify a Content-Encoding: gzip header, nothing gets displayed again. So it's not my browser that's causing the problem. [2005-08-10 19:21:08] [EMAIL PROTECTED] Not PHP problem then. 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/34071 -- Edit this bug report at http://bugs.php.net/?id=34071edit=1
#34078 [Asn]: Reflection API problems in methods with boolean or null default values
ID: 34078
Updated by: [EMAIL PROTECTED]
Reported By: leon at lost dot co dot nz
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Debian Sarge (2.6.12 kernel)
PHP Version: 5CVS-2005-08-11 (dev)
Assigned To: tony2001
New Comment:
Okay, I discussed it with Marcus and committed the fix to 5.0 5.1
branches.
I'll commit it to 6.0 too when I'll be able to do it.
Previous Comments:
[2005-08-11 22:47:22] leon at lost dot co dot nz
Great work!
I can understand you having to wait to merge into the 5.5/6.0 series,
but it would be great if the fix could be pushed into just the 5.1 tree
before the next release (beta4? rc4?).
We -- like many other companies -- are waiting for the 5.1 release to
move everything from PHP4 to PHP5. Unfortunately this bug is a 'show
stopper' for us right now.
[2005-08-11 12:50:22] [EMAIL PROTECTED]
The fix is ready, but we have to wait for Andrey Dmitry to finish
merging of Unicode patches.
[2005-08-11 03:37:24] leon at lost dot co dot nz
Description:
This problem came up when moving our homebrew 'PHPDoc' type class to
PHP5.1. When built with --enable-debug PHP throws up warnings up when
the class to be documented ('A' below) contains methods with default
values that are either NULL or boolean
In the code snippet below we get two warnings, one for each default
parameter. Changing the default values to a string or number (even
zero) eliminates the warnings.
This is a serious problem for us. When documenting some of our bigger
classes we have seen lots of 'odd' behaviour, including permanent 100%
CPU usage by Apache! It has taken *days* to track down the problem to
the snippet below. If there is anything elso I can do to help fix it
please let me know...
Reproduce code:
---
$r = new ReflectionClass('A');
$methods = $r-getMethods();
foreach($methods as $method)
{
$parameters = $method-getParameters();
foreach($parameters as $p)
{
if($p-isDefaultValueAvailable())
$p-getDefaultValue();
}
}
class A
{
function foo($p=null, $q=false)
{
}
}
Expected result:
No output at all -- I've trimed all the output code out.
Actual result:
--
$ php bug2.php
Warning: String is not zero-terminated (ZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x08514F30
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
5 bytes)
End: OK
---
Warning: String is not zero-terminated (ZZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x085150C8
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
6 bytes)
End: OK
---
--
Edit this bug report at http://bugs.php.net/?id=34078edit=1
#34078 [Asn]: Reflection API problems in methods with boolean or null default values
ID: 34078
User updated by: leon at lost dot co dot nz
Reported By: leon at lost dot co dot nz
Status: Assigned
Bug Type: Scripting Engine problem
Operating System: Debian Sarge (2.6.12 kernel)
PHP Version: 5CVS-2005-08-11 (dev)
Assigned To: tony2001
New Comment:
As Homer would say: Woo-hoo! You absolutely rock! I just can't wait
for the next 5.1 snapshot... :-)
Previous Comments:
[2005-08-11 23:18:55] [EMAIL PROTECTED]
Okay, I discussed it with Marcus and committed the fix to 5.0 5.1
branches.
I'll commit it to 6.0 too when I'll be able to do it.
[2005-08-11 22:47:22] leon at lost dot co dot nz
Great work!
I can understand you having to wait to merge into the 5.5/6.0 series,
but it would be great if the fix could be pushed into just the 5.1 tree
before the next release (beta4? rc4?).
We -- like many other companies -- are waiting for the 5.1 release to
move everything from PHP4 to PHP5. Unfortunately this bug is a 'show
stopper' for us right now.
[2005-08-11 12:50:22] [EMAIL PROTECTED]
The fix is ready, but we have to wait for Andrey Dmitry to finish
merging of Unicode patches.
[2005-08-11 03:37:24] leon at lost dot co dot nz
Description:
This problem came up when moving our homebrew 'PHPDoc' type class to
PHP5.1. When built with --enable-debug PHP throws up warnings up when
the class to be documented ('A' below) contains methods with default
values that are either NULL or boolean
In the code snippet below we get two warnings, one for each default
parameter. Changing the default values to a string or number (even
zero) eliminates the warnings.
This is a serious problem for us. When documenting some of our bigger
classes we have seen lots of 'odd' behaviour, including permanent 100%
CPU usage by Apache! It has taken *days* to track down the problem to
the snippet below. If there is anything elso I can do to help fix it
please let me know...
Reproduce code:
---
$r = new ReflectionClass('A');
$methods = $r-getMethods();
foreach($methods as $method)
{
$parameters = $method-getParameters();
foreach($parameters as $p)
{
if($p-isDefaultValueAvailable())
$p-getDefaultValue();
}
}
class A
{
function foo($p=null, $q=false)
{
}
}
Expected result:
No output at all -- I've trimed all the output code out.
Actual result:
--
$ php bug2.php
Warning: String is not zero-terminated (ZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x08514F30
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
5 bytes)
End: OK
---
Warning: String is not zero-terminated (ZZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x085150C8
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
6 bytes)
End: OK
---
--
Edit this bug report at http://bugs.php.net/?id=34078edit=1
#34078 [Asn-Csd]: Reflection API problems in methods with boolean or null default values
ID: 34078
Updated by: [EMAIL PROTECTED]
Reported By: leon at lost dot co dot nz
-Status: Assigned
+Status: Closed
Bug Type: Scripting Engine problem
Operating System: Debian Sarge (2.6.12 kernel)
PHP Version: 5CVS-2005-08-11 (dev)
Assigned To: tony2001
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2005-08-11 23:22:38] leon at lost dot co dot nz
As Homer would say: Woo-hoo! You absolutely rock! I just can't wait
for the next 5.1 snapshot... :-)
[2005-08-11 23:18:55] [EMAIL PROTECTED]
Okay, I discussed it with Marcus and committed the fix to 5.0 5.1
branches.
I'll commit it to 6.0 too when I'll be able to do it.
[2005-08-11 22:47:22] leon at lost dot co dot nz
Great work!
I can understand you having to wait to merge into the 5.5/6.0 series,
but it would be great if the fix could be pushed into just the 5.1 tree
before the next release (beta4? rc4?).
We -- like many other companies -- are waiting for the 5.1 release to
move everything from PHP4 to PHP5. Unfortunately this bug is a 'show
stopper' for us right now.
[2005-08-11 12:50:22] [EMAIL PROTECTED]
The fix is ready, but we have to wait for Andrey Dmitry to finish
merging of Unicode patches.
[2005-08-11 03:37:24] leon at lost dot co dot nz
Description:
This problem came up when moving our homebrew 'PHPDoc' type class to
PHP5.1. When built with --enable-debug PHP throws up warnings up when
the class to be documented ('A' below) contains methods with default
values that are either NULL or boolean
In the code snippet below we get two warnings, one for each default
parameter. Changing the default values to a string or number (even
zero) eliminates the warnings.
This is a serious problem for us. When documenting some of our bigger
classes we have seen lots of 'odd' behaviour, including permanent 100%
CPU usage by Apache! It has taken *days* to track down the problem to
the snippet below. If there is anything elso I can do to help fix it
please let me know...
Reproduce code:
---
$r = new ReflectionClass('A');
$methods = $r-getMethods();
foreach($methods as $method)
{
$parameters = $method-getParameters();
foreach($parameters as $p)
{
if($p-isDefaultValueAvailable())
$p-getDefaultValue();
}
}
class A
{
function foo($p=null, $q=false)
{
}
}
Expected result:
No output at all -- I've trimed all the output code out.
Actual result:
--
$ php bug2.php
Warning: String is not zero-terminated (ZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x08514F30
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
5 bytes)
End: OK
---
Warning: String is not zero-terminated (ZZÌ*) (source:
/tmp/php5-200508110030/Zend/zend_variables.h:35) in Unknown on line 0
[Thu Aug 11 13:18:58 2005] Script: 'bug2.php'
---
/tmp/php5-200508110030/Zend/zend_variables.h(35) : Block 0x085150C8
status:
/tmp/php5-200508110030/Zend/zend_variables.c(36) : Actual location
(location was relayed)
Beginning: Cached (allocated on Zend/zend_language_scanner.c:4689,
6 bytes)
End: OK
---
--
Edit this bug report at http://bugs.php.net/?id=34078edit=1
#34085 [Opn-Csd]: Missied ')' in 'msg_receive' (sysvmsg.c) proto definition.
ID: 34085 Updated by: [EMAIL PROTECTED] Reported By: flatdev at mail dot ru -Status: Open +Status: Closed -Bug Type: Documentation problem +Bug Type: Unknown/Other Function Operating System: WinXP -PHP Version: Irrelevant +PHP Version: 4.4.0 New Comment: This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. This bug has been fixed in the documentation's XML sources. Since the online and downloadable versions of the documentation need some time to get updated, we would like to ask you to be a bit patient. Thank you for the report, and for helping us make our documentation better. Actually, this is not a docu problem. But thanks, it's fixed in CVS. Previous Comments: [2005-08-11 23:47:59] flatdev at mail dot ru Description: File: ext/sysvmsg/sysvmsg.c Find: proto mixed msg_receive(resource queue, long desiredmsgtype, long msgtype, long maxsize, mixed message [[, bool unserialize=true][, long flags=0[, long errorcode]]] After this ']]]' should be ')'. -- Edit this bug report at http://bugs.php.net/?id=34085edit=1
#34050 [Opn-Fbk]: safe_mode_include_dir isn't honored
ID: 34050
Updated by: [EMAIL PROTECTED]
Reported By: wolfram at schlich dot org
-Status: Open
+Status: Feedback
Bug Type: Safe Mode/open_basedir
Operating System: Linux 2.6.12-gentoo-r4 x86_64
PHP Version: 5CVS-2005-08-09 (dev)
New Comment:
Can't reproduce.
Make sure that /usr/lib/php/Smarty (or any of it's parent dirs) is not
a symbolic link.
Previous Comments:
[2005-08-09 18:16:23] wolfram at schlich dot org
then the comment above safe_mode_include_dir is silly:
; When safe_mode is on, UID/GID checks are bypassed when
; including files from this directory and its subdirectories.
; (directory must also be in include_path or full path must
; be used when including)
it says UID/GID checks are bypassed, so why should I enable
safe_mod_gid then?
I even tried that, result:
--8--
Warning: main() [function.main]: SAFE MODE Restriction in effect. The
script whose uid/gid is 667/888 is not allowed to access
/usr/lib/php/Smarty/Smarty.class.php owned by uid/gid 0/0 in
/home/wschlich/public_html/smartytest/class.MySmarty.inc.php on line
27
--8--
[2005-08-09 18:09:19] [EMAIL PROTECTED]
; By default, Safe Mode does a UID compare check when
; opening files. If you want to relax this to a GID compare,
; then turn on safe_mode_gid.
[2005-08-09 16:56:52] wolfram at schlich dot org
Description:
when safe_mode is active, I want to be able to include files from
certain directories without checking for their UID/GID.
Reproduce code:
---
--8--[ php.ini ]--8--
safe_mode = On
safe_mode_gid = Off
safe_mode_include_dir = /usr/share/php/:/usr/lib/php/
safe_mode_allowed_env_vars = PHP_,LANG,LC_
--8--[ apache vhost config ]--8--
php_value include_path .:/usr/share/php:/usr/lib/php
--8--[ sample php script ]--8--
require_once('/usr/lib/php/Smarty/Smarty.class.php');
--8--
Expected result:
included file, no error message.
Actual result:
--
Warning: main() [function.main]: SAFE MODE Restriction in effect. The
script whose uid is 667 is not allowed to access
/usr/lib/php/Smarty/Smarty.class.php owned by uid 0 in
/home/wschlich/public_html/smartytest/smartytest.php on line 19
--
Edit this bug report at http://bugs.php.net/?id=34050edit=1
#31618 [Opn-Fbk]: is_readable() results based on ownership of calling script, not file
ID: 31618 Updated by: [EMAIL PROTECTED] Reported By: kibab at icehouse dot net -Status: Open +Status: Feedback Bug Type: Filesystem function related Operating System: redhat enterprise PHP Version: 5CVS-2005-03-14 New Comment: Please try this patch: http://tony2001.phpclub.net/dev/tmp/bugs_29840_31618.diff (with the latest snapshot/CVS). Previous Comments: [2005-08-11 15:57:11] kibab at icehouse dot net Yes. I read docs, although I sometimes misunderstand them: Note in my previous post: safe_mode_include_dir = /usr/share/pear Also note that per the documentation (http://www.php.net/manual/en/features.safe-mode.php): safe_mode_include_dir string UID/GID checks are bypassed when including files from this directory and its subdirectories (directory must also be in include_path or full path must including). Certainly $myfilename = '/usr/share/pear/commonfile.php'; is in safe_mode_include dir. Thus, the error message is incorrect and *is* a PHP bug. [2005-08-11 11:10:57] [EMAIL PROTECTED] Did you read something about safe_mode before turning it On? By default, Safe Mode does a UID compare check when opening files. If you want to relax this to a GID compare, then turn on safe_mode_gid. Whether to use UID (FALSE) or GID (TRUE) checking upon file access. (c) http://www.php.net/manual/en/features.safe-mode.php So, it's perfectly fine to have these errors and to have FALSE in is_readable() because you turned safe_mode yourself. This is expected behaviour. [2005-08-11 01:59:45] kibab at icehouse dot net Ok. It says (see http://www.ewu.edu/web/tools/bug31618_3.php): Warning: fopen() [function.fopen]: SAFE MODE Restriction in effect. The script whose uid/gid is 687/694 is not allowed to access /usr/share/pear/commonfile.php owned by uid/gid 0/0 in /var/www/sites/web/tools/bug31618_3.php on line 3 Warning: fopen(/usr/share/pear/commonfile.php) [function.fopen]: failed to open stream: Resource temporarily unavailable in /var/www/sites/web/tools/bug31618_3.php on line 3 [2005-08-10 20:44:05] [EMAIL PROTECTED] Of course, I meant this: ?php $myfilename = '/usr/share/pear/commonfile.php'; fopen($myfilename, 'r'); ? [2005-08-10 20:36:39] [EMAIL PROTECTED] Could you plz also try this: ?php fopen($myfilename, 'r'); ? And post the error message here. Thanks. 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/31618 -- Edit this bug report at http://bugs.php.net/?id=31618edit=1
#29840 [Asn-Fbk]: is_executable does not honor the safe_mode_exec_dir setting
ID: 29840
Updated by: [EMAIL PROTECTED]
Reported By: markus at cultcom dot de
-Status: Assigned
+Status: Feedback
Bug Type: Filesystem function related
Operating System: *
PHP Version: 5CVS, 4CVS (2005-01-04)
-Assigned To: wez
+Assigned To: tony2001
New Comment:
Please try this patch:
http://tony2001.phpclub.net/dev/tmp/bugs_29840_31618.diff
(with the latest snapshot/CVS).
Previous Comments:
[2004-12-12 11:36:05] [EMAIL PROTECTED]
Jani, I sent a patch for this problem to Wez long ago.
The problem is that is_executable() indeed doesn't respect
safe_mode_exec_dir as it should, so I'm assigning this to Wez.
[2004-12-12 02:07:16] [EMAIL PROTECTED]
It works just fine. (it returns false always when in safe-mode..)
[2004-08-25 18:06:12] markus at cultcom dot de
Description:
Seems to be a common problem nobody complains about...
is_executable() does not work in safe_mode!
Some PHP-Projects check for sendmail using this function and don't work
in safe_mode even if sendmail acutally IS executable (i.e. PEAR:
Mail.php).
is_executable() should at least honor the safe_mode_exec_dir directive!
Reproduce code:
---
?php
if( is_executable( /usr/sbin/sendmail ) ) {
print (no probs!\n);
}
else {
print (this really sucks!\n);
}
?
Try with PHP/CGI and suexec + safe_mode
where example-UID != sendmail-UID
Expected result:
true, what else?
Actual result:
--
false.
--
Edit this bug report at http://bugs.php.net/?id=29840edit=1
#34050 [Fbk-Opn]: safe_mode_include_dir isn't honored
ID: 34050
User updated by: wolfram at schlich dot org
Reported By: wolfram at schlich dot org
-Status: Feedback
+Status: Open
Bug Type: Safe Mode/open_basedir
Operating System: Linux 2.6.12-gentoo-r4 x86_64
PHP Version: 5CVS-2005-08-09 (dev)
New Comment:
no symlink...
Previous Comments:
[2005-08-12 00:30:26] [EMAIL PROTECTED]
Can't reproduce.
Make sure that /usr/lib/php/Smarty (or any of it's parent dirs) is not
a symbolic link.
[2005-08-09 18:16:23] wolfram at schlich dot org
then the comment above safe_mode_include_dir is silly:
; When safe_mode is on, UID/GID checks are bypassed when
; including files from this directory and its subdirectories.
; (directory must also be in include_path or full path must
; be used when including)
it says UID/GID checks are bypassed, so why should I enable
safe_mod_gid then?
I even tried that, result:
--8--
Warning: main() [function.main]: SAFE MODE Restriction in effect. The
script whose uid/gid is 667/888 is not allowed to access
/usr/lib/php/Smarty/Smarty.class.php owned by uid/gid 0/0 in
/home/wschlich/public_html/smartytest/class.MySmarty.inc.php on line
27
--8--
[2005-08-09 18:09:19] [EMAIL PROTECTED]
; By default, Safe Mode does a UID compare check when
; opening files. If you want to relax this to a GID compare,
; then turn on safe_mode_gid.
[2005-08-09 16:56:52] wolfram at schlich dot org
Description:
when safe_mode is active, I want to be able to include files from
certain directories without checking for their UID/GID.
Reproduce code:
---
--8--[ php.ini ]--8--
safe_mode = On
safe_mode_gid = Off
safe_mode_include_dir = /usr/share/php/:/usr/lib/php/
safe_mode_allowed_env_vars = PHP_,LANG,LC_
--8--[ apache vhost config ]--8--
php_value include_path .:/usr/share/php:/usr/lib/php
--8--[ sample php script ]--8--
require_once('/usr/lib/php/Smarty/Smarty.class.php');
--8--
Expected result:
included file, no error message.
Actual result:
--
Warning: main() [function.main]: SAFE MODE Restriction in effect. The
script whose uid is 667 is not allowed to access
/usr/lib/php/Smarty/Smarty.class.php owned by uid 0 in
/home/wschlich/public_html/smartytest/smartytest.php on line 19
--
Edit this bug report at http://bugs.php.net/?id=34050edit=1
#34075 [Fbk-Opn]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: Hi Sniper, Sorry about that, here's the run on PHP 4.4 vs. PHP 4.3.8, the failure and output are the same, note this is a different host name, the one where I'm trying to build PHP 4.4. If you need any more info please let me know. This is from the PHP 4.4 sources pulled on 1 Aug 2005: # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/local/src/Tars/php-4.4.0 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.4.0 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] Previous Comments: [2005-08-11 23:06:51] [EMAIL PROTECTED] All your output here shows version 4.3.8. Please do the tests REALLY with PHP 4.4.0 or rather with the latest CVS snapshot of PHP 5.1 (http://snaps.php.net/php5-latest.tar.gz) [2005-08-11 20:43:33] RVaughn at pheedo dot com More info: === BUILD ENVIRONMENT === OS: Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT \ 2005 i686 Automake: automake (GNU automake) 1.6.3 Written by Tom Tromey [EMAIL PROTECTED]. Copyright 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Autoconf: autoconf (GNU Autoconf) 2.57 Written by David J. MacKenzie and Akim Demaille. [2005-08-11 19:06:18] RVaughn at pheedo dot com Shell is RHEL 3.0 /bin/bash. # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php # ls -al `echo $TEST_PHP_EXECUTABLE` -rwxr-xr-x1 root root 6254005 Aug 10 21:50 /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php From the Makefile: TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) top_builddir = /usr/src/redhat/SOURCES/php-4.3.8 SAPI_CLI_PATH = sapi/cli/php The Makefile matches this, which is where the unstriped executable is: # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php As per Tony's suggestion (thanks, but doesn't work, sorry I forgot that I also tried 'run-tests.php'): # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/src/redhat/SOURCES/php-4.3.8 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.8 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/imap.ini,/etc/php.d/ldap.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] Output from this run is the same: # more ext/standard/tests/file/bug22414.out HELLO Does not work I haven't tried the CVS snapshot because we've given up on getting PHP 4.4 to build and work on RHEL 3.0 for now. The fact that this test fails on three different RHEL 3.0 servers w/three different PHP versions (4.3.8, 4.3.11, 4.4) is what makes me think there's a problem with this script on RHEL 3.0. The test script is the same in all three distributions, and it fails in the same way on all three, and I've written some simple passthru() tests myself and the function seems to work just fine, it's the test script. Could be that passthru() is failing on RHEL 3.0 for all these versions as my own tests are pretty simple. Thanks! [2005-08-11 11:24:51] [EMAIL PROTECTED] ./sapi/cli/php ext/standard/tests/file/bug22414.phpt Ugh..Don't do it, please. These tests should not be run directly. You must use run-tests.php for running them. Please try to this: TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt
#34075 [Opn]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com Status: Open Bug Type: *General Issues Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: Can't run these tests against PHP 5.1 - we are running PHP 4.3.2 on our servers and want to upgrade to PHP 4.4 if possible but do not want to move to PHP 5.1 yet, our application will require a lot of testing with PHP 5 before we make that migration. Our goal right now is simply to get to PHP 4.4 for the bug and security fixes and to test our application against it as well as upgrade MySQL from 3.x to 4.1-1, and then migrate to PHP 5.x at some later date. Thanks, Rob Previous Comments: [2005-08-12 02:08:36] RVaughn at pheedo dot com Hi Sniper, Sorry about that, here's the run on PHP 4.4 vs. PHP 4.3.8, the failure and output are the same, note this is a different host name, the one where I'm trying to build PHP 4.4. If you need any more info please let me know. This is from the PHP 4.4 sources pulled on 1 Aug 2005: # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/local/src/Tars/php-4.4.0 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.4.0 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] [2005-08-11 23:06:51] [EMAIL PROTECTED] All your output here shows version 4.3.8. Please do the tests REALLY with PHP 4.4.0 or rather with the latest CVS snapshot of PHP 5.1 (http://snaps.php.net/php5-latest.tar.gz) [2005-08-11 20:43:33] RVaughn at pheedo dot com More info: === BUILD ENVIRONMENT === OS: Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT \ 2005 i686 Automake: automake (GNU automake) 1.6.3 Written by Tom Tromey [EMAIL PROTECTED]. Copyright 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Autoconf: autoconf (GNU Autoconf) 2.57 Written by David J. MacKenzie and Akim Demaille. [2005-08-11 19:06:18] RVaughn at pheedo dot com Shell is RHEL 3.0 /bin/bash. # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php # ls -al `echo $TEST_PHP_EXECUTABLE` -rwxr-xr-x1 root root 6254005 Aug 10 21:50 /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php From the Makefile: TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) top_builddir = /usr/src/redhat/SOURCES/php-4.3.8 SAPI_CLI_PATH = sapi/cli/php The Makefile matches this, which is where the unstriped executable is: # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php As per Tony's suggestion (thanks, but doesn't work, sorry I forgot that I also tried 'run-tests.php'): # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/src/redhat/SOURCES/php-4.3.8 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.8 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/imap.ini,/etc/php.d/ldap.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] Output from this run is the same: # more ext/standard/tests/file/bug22414.out HELLO Does not work I haven't tried the CVS snapshot because we've given up on getting PHP 4.4 to build and work on RHEL 3.0 for now. The fact that this test fails on three different RHEL 3.0 servers w/three different PHP versions (4.3.8, 4.3.11, 4.4) is what makes me think there's a problem with this script on RHEL 3.0. The test script is the same in all three distributions, and it fails in the same way on all three, and I've written some simple passthru() tests myself and the function seems to work just
#34075 [Opn-Bgs]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 Updated by: [EMAIL PROTECTED] Reported By: RVaughn at pheedo dot com -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: You're running the test wrong. Use 'make test' or 'make test TESTS=pathtotestsyouwanttorun'. Secondly: I wasn't saying you need to move to PHP 5.1, I simply asked you to TEST if this happens with it.. Previous Comments: [2005-08-12 02:11:01] RVaughn at pheedo dot com Can't run these tests against PHP 5.1 - we are running PHP 4.3.2 on our servers and want to upgrade to PHP 4.4 if possible but do not want to move to PHP 5.1 yet, our application will require a lot of testing with PHP 5 before we make that migration. Our goal right now is simply to get to PHP 4.4 for the bug and security fixes and to test our application against it as well as upgrade MySQL from 3.x to 4.1-1, and then migrate to PHP 5.x at some later date. Thanks, Rob [2005-08-12 02:08:36] RVaughn at pheedo dot com Hi Sniper, Sorry about that, here's the run on PHP 4.4 vs. PHP 4.3.8, the failure and output are the same, note this is a different host name, the one where I'm trying to build PHP 4.4. If you need any more info please let me know. This is from the PHP 4.4 sources pulled on 1 Aug 2005: # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/local/src/Tars/php-4.4.0 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.4.0 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] [2005-08-11 23:06:51] [EMAIL PROTECTED] All your output here shows version 4.3.8. Please do the tests REALLY with PHP 4.4.0 or rather with the latest CVS snapshot of PHP 5.1 (http://snaps.php.net/php5-latest.tar.gz) [2005-08-11 20:43:33] RVaughn at pheedo dot com More info: === BUILD ENVIRONMENT === OS: Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT \ 2005 i686 Automake: automake (GNU automake) 1.6.3 Written by Tom Tromey [EMAIL PROTECTED]. Copyright 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Autoconf: autoconf (GNU Autoconf) 2.57 Written by David J. MacKenzie and Akim Demaille. [2005-08-11 19:06:18] RVaughn at pheedo dot com Shell is RHEL 3.0 /bin/bash. # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php # ls -al `echo $TEST_PHP_EXECUTABLE` -rwxr-xr-x1 root root 6254005 Aug 10 21:50 /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php From the Makefile: TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) top_builddir = /usr/src/redhat/SOURCES/php-4.3.8 SAPI_CLI_PATH = sapi/cli/php The Makefile matches this, which is where the unstriped executable is: # echo $TEST_PHP_EXECUTABLE /usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php As per Tony's suggestion (thanks, but doesn't work, sorry I forgot that I also tried 'run-tests.php'): # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/src/redhat/SOURCES/php-4.3.8 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.3.8 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/imap.ini,/etc/php.d/ldap.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] Output from this run is the same: # more ext/standard/tests/file/bug22414.out HELLO Does not work I haven't tried the CVS snapshot because we've given up on getting PHP 4.4 to build and work on RHEL 3.0 for now. The fact that this test fails on
#34075 [Bgs]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com Status: Bogus Bug Type: *General Issues Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: I ran the test exactly the way [EMAIL PROTECTED] said to in this bug report. If I run 'make test' the same thing happens. I'll run it yet again the Nth way you've asked. Here you go, fails exactly the same way: # make test TESTS=ext/standard/tests/file/bug22414.phpt = CWD : /usr/local/src/Tars/php-4.4.0 PHP : /usr/local/src/Tars/php-4.4.0/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.4.0 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] Previous Comments: [2005-08-12 02:22:01] [EMAIL PROTECTED] You're running the test wrong. Use 'make test' or 'make test TESTS=pathtotestsyouwanttorun'. Secondly: I wasn't saying you need to move to PHP 5.1, I simply asked you to TEST if this happens with it.. [2005-08-12 02:11:01] RVaughn at pheedo dot com Can't run these tests against PHP 5.1 - we are running PHP 4.3.2 on our servers and want to upgrade to PHP 4.4 if possible but do not want to move to PHP 5.1 yet, our application will require a lot of testing with PHP 5 before we make that migration. Our goal right now is simply to get to PHP 4.4 for the bug and security fixes and to test our application against it as well as upgrade MySQL from 3.x to 4.1-1, and then migrate to PHP 5.x at some later date. Thanks, Rob [2005-08-12 02:08:36] RVaughn at pheedo dot com Hi Sniper, Sorry about that, here's the run on PHP 4.4 vs. PHP 4.3.8, the failure and output are the same, note this is a different host name, the one where I'm trying to build PHP 4.4. If you need any more info please let me know. This is from the PHP 4.4 sources pulled on 1 Aug 2005: # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/local/src/Tars/php-4.4.0 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.4.0 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] [2005-08-11 23:06:51] [EMAIL PROTECTED] All your output here shows version 4.3.8. Please do the tests REALLY with PHP 4.4.0 or rather with the latest CVS snapshot of PHP 5.1 (http://snaps.php.net/php5-latest.tar.gz) [2005-08-11 20:43:33] RVaughn at pheedo dot com More info: === BUILD ENVIRONMENT === OS: Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT \ 2005 i686 Automake: automake (GNU automake) 1.6.3 Written by Tom Tromey [EMAIL PROTECTED]. Copyright 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Autoconf: autoconf (GNU Autoconf) 2.57 Written by David J. MacKenzie and Akim Demaille. 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/34075 -- Edit this bug report at http://bugs.php.net/?id=34075edit=1
#34087 [NEW]: strtotime() does not work with date format Y/m/d
From: osmium at 163 dot com Operating system: Windows Server 2003 PHP version: 5.1.0b3 PHP Bug Type: Date/time related Bug description: strtotime() does not work with date format Y/m/d Description: I got nothing on the first line but a number 1123804800 on the second line. Maybe format Y/m/d is not supported by strtotime(). However, I got two numbers in v5.0.3 Reproduce code: --- ?php echo Y/m/d: , strtotime(2005/8/12), br; echo Y-m-d: , strtotime(2005-8-12); ? Expected result: Y/m/d: 1123804800 Y-m-d: 1123804800 Actual result: -- Y/m/d: Y-m-d: 1123804800 -- Edit bug report at http://bugs.php.net/?id=34087edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34087r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34087r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34087r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34087r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34087r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34087r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34087r=needscript Try newer version: http://bugs.php.net/fix.php?id=34087r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34087r=support Expected behavior: http://bugs.php.net/fix.php?id=34087r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34087r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34087r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34087r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34087r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34087r=dst IIS Stability: http://bugs.php.net/fix.php?id=34087r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34087r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34087r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34087r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34087r=mysqlcfg
#34075 [Bgs-Opn]: The ext/standard/tests/file/bug22414.phpt script fails
ID: 34075 User updated by: RVaughn at pheedo dot com Reported By: RVaughn at pheedo dot com -Status: Bogus +Status: Open Bug Type: *General Issues Operating System: RHEL 3.0 PHP Version: 4.4.0 New Comment: Here's output from the straight-forward 'make test'. I don't know how many other bits of info I can send to convince someone that this test script doesn't work right? It fails the same no matter which way I run it, and on three different version of PHP 4.x all on RHEL 3.0 servers. Is there any way I can convince someone this script has a problem? = TIME END 2005-08-11 19:26:29 = TEST RESULT SUMMARY - Exts skipped: 55 Exts tested : 32 - Number of tests : 630 Tests skipped : 137 (21.7%) Tests warned:0 (0.0%) Tests failed:5 (0.8%) Tests passed: 488 (77.5%) - Time taken : 72 seconds = = FAILED TEST SUMMARY - mb_send_mail() test 5 (lang=Simplified Chinese) [ext/mbstring/tests/mb_send_mail05.phpt] mb_send_mail() test 6 (lang=Traditional Chinese) [ext/mbstring/tests/mb_send_mail06.phpt] mb_send_mail() test 7 (lang=Korean) [ext/mbstring/tests/mb_send_mail07.phpt] [EMAIL PROTECTED] #16242 [ext/mbstring/tests/php_gr_jp_16242.phpt] Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] = Previous Comments: [2005-08-12 02:56:31] RVaughn at pheedo dot com I ran the test exactly the way [EMAIL PROTECTED] said to in this bug report. If I run 'make test' the same thing happens. I'll run it yet again the Nth way you've asked. Here you go, fails exactly the same way: # make test TESTS=ext/standard/tests/file/bug22414.phpt = CWD : /usr/local/src/Tars/php-4.4.0 PHP : /usr/local/src/Tars/php-4.4.0/sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.4.0 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly [ext/standard/tests/file/bug22414.phpt] [2005-08-12 02:22:01] [EMAIL PROTECTED] You're running the test wrong. Use 'make test' or 'make test TESTS=pathtotestsyouwanttorun'. Secondly: I wasn't saying you need to move to PHP 5.1, I simply asked you to TEST if this happens with it.. [2005-08-12 02:11:01] RVaughn at pheedo dot com Can't run these tests against PHP 5.1 - we are running PHP 4.3.2 on our servers and want to upgrade to PHP 4.4 if possible but do not want to move to PHP 5.1 yet, our application will require a lot of testing with PHP 5 before we make that migration. Our goal right now is simply to get to PHP 4.4 for the bug and security fixes and to test our application against it as well as upgrade MySQL from 3.x to 4.1-1, and then migrate to PHP 5.x at some later date. Thanks, Rob [2005-08-12 02:08:36] RVaughn at pheedo dot com Hi Sniper, Sorry about that, here's the run on PHP 4.4 vs. PHP 4.3.8, the failure and output are the same, note this is a different host name, the one where I'm trying to build PHP 4.4. If you need any more info please let me know. This is from the PHP 4.4 sources pulled on 1 Aug 2005: # TEST_PHP_EXECUTABLE=./sapi/cli/php ./sapi/cli/php run-tests.php ext/standard/tests/file/bug22414.phpt = CWD : /usr/local/src/Tars/php-4.4.0 PHP : ./sapi/cli/php PHP_SAPI: cli PHP_VERSION : 4.4.0 ZEND_VERSION: 1.3.0 PHP_OS : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17 17:52:23 EDT 2005 i686 INI actual : /etc/php.ini More .INIs : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini Extra dirs : = Running selected tests. FAIL Bug #22414: passthru() does not read data correctly
#34089 [NEW]: Configure fails build test for libxml2
From: [EMAIL PROTECTED] Operating system: Mac OS X 10.4.2 PHP version: 5CVS-2005-08-12 (dev) PHP Bug Type: *Configuration Issues Bug description: Configure fails build test for libxml2 Description: Configure fails on the build test for libxml2 in HEAD, but the same configure line works fine when building PHP 5.1 on the same system. (I am trying to build according to Andrei's notes on building in the Unicode support: http://news.php.net/php.internals/17848 ) Had to include the options --disable-libxml, --disable-dom, and --disable-simplexml to get past the error. However, now I receive another error: checking for char *... yes checking size of char *... configure: error: cannot compute sizeof (char *), 77 But I should probably leave this error for another bug report once this one has been resolved (if it still exists once this is resolved). Please see the output of config.log at http://benramsey.com/files/php/config.log Reproduce code: --- cvs -d :pserver:[EMAIL PROTECTED]:/repository co -d php-HEAD php-src cd php-HEAD ./buildconf ./configure --with-layout=PHP --prefix=/usr/local/php/6.0.0 --with-apxs=/usr/local/apache/83/bin/apxs --without-pear --with-sqlite --with-pdo-mysql=/usr/local/mysql --with-pdo-pgsql=/usr/local/pgsql --with-iconv=/sw --with-icu-dir=/usr/local/icu Expected result: I expect configure to run fine and generate the make files. Actual result: -- configure:29153: checking whether to enable LIBXML support configure:29191: result: yes configure:29200: checking libxml2 install dir configure:29218: result: no configure:29230: checking for xml2-config path configure:29244: result: /usr/bin/xml2-config configure:29387: checking whether libxml build works configure:29419: gcc -o conftest -g -O2 -no-cpp-precomp -L/usr/local/icu/lib -L/usr/local/icu/lib conftest.c -lm -lm -licui18n -licuuc -licudata -lm -licuio -lxml2 -lz -liconv -lm 5 configure:29422: $? = 0 configure:29424: ./conftest dyld: Library not loaded: libicui18n.dylib.34 Referenced from: /Users/ramsey/src/php/php-HEAD/./conftest Reason: image not found ./configure: line 1: 16108 Trace/BPT trap ./conftest$ac_exeext configure:29427: $? = 133 configure: program exited with status 133 configure:29444: result: no configure:29446: error: build test failed. Please check the config.log for details. -- Edit bug report at http://bugs.php.net/?id=34089edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34089r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34089r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34089r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34089r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34089r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34089r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34089r=needscript Try newer version: http://bugs.php.net/fix.php?id=34089r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34089r=support Expected behavior: http://bugs.php.net/fix.php?id=34089r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34089r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34089r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34089r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34089r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34089r=dst IIS Stability: http://bugs.php.net/fix.php?id=34089r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34089r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34089r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34089r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34089r=mysqlcfg
#34087 [Opn-Bgs]: strtotime() does not work with date format Y/m/d
ID: 34087 Updated by: [EMAIL PROTECTED] Reported By: osmium at 163 dot com -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Windows Server 2003 PHP Version: 5.1.0b3 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The manual states that strtotime() parses a date/time string according to the GNU Date Input Formats syntax. The format Y/m/d is not a supported GNU date input format (see the link below). http://www.php.net/strtotime http://www.gnu.org/software/tar/manual/html_chapter/tar_7.html Previous Comments: [2005-08-12 03:08:37] osmium at 163 dot com Description: I got nothing on the first line but a number 1123804800 on the second line. Maybe format Y/m/d is not supported by strtotime(). However, I got two numbers in v5.0.3 Reproduce code: --- ?php echo Y/m/d: , strtotime(2005/8/12), br; echo Y-m-d: , strtotime(2005-8-12); ? Expected result: Y/m/d: 1123804800 Y-m-d: 1123804800 Actual result: -- Y/m/d: Y-m-d: 1123804800 -- Edit this bug report at http://bugs.php.net/?id=34087edit=1
#34090 [NEW]: CVS HEAD build failes
From: [EMAIL PROTECTED] Operating system: FreeBSD 5.3-RELEASE PHP version: 5CVS-2005-08-12 (dev) PHP Bug Type: Compile Failure Bug description: CVS HEAD build failes Description: $ cvs -d :pserver:[EMAIL PROTECTED]:/repository checkout php-src $ cd php-src/ $ ./buildconf --force $ ./configure --with-zend-vm=GOTO --enable-debug --with-apxs2=/usr/local/sbin/apxs --prefix=/usr/home/dev $ make Actual result: -- -b /usr/home/dev/php-src/ext/standard/var_unserializer.re /usr/home/dev/php-src/ext/standard/var_unserializer.c -b: not found *** Error code 127 -- Edit bug report at http://bugs.php.net/?id=34090edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34090r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34090r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34090r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34090r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34090r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34090r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34090r=needscript Try newer version: http://bugs.php.net/fix.php?id=34090r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34090r=support Expected behavior: http://bugs.php.net/fix.php?id=34090r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34090r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34090r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34090r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34090r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34090r=dst IIS Stability: http://bugs.php.net/fix.php?id=34090r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34090r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34090r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34090r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34090r=mysqlcfg
#34091 [NEW]: fsockopen data connection failed?
From: gordon at perridot dot com Operating system: Linux 7.3 PHP version: 4CVS-2005-08-12 (stable) PHP Bug Type: Sockets related Bug description: fsockopen data connection failed? Description: Hi, I am using php4.1, when i try connect to the FTP server via fsockopen, after login succeesfully, i can't list or get files from the server, the system prompt me 425 Can't open data connection. How to solve this problem? Thank you... Reproduce code: --- $fp = fsockopen(ftpip,21); fputs($fp,USER myname\r\n); echo fgets($fp,4096); fputs($fp,PASS mypassword\r\n); echo fgets($fp,4096); fputs($fp,TYPE A\r\n); echo fgets($fp,4096); fputs($fp,PASV\r\n); echo fgets($fp,4096); fputs($fp,RETR test.txt\r\n); echo fgets($fp,4096); fputs($fp,quit\r\n); Expected result: 425 Can't open data connection. -- Edit bug report at http://bugs.php.net/?id=34091edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34091r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34091r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34091r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34091r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34091r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34091r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34091r=needscript Try newer version: http://bugs.php.net/fix.php?id=34091r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34091r=support Expected behavior: http://bugs.php.net/fix.php?id=34091r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34091r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34091r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34091r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34091r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34091r=dst IIS Stability: http://bugs.php.net/fix.php?id=34091r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34091r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34091r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34091r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34091r=mysqlcfg
#34092 [NEW]: Compile error: tsrm_ls undeclared in php_expand_u_trim_range
From: david dot tulloh at anu dot edu dot au Operating system: Debian Linux PHP version: 5CVS-2005-08-12 (dev) PHP Bug Type: Strings related Bug description: Compile error: tsrm_ls undeclared in php_expand_u_trim_range Description: I was trying to give the new unicode stuff a spin but it wouldn't compile. Reproduce code: --- ./cvsclean cvs update ./buildconf http://localhost:100/configure_line make Actual result: -- /bin/sh /home/lod/Downloads/php-cvs/libtool --silent --preserve-dup-deps --mode=compile /home/lod/Downloads/php-cvs/meta_ccld -Iext/standard/ -I/home/lod/Downloads/php-cvs/ext/standard/ -DPHP_ATOM_INC -I/home/lod/Downloads/php-cvs/include -I/home/lod/Downloads/php-cvs/main -I/home/lod/Downloads/php-cvs -I/usr/include/libxml2 -I/usr/include/postgresql/8.0 -I/usr/include/tidy -I/home/lod/Downloads/php-cvs/TSRM -I/home/lod/Downloads/php-cvs/Zend -D_REENTRANT -g -O2 -pthread -DZTS -prefer-non-pic -c /home/lod/Downloads/php-cvs/ext/standard/string.c -o ext/standard/string.lo /home/lod/Downloads/php-cvs/ext/standard/string.c: In function `php_expand_u_trim_range': /home/lod/Downloads/php-cvs/ext/standard/string.c:619: error: `tsrm_ls' undeclared (first use in this function) /home/lod/Downloads/php-cvs/ext/standard/string.c:619: error: (Each undeclared identifier is reported only once /home/lod/Downloads/php-cvs/ext/standard/string.c:619: error: for each function it appears in.) /home/lod/Downloads/php-cvs/ext/standard/string.c: In function `zif_strstr': /home/lod/Downloads/php-cvs/ext/standard/string.c:1915: warning: assignment from incompatible pointer type /home/lod/Downloads/php-cvs/ext/standard/string.c:1916: warning: passing arg 1 of `u_strncpy_3_4' from incompatible pointer type /home/lod/Downloads/php-cvs/ext/standard/string.c:1918: warning: initialization from incompatible pointer type make: *** [ext/standard/string.lo] Error 1 -- Edit bug report at http://bugs.php.net/?id=34092edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34092r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34092r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34092r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34092r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34092r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34092r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34092r=needscript Try newer version: http://bugs.php.net/fix.php?id=34092r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34092r=support Expected behavior: http://bugs.php.net/fix.php?id=34092r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34092r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34092r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34092r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34092r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34092r=dst IIS Stability: http://bugs.php.net/fix.php?id=34092r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34092r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34092r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34092r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34092r=mysqlcfg
#34091 [Opn-Fbk]: fsockopen data connection failed?
ID: 34091 Updated by: [EMAIL PROTECTED] Reported By: gordon at perridot dot com -Status: Open +Status: Feedback Bug Type: Sockets related Operating System: Linux 7.3 PHP Version: 4CVS-2005-08-12 (stable) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2005-08-12 06:16:46] gordon at perridot dot com Description: Hi, I am using php4.1, when i try connect to the FTP server via fsockopen, after login succeesfully, i can't list or get files from the server, the system prompt me 425 Can't open data connection. How to solve this problem? Thank you... Reproduce code: --- $fp = fsockopen(ftpip,21); fputs($fp,USER myname\r\n); echo fgets($fp,4096); fputs($fp,PASS mypassword\r\n); echo fgets($fp,4096); fputs($fp,TYPE A\r\n); echo fgets($fp,4096); fputs($fp,PASV\r\n); echo fgets($fp,4096); fputs($fp,RETR test.txt\r\n); echo fgets($fp,4096); fputs($fp,quit\r\n); Expected result: 425 Can't open data connection. -- Edit this bug report at http://bugs.php.net/?id=34091edit=1
#34093 [NEW]: Apache child segfaults(11) in strlen
From: alexiadeath at hotmail dot com Operating system: Slackware Linux 10.1 PHP version: 5.0.4 PHP Bug Type: Reproducible crash Bug description: Apache child segfaults(11) in strlen Description: in php 5.0.4 with either apache 2 or apache 1.3 (there is no difference) click on phpMyadmin Browse tab generates a partial page with segfault(11) in apache log. Failed to find the exact cause because the moment of segfaulting DEPENDS on minor changes in the code for example an added echo. With php 4.4 nothing like this happens and page loads properly. on windows with apache2 and php 5.0.5dev the problem simply does not exist. Cant try the latest dev because of the disc space limitations of my box. no room for compile tools. all items involeved are a maching set of precompiled packages from linuxpackages site. Reproduce code: --- In phpMyadmin every time on clicking browse. go try. Expected result: phpMyadmin page with database results. Actual result: -- page with just tab headers. GDB backtrace follows: (gdb) bt #0 0x403c623b in strlen () from /lib/libc.so.6 #1 0x407c2128 in add_property_string_ex () from /usr/lib/apache2/libphp5.so #2 0x406803fb in zif_mysql_fetch_field () from /usr/lib/apache2/libphp5.so #3 0x407e40b8 in zend_do_fcall_common_helper () from /usr/lib/apache2/libphp5.so #4 0x407e422a in zend_do_fcall_handler () from /usr/lib/apache2/libphp5.so #5 0x407e09a5 in execute () from /usr/lib/apache2/libphp5.so #6 0x407e3e7f in zend_do_fcall_common_helper () from /usr/lib/apache2/libphp5.so #7 0x407e416a in zend_do_fcall_by_name_handler () from /usr/lib/apache2/libphp5.so #8 0x407e09a5 in execute () from /usr/lib/apache2/libphp5.so #9 0x407bfc6d in zend_execute_scripts () from /usr/lib/apache2/libphp5.so #10 0x40786d6f in php_execute_script () from /usr/lib/apache2/libphp5.so #11 0x407ebb9c in php_handler () from /usr/lib/apache2/libphp5.so #12 0x08067fa6 in ap_run_handler () #13 0x08068578 in ap_invoke_handler () #14 0x080654af in ap_process_request () #15 0x08060d49 in ap_process_http_connection () #16 0x08071046 in ap_run_process_connection () #17 0x08066958 in child_main () #18 0x08066b0e in make_child () #19 0x08066b7f in startup_children () #20 0x080672f9 in ap_mpm_run () #21 0x0806ca88 in main () -- Edit bug report at http://bugs.php.net/?id=34093edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34093r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34093r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34093r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34093r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34093r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34093r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34093r=needscript Try newer version: http://bugs.php.net/fix.php?id=34093r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34093r=support Expected behavior: http://bugs.php.net/fix.php?id=34093r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34093r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34093r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34093r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34093r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34093r=dst IIS Stability: http://bugs.php.net/fix.php?id=34093r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34093r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34093r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34093r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34093r=mysqlcfg
