#24608 [Com]: __set not triggered when overloading with array
ID: 24608
Comment by: itotakas at msu dot edu
Reported By: jaanus at heeringson dot com
Status: Open
Bug Type: Class/Object related
Operating System: Linux 2.4 jkernel source distro
PHP Version: 5.0.0b1 (beta1)
New Comment:
I got same result by running your code.
my platform is
OS : Win 2000 Pro SP4
PHP : 5.0.0b2-dev
using Apache 1.3.24 and SAPI modules
If you really want to do,
$test-style[temp] = content;
you can do this instead.
$test-style = array(temp = content);
In this case, __set function will work.
Previous Comments:
[2003-07-11 12:48:38] jaanus at heeringson dot com
Description:
When overloading a class with a property containing an array by
assigning an element to to the new array the __set handle does not
fire, but the element gets created.
Reproduce code:
---
?php
class myclass {
public function __set($name,$data) {
echo(Name: {$name}br/\nData: {$data}br/\n); //prints out input
when fired
}
}
$test=new myclass();
$test-style['temp']='content'; //creates a new property
print_r($test-style); //check if property is created
?
Expected result:
Results from the echo in __set
Actual result:
--
The result of the print_r shows that the property is created, but id
did not pass the __set
--
Edit this bug report at http://bugs.php.net/?id=24608edit=1
#24912 [Bgs-Opn]: Date function returns incorrect time zone
ID: 24912
User updated by: mark at katmoda dot com
Reported By: mark at katmoda dot com
-Status: Bogus
+Status: Open
-Bug Type: Date/time related
+Bug Type: Mail related
Operating System: windows xp/ win2k
PHP Version: 5.0.0b1 (beta1)
New Comment:
What you state means that there is a bug in de mail() function. Because
that function sends a +0100 value with the date header. Isn't this
true?
Previous Comments:
[2003-08-01 19:26:53] [EMAIL PROTECTED]
You are in GMT+0100 in winter and GMT+0200 in summer, see e.g.
http://greenwichmeantime.com/local/europe/nl.htm. GMT doesn't have
daylight savings, it's fixed.
[2003-08-01 18:30:59] mark at katmoda dot com
Description:
I just found out this on my windows XP machine:
background info:
- I live in the Netherlands (timezone= GMT+1)
When you enable the option to automaticaly adjust your system clock for
daylight savings (on windows' control panel), php's date() function and
the Date header in the mail function will return different time zones.
an example:
?php
$test= date('O');
?
now $test is: +0200
But if I send a mail with php using the mail() function the Date header
is telling me +0100 (which seems to me is right because I live in the
Netherlands where timezone=GMT+1)
This bug can be caused by windows (returning the wrong timezone to
php's date() function). Or php's date() function is doing something
wrong itself.
I found this trying to figure out why my emails appeared to be sent one
hour later than they really were sent. (I use Mozilla mail and
appearantly it suffers from the same bug as php's date() function ).
Reproduce code:
---
?php
print(date('D, d M y H:i:s O'));
# This only goes wrong when you have automaticaly adjust
# clock for daylight saving changes on:
# control panel Date and Time Time zone
# set to enabled
?
Expected result:
Sat, 02 Aug 03 01:17:02 +0100
Actual result:
--
Sat, 02 Aug 03 01:17:02 +0200
--
Edit this bug report at http://bugs.php.net/?id=24912edit=1
#24913 [Opn-Bgs]: configure doesn't detect C++ compiler properly
ID: 24913 Updated by: [EMAIL PROTECTED] Reported By: djain at gmx dot net -Status: Open +Status: Bogus -Bug Type: *Compile Issues +Bug Type: Compile Failure Operating System: CygWin NT5 PHP Version: 4CVS-2003-08-01 (stable) New Comment: cygwin tests are from libtool/autoconf, those we can't remove. We do NOT support Cygwin, period. (and it's likely that your config.m4 is borked, and that is definately NOT our problem. Previous Comments: [2003-08-01 21:40:50] djain at gmx dot net And why do you assume I am having trouble developing extensions? As I said, it worked fine after modifying configure. [2003-08-01 21:28:42] djain at gmx dot net If CygWin is not a supported build environment, how come the configure script explicitly checks for it: checking for CygWin environment. And PHP can be compiled on CygWin with no problems as long as you don't use C++. And even if you use C++, there are no problems except that configure thinks the C++ compiler is incapable of producing executables. So I had to modify configure not to exit after detecting that the compiler is supposedly incapable of producing executables. It really has nothing to do with my extension at all. You can use any (C++) extension that has PHP_REQUIRE_CXX() in the config.m4 file. [2003-08-01 19:44:08] [EMAIL PROTECTED] cygwin is not a supported build environment for PHP. We didn't write your extension. You didn't give enough info for us to know what is going wrong. This is not a bug in php, so marking as bogus. If you have problems developing extensions, ask on the internals mailing list. [2003-08-01 19:11:24] djain at gmx dot net Description: Under CygWin, when compiling with an extension that uses C++, configure reports C++ compiler cannot create executables and exits (./configure --with-myextension). I'm using the latest version of CygWin with gcc 3.2 20020927. After uncommenting the corresponding line in the configure script, I was able to successfully build PHP with my C++ extension. I originally used php 4.3.2, the latest CVS version didn't work either. -- Edit this bug report at http://bugs.php.net/?id=24913edit=1
#24608 [Opn-Ver]: __set not triggered when overloading with array
ID: 24608
Updated by: [EMAIL PROTECTED]
Reported By: jaanus at heeringson dot com
-Status: Open
+Status: Verified
-Bug Type: Class/Object related
+Bug Type: Zend Engine 2 problem
Operating System: Linux 2.4 jkernel source distro
-PHP Version: 5.0.0b1 (beta1)
+PHP Version: 5.0.0b2-dev
Previous Comments:
[2003-07-11 12:48:38] jaanus at heeringson dot com
Description:
When overloading a class with a property containing an array by
assigning an element to to the new array the __set handle does not
fire, but the element gets created.
Reproduce code:
---
?php
class myclass {
public function __set($name,$data) {
echo(Name: {$name}br/\nData: {$data}br/\n); //prints out input
when fired
}
}
$test=new myclass();
$test-style['temp']='content'; //creates a new property
print_r($test-style); //check if property is created
?
Expected result:
Results from the echo in __set
Actual result:
--
The result of the print_r shows that the property is created, but id
did not pass the __set
--
Edit this bug report at http://bugs.php.net/?id=24608edit=1
#24912 [Opn-Bgs]: Date function returns incorrect time zone
ID: 24912
Updated by: [EMAIL PROTECTED]
Reported By: mark at katmoda dot com
-Status: Open
+Status: Bogus
Bug Type: Mail related
Operating System: windows xp/ win2k
PHP Version: 5.0.0b1 (beta1)
New Comment:
That depends on your system settings / SMTP server's settings. As you
failed to give an example script - bogus.
Previous Comments:
[2003-08-02 03:43:20] mark at katmoda dot com
What you state means that there is a bug in de mail() function. Because
that function sends a +0100 value with the date header. Isn't this
true?
[2003-08-01 19:26:53] [EMAIL PROTECTED]
You are in GMT+0100 in winter and GMT+0200 in summer, see e.g.
http://greenwichmeantime.com/local/europe/nl.htm. GMT doesn't have
daylight savings, it's fixed.
[2003-08-01 18:30:59] mark at katmoda dot com
Description:
I just found out this on my windows XP machine:
background info:
- I live in the Netherlands (timezone= GMT+1)
When you enable the option to automaticaly adjust your system clock for
daylight savings (on windows' control panel), php's date() function and
the Date header in the mail function will return different time zones.
an example:
?php
$test= date('O');
?
now $test is: +0200
But if I send a mail with php using the mail() function the Date header
is telling me +0100 (which seems to me is right because I live in the
Netherlands where timezone=GMT+1)
This bug can be caused by windows (returning the wrong timezone to
php's date() function). Or php's date() function is doing something
wrong itself.
I found this trying to figure out why my emails appeared to be sent one
hour later than they really were sent. (I use Mozilla mail and
appearantly it suffers from the same bug as php's date() function ).
Reproduce code:
---
?php
print(date('D, d M y H:i:s O'));
# This only goes wrong when you have automaticaly adjust
# clock for daylight saving changes on:
# control panel Date and Time Time zone
# set to enabled
?
Expected result:
Sat, 02 Aug 03 01:17:02 +0100
Actual result:
--
Sat, 02 Aug 03 01:17:02 +0200
--
Edit this bug report at http://bugs.php.net/?id=24912edit=1
#22546 [Com]: fread (maybe in connection with fseek) do not read length bytes
ID: 22546
Comment by: diz at ysagoon dot com
Reported By: 4u at direct-netware dot de
Status: Bogus
Bug Type: Filesystem function related
Operating System: WinNT
PHP Version: 4.3.1
New Comment:
I don't know if this is related, but I think so. Please tell me if I
should better submit this as a new bug.
The fseek teleports my file pointer to some strange places. I'm using
Win2K (NT5 SP4) with administrative rights and I'm running EasyPhp
1.6.0.0 that contains PHP 4.2.0. But the same script works on Debian
GNU/Linux 2.2.20 with PHP 4.1.2!
Here's my example script (note that none of the two fseek methods
work):
function getChar($fp, $c)
{
$c=fgetc($fp);
if(feof($fp))
return false;
return true;
}
$fp=fopen('parseTest.txt','r');
while(true)
{
$c=fgetc($fp);
if(feof($fp))
break;
echo($c);
//fseek($fp, -1, SEEK_CUR);
fseek($fp, ftell($fp)-1);
$c=fgetc($fp);
if(feof($fp))
break;
echo($c);
}
fclose($fp);
echo('EOF');
The file that I read contains just this:
Hello World!
The correct output on Debian GNU/Linux 2.2.20 with PHP 4.1.2:
hheeoo wwoorrlldd!!
EOF
The problematic output on Win2k with PHP 4.2.0:
hEOF
Ok that's it. Thank you for your support! :)
Gabriel
Previous Comments:
[2003-03-05 08:17:52] 4u at direct-netware dot de
Strange things happening here - I will check it before getting on your
nerves again ;)
[2003-03-05 07:54:57] 4u at direct-netware dot de
I know how to install PHP using a ZIP-file...
1,22 MB (1.286.144 Bytes) - Is this the right dll? (At least this is
the dll in the snapshot I downloaded - Last edited today)
The error still exists with the dll, mentioned above!
[2003-03-05 06:48:56] [EMAIL PROTECTED]
Just replace every existing php4ts.dll with the new one from the
snapshot package..and make sure nothing is running when you do this.
[2003-03-05 06:25:52] 4u at direct-netware dot de
I'm sorry, but then the bug isn't (completly?) removed - used snapshot
resulting fread-error: php4-win32-STABLE-200303050930
[2003-03-05 06:20:38] [EMAIL PROTECTED]
This was fixed last week; any current snapshot should contain the fix.
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/22546
--
Edit this bug report at http://bugs.php.net/?id=22546edit=1
#24915 [NEW]: empty()/isset() misleading with __get/__set
From: tater at potatoe dot com
Operating system: OS X 10.2
PHP version: 5CVS-2003-08-02 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: empty()/isset() misleading with __get/__set
Description:
Given a property that is really being handled by __get() and __set()
functions, you are allowed to use it with empty() and isset() without
errors or warnings, but they always report that the property is
empty/not-set.
I understand that this may not be a bug, but a feature
of PHP 5 - i.e., just the way it works - but if that is true,
please be kind enough to say so explicitly. It is not helpful
to mark bugs as Bogus with comments like I suggest you read ZEND_CHANGES
:)
If it is to be expected, it might be good to throw the
same kind of error that one would see if trying to use
empty() on a function call, if that's possible.
This is possibly related to bug #24436.
Reproduce code:
---
class foo
{
private $_x;
private function __get($p) { return $this-_x; }
private function __set($p,$v) { $this-_x = $v; }
}
$y = new foo;
$y-x = 12;
if (empty($y-x))
print y-x is empty: {$y-x} \n;
else
print y-x is not empty: {$y-x} \n;
if (isset($y-x))
print y-x is set: {$y-x} \n;
else
print y-x is not set: {$y-x} \n;
Expected result:
y-x is not empty: 12
y-x is set: 12
Actual result:
--
y-x is empty: 12
y-x is not set: 12
--
Edit bug report at http://bugs.php.net/?id=24915edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24915r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24915r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24915r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24915r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24915r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24915r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24915r=support
Expected behavior: http://bugs.php.net/fix.php?id=24915r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24915r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24915r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24915r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24915r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24915r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24915r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24915r=gnused
#24916 [NEW]: IIS6.0 CGI PHP header()
From: sadun at isikun dot org Operating system: Windows Server 2003 PHP version: 4.3.2 PHP Bug Type: IIS related Bug description: IIS6.0 CGI PHP header() Description: ;changes in php.ini error_reporting = E_ALL ~E_NOTICE register_globals = On include_path = .;W:\wwwroot\includes extension_dir = W:\php\extensions cgi.force_redirect = 0 cgi.redirect_status_env = ENV_VAR_NAME fastcgi.impersonate = 1 cgi.rfc2616_headers = 1 upload_tmp_dir = W:\php\phpupload extension=php_mbstring.dll extension=php_imap.dll extension=php_gd2.dll session.save_path = W:\php\phpsession session.auto_start = 1 Reproduce code: --- Header(Location: Http://.$GLOBALS[HTTP_HOST]./main.php?;); // i checked URL is correct Expected result: redirect to url Actual result: -- CGI Error The specified CGI application misbehaved by not returning a complete set of, HTTP headers. -- Edit bug report at http://bugs.php.net/?id=24916edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24916r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24916r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24916r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24916r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24916r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24916r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24916r=support Expected behavior: http://bugs.php.net/fix.php?id=24916r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24916r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24916r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24916r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24916r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24916r=dst IIS Stability: http://bugs.php.net/fix.php?id=24916r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24916r=gnused
#24916 [Opn]: IIS6.0 CGI PHP header()
ID: 24916 User updated by: sadun at isikun dot org Reported By: sadun at isikun dot org Status: Open Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 4.3.2 New Comment: it was working fine with ISAPI on IIS 6.0 but i need to use like CGI and i faced with CGI Error. i have searched the net but i can't find anything about it. Previous Comments: [2003-08-02 08:06:02] sadun at isikun dot org Description: ;changes in php.ini error_reporting = E_ALL ~E_NOTICE register_globals = On include_path = .;W:\wwwroot\includes extension_dir = W:\php\extensions cgi.force_redirect = 0 cgi.redirect_status_env = ENV_VAR_NAME fastcgi.impersonate = 1 cgi.rfc2616_headers = 1 upload_tmp_dir = W:\php\phpupload extension=php_mbstring.dll extension=php_imap.dll extension=php_gd2.dll session.save_path = W:\php\phpsession session.auto_start = 1 Reproduce code: --- Header(Location: Http://.$GLOBALS[HTTP_HOST]./main.php?;); // i checked URL is correct Expected result: redirect to url Actual result: -- CGI Error The specified CGI application misbehaved by not returning a complete set of, HTTP headers. -- Edit this bug report at http://bugs.php.net/?id=24916edit=1
#24913 [Bgs]: configure doesn't detect C++ compiler properly
ID: 24913 User updated by: djain at gmx dot net Reported By: djain at gmx dot net Status: Bogus Bug Type: Compile Failure Operating System: CygWin NT5 PHP Version: 4CVS-2003-08-01 (stable) New Comment: Thank you very much, that clarifies it. Previous Comments: [2003-08-02 05:04:18] [EMAIL PROTECTED] cygwin tests are from libtool/autoconf, those we can't remove. We do NOT support Cygwin, period. (and it's likely that your config.m4 is borked, and that is definately NOT our problem. [2003-08-01 21:40:50] djain at gmx dot net And why do you assume I am having trouble developing extensions? As I said, it worked fine after modifying configure. [2003-08-01 21:28:42] djain at gmx dot net If CygWin is not a supported build environment, how come the configure script explicitly checks for it: checking for CygWin environment. And PHP can be compiled on CygWin with no problems as long as you don't use C++. And even if you use C++, there are no problems except that configure thinks the C++ compiler is incapable of producing executables. So I had to modify configure not to exit after detecting that the compiler is supposedly incapable of producing executables. It really has nothing to do with my extension at all. You can use any (C++) extension that has PHP_REQUIRE_CXX() in the config.m4 file. [2003-08-01 19:44:08] [EMAIL PROTECTED] cygwin is not a supported build environment for PHP. We didn't write your extension. You didn't give enough info for us to know what is going wrong. This is not a bug in php, so marking as bogus. If you have problems developing extensions, ask on the internals mailing list. [2003-08-01 19:11:24] djain at gmx dot net Description: Under CygWin, when compiling with an extension that uses C++, configure reports C++ compiler cannot create executables and exits (./configure --with-myextension). I'm using the latest version of CygWin with gcc 3.2 20020927. After uncommenting the corresponding line in the configure script, I was able to successfully build PHP with my C++ extension. I originally used php 4.3.2, the latest CVS version didn't work either. -- Edit this bug report at http://bugs.php.net/?id=24913edit=1
#21611 [Opn]: Problem with version_compare() (Was: Problem with pear cli and release numbers)
ID: 21611
Updated by: [EMAIL PROTECTED]
-Summary: Problem with pear cli and release numbers
Reported By: jan at horde dot org
Status: Open
-Bug Type: PEAR related
+Bug Type: PHP options/info functions
Operating System: Any
PHP Version: 4CVS-2003-01-13 (stable)
Assigned To: gschlossnagle
New Comment:
reclassifying as PHP options/info functions
Previous Comments:
[2003-08-02 09:35:44] [EMAIL PROTECTED]
I'd go for B) and change it, since it's easy and the p suffix is quite
common... here's a patch that does it:
Index: versioning.c
===
RCS file: /repository/php-src/ext/standard/versioning.c,v
retrieving revision 1.15
diff -u -r1.15 versioning.c
--- versioning.c10 Jun 2003 20:03:39 - 1.15
+++ versioning.c2 Aug 2003 14:28:45 -
@@ -90,7 +90,7 @@
compare_special_version_forms(char *form1, char *form2)
{
int found1 = -1, found2 = -1;
- special_forms_t special_forms[9] = {
+ special_forms_t special_forms[10] = {
{dev, 0},
{alpha, 1},
{a, 1},
@@ -99,6 +99,7 @@
{RC, 3},
{#, 4},
{pl, 5},
+ {p, 5},
{NULL, 0},
};
special_forms_t *pp;
[2003-08-01 05:40:08] [EMAIL PROTECTED]
version_compare does handle suffixes. (see example below) However, p1
is not a valid suffix for this function. So, solutions would be imo:
A) use the pl suffix and document this
B) make version_compare handle pl and p equally
Example script:
?php
$version[] = 4.0.1pl2;
$version[] = 4.0.1pl1;
$version[] = 4.0.1b;
$version[] = 4.0.1a;
$version[] = 4.0.1p1;
$version[] = 4.0.1;
printf(%10s | %10s | %10s\n, Version 1, Version 2, New Vers.);
print str_repeat('-',36).\n;
for ($i = 0, $s = count($version); $i $s; $i++ ) {
for ($j = $i; $j $s; $j++) {
printf(%10s | %10s | ,$version[$i],$version[$j]);
$c = version_compare($version[$i], $version[$j]);
switch ($c) {
case -1:
$r = $version[$j];
break;
case 0:
$r = 'equal';
break;
case 1:
$r = $version[$i];
}
printf(%10s\n, $r);
}
}
?
Result:
Version 1 | Version 2 | New Vers.
4.0.1pl2 | 4.0.1pl2 | equal
4.0.1pl2 | 4.0.1pl1 | 4.0.1pl2
4.0.1pl2 | 4.0.1b | 4.0.1pl2
4.0.1pl2 | 4.0.1a | 4.0.1pl2
4.0.1pl2 |4.0.1p1 | 4.0.1pl2
4.0.1pl2 | 4.0.1 | 4.0.1pl2
4.0.1pl1 | 4.0.1pl1 | equal
4.0.1pl1 | 4.0.1b | 4.0.1pl1
4.0.1pl1 | 4.0.1a | 4.0.1pl1
4.0.1pl1 |4.0.1p1 | 4.0.1pl1
4.0.1pl1 | 4.0.1 | 4.0.1pl1
4.0.1b | 4.0.1b | equal
4.0.1b | 4.0.1a | 4.0.1b
4.0.1b |4.0.1p1 | 4.0.1b
4.0.1b | 4.0.1 | 4.0.1
4.0.1a | 4.0.1a | equal
4.0.1a |4.0.1p1 | 4.0.1a
4.0.1a | 4.0.1 | 4.0.1
4.0.1p1 |4.0.1p1 | equal
4.0.1p1 | 4.0.1 | 4.0.1
4.0.1 | 4.0.1 | equal
[2003-07-31 15:19:07] [EMAIL PROTECTED]
Um, PHP version 5.0.0b1 is a PHP version with a suffix. I'd call this
a valid bug, especially because this can be fixed by using
strnatcasecmp() instead of version_compare(). Perhaps this is a bug in
version_compare(), and should be noted as such?
Greg
[2003-07-31 14:50:16] [EMAIL PROTECTED]
Yes many developers have this problem because of lack of
documentation.
Opening back as a documentation problem (even if we don't have this
category for PEAR and btw we should have more categories for PEAR).
Can anyone write a little para on this?
[2003-07-31 14:16:24] [EMAIL PROTECTED]
this should be then at least noted in the PEAR developer
documenation... My package is not the first one with this problem
(and using p1 as suffix is pretty standard for software versions) so
that note is needed.
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/21611
--
Edit this bug report at http://bugs.php.net/?id=21611edit=1
#24827 [Csd]: ob_gzhandler overrides Vary header
ID: 24827
Updated by: [EMAIL PROTECTED]
Reported By: phpnet at shredzone dot de
Status: Closed
Bug Type: Zlib Related
Operating System: Linux
PHP Version: 4.3.2
New Comment:
Same as bug #23488
Previous Comments:
[2003-07-27 13:16:54] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-07-27 06:09:27] phpnet at shredzone dot de
Description:
I am using ob_gzhandler to compress the page output. Now I need to add
an 'accept-language' to the Vary header, because my page content
depends on the language settings of the browser.
Anyhow, it is impossible to change the Vary header when using
ob_gzhandler. It seems like ob_gzhandler is overriding an existing Vary
header just before returning the compressed content to the browser.
Expected behaviour: ob_gzhandler should check if a Vary header has
already been set. If so, it should only ADD an accept-encoding unless
already present, or should not change the Vary header at all.
Reproduce code:
---
?php
header(vary: accept-encoding,accept-language);
ob_start('ob_gzhandler');
print(htmlbodyfoo/body/html);
?
Expected result:
A HTTP header vary: accept-encoding,accept-language being returned.
Actual result:
--
A HTTP header Vary: Accept-Encoding (note the uppercase letters) will
always be returned.
--
Edit this bug report at http://bugs.php.net/?id=24827edit=1
#23488 [Opn]: zlib output compression clobbers user-supplied Vary: header
ID: 23488
Updated by: [EMAIL PROTECTED]
Reported By: m at mlcastle dot net
Status: Open
Bug Type: Feature/Change Request
Operating System: GNU/Linux 2.2.25
PHP Version: 4.3.1
New Comment:
Same as bug #24827
Previous Comments:
[2003-05-05 05:52:41] [EMAIL PROTECTED]
This issue has long been recognised since zlib.compression feature was
implemented.
The behaviour is quite expected = marking this as a feature request.
[2003-05-05 04:44:46] m at mlcastle dot net
If zlib.output_compression is on, then it (sensibly) sends a
Vary: Accept-Encoding
header to the browser. However, if the user's script has sent its own
Vary: header, then that header will get clobbered by zlib's. Better
solutions would be to either:
* let the user's header take preference, and caution the user to
include Accept-Encoding in the custom one, or
* magically combine the user's header and the zlib one.
Refernece: RFC 2616 (HTTP/1.1 Spec), Section 14.44
Sample script:
?php
ini_set('zlib.output_compression', 'on');
// do something with $_SERVER['HTTP_ACCEPT_LANGUAGE']
header('Vary: Accept-Language');
// output something
?
--
Edit this bug report at http://bugs.php.net/?id=23488edit=1
#23488 [Opn-Csd]: zlib output compression clobbers user-supplied Vary: header
ID: 23488
Updated by: [EMAIL PROTECTED]
Reported By: m at mlcastle dot net
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: GNU/Linux 2.2.25
PHP Version: 4.3.1
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-08-02 11:08:02] [EMAIL PROTECTED]
Same as bug #24827
[2003-05-05 05:52:41] [EMAIL PROTECTED]
This issue has long been recognised since zlib.compression feature was
implemented.
The behaviour is quite expected = marking this as a feature request.
[2003-05-05 04:44:46] m at mlcastle dot net
If zlib.output_compression is on, then it (sensibly) sends a
Vary: Accept-Encoding
header to the browser. However, if the user's script has sent its own
Vary: header, then that header will get clobbered by zlib's. Better
solutions would be to either:
* let the user's header take preference, and caution the user to
include Accept-Encoding in the custom one, or
* magically combine the user's header and the zlib one.
Refernece: RFC 2616 (HTTP/1.1 Spec), Section 14.44
Sample script:
?php
ini_set('zlib.output_compression', 'on');
// do something with $_SERVER['HTTP_ACCEPT_LANGUAGE']
header('Vary: Accept-Language');
// output something
?
--
Edit this bug report at http://bugs.php.net/?id=23488edit=1
#24916 [Opn-Fbk]: IIS6.0 CGI PHP header()
ID: 24916 Updated by: [EMAIL PROTECTED] Reported By: sadun at isikun dot org -Status: Open +Status: Feedback Bug Type: IIS related Operating System: Windows Server 2003 PHP Version: 4.3.2 New Comment: Please reply with all the headers php sends back. Previous Comments: [2003-08-02 08:11:28] sadun at isikun dot org it was working fine with ISAPI on IIS 6.0 but i need to use like CGI and i faced with CGI Error. i have searched the net but i can't find anything about it. [2003-08-02 08:06:02] sadun at isikun dot org Description: ;changes in php.ini error_reporting = E_ALL ~E_NOTICE register_globals = On include_path = .;W:\wwwroot\includes extension_dir = W:\php\extensions cgi.force_redirect = 0 cgi.redirect_status_env = ENV_VAR_NAME fastcgi.impersonate = 1 cgi.rfc2616_headers = 1 upload_tmp_dir = W:\php\phpupload extension=php_mbstring.dll extension=php_imap.dll extension=php_gd2.dll session.save_path = W:\php\phpsession session.auto_start = 1 Reproduce code: --- Header(Location: Http://.$GLOBALS[HTTP_HOST]./main.php?;); // i checked URL is correct Expected result: redirect to url Actual result: -- CGI Error The specified CGI application misbehaved by not returning a complete set of, HTTP headers. -- Edit this bug report at http://bugs.php.net/?id=24916edit=1
#24918 [NEW]: request for imagecolorget() function
From: sh at xcom dot pl Operating system: Linux PHP version: 4CVS-2003-08-02 (stable) PHP Bug Type: Feature/Change Request Bug description: request for imagecolorget() function Description: Currently it is impossible to know what is RGB of color handle. For example, I can get color handle from imagecolortransparent($img), but there is no way to extract RBG data from it. Sorry for my english. -- Edit bug report at http://bugs.php.net/?id=24918edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24918r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24918r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24918r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24918r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24918r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24918r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24918r=support Expected behavior: http://bugs.php.net/fix.php?id=24918r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24918r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24918r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24918r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24918r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24918r=dst IIS Stability: http://bugs.php.net/fix.php?id=24918r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24918r=gnused
#24918 [Opn-Bgs]: request for imagecolorget() function
ID: 24918 User updated by: sh at xcom dot pl Reported By: sh at xcom dot pl -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4CVS-2003-08-02 (stable) New Comment: Woops, imagecolorsforindex is doing the job... sorry. Previous Comments: [2003-08-02 11:26:57] sh at xcom dot pl Description: Currently it is impossible to know what is RGB of color handle. For example, I can get color handle from imagecolortransparent($img), but there is no way to extract RBG data from it. Sorry for my english. -- Edit this bug report at http://bugs.php.net/?id=24918edit=1
#24919 [NEW]: PHP File Uploads in RAM
From: jgiglio at smythco dot com Operating system: Linux PHP version: Irrelevant PHP Bug Type: Feature/Change Request Bug description: PHP File Uploads in RAM Description: PHP loads entire uploaded files into RAM, which makes the feature useless except for toy websites. PHP should be smart enough to spool large uploads to disk, like CGI.pm does. It would also be very nice if there were a way to get the name of the temp file spooled to, so that the user can be given feedback on their upload as it progresses, but this is not necessary. I'm putting this in as a feature request, because I know you guys don't consider it a bug. -- Edit bug report at http://bugs.php.net/?id=24919edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24919r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24919r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24919r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24919r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24919r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24919r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24919r=support Expected behavior: http://bugs.php.net/fix.php?id=24919r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24919r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24919r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24919r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24919r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24919r=dst IIS Stability: http://bugs.php.net/fix.php?id=24919r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24919r=gnused
#24919 [Opn-Bgs]: PHP File Uploads in RAM
ID: 24919 Updated by: [EMAIL PROTECTED] Reported By: jgiglio at smythco dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: Irrelevant New Comment: From http://www.php.net/manual/en/features.file-upload.php : Files will by default be stored in the server's default temporary directory, unless another location has been given with the upload_tmp_dir directive in php.ini. $_FILES['userfile']['tmp_name'] The temporary filename of the file in which the uploaded file was stored on the server. Previous Comments: [2003-08-02 12:16:42] jgiglio at smythco dot com Description: PHP loads entire uploaded files into RAM, which makes the feature useless except for toy websites. PHP should be smart enough to spool large uploads to disk, like CGI.pm does. It would also be very nice if there were a way to get the name of the temp file spooled to, so that the user can be given feedback on their upload as it progresses, but this is not necessary. I'm putting this in as a feature request, because I know you guys don't consider it a bug. -- Edit this bug report at http://bugs.php.net/?id=24919edit=1
#24909 [Opn-Fbk]: rand function with range always returns low value of range
ID: 24909 Updated by: [EMAIL PROTECTED] Reported By: a0 at hush dot com -Status: Open +Status: Feedback Bug Type: Math related Operating System: solaris 8 PHP Version: 4.3.2 New Comment: I've asked a number of people to replicate the problem, however they were unable to do so using latest PHP and Solaris 8 9. Please try the latest snapshot of 4.3.3 and see if the problem persists. Previous Comments: [2003-08-01 14:37:22] a0 at hush dot com Description: when using the rand function with php 4.3.2 on solaris 8, it will return a random value as expected if no range is specified. if a range is specified it will always return the low value of the range. i'm building the module with -DZTS, and it is being loaded into IWS4.1. i've modified the code so it works by changing line 36 of php_rand.h from #if HAVE_LRAND48 to #if (HAVE_LRAND48 !sun) so PHP_RAND_MAX will get a value of RAND_MAX. Reproduce code: --- ? $r = rand(); echo $r\n; $r = rand(0, 100); echo $r\n; ? Expected result: 24384 0 (it will always return 0) -- Edit this bug report at http://bugs.php.net/?id=24909edit=1
#24919 [Com]: PHP File Uploads in RAM
ID: 24919 Comment by: jgiglio at netmar dot com Reported By: jgiglio at smythco dot com Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: Irrelevant New Comment: Correct me if I am wrong, but since PHP caches the whole file in RAM before writing it out, that temp file name would be useless for purposes for letting the user know the progress of their upload (such as percentage complete). Previous Comments: [2003-08-02 12:28:56] [EMAIL PROTECTED] From http://www.php.net/manual/en/features.file-upload.php : Files will by default be stored in the server's default temporary directory, unless another location has been given with the upload_tmp_dir directive in php.ini. $_FILES['userfile']['tmp_name'] The temporary filename of the file in which the uploaded file was stored on the server. [2003-08-02 12:16:42] jgiglio at smythco dot com Description: PHP loads entire uploaded files into RAM, which makes the feature useless except for toy websites. PHP should be smart enough to spool large uploads to disk, like CGI.pm does. It would also be very nice if there were a way to get the name of the temp file spooled to, so that the user can be given feedback on their upload as it progresses, but this is not necessary. I'm putting this in as a feature request, because I know you guys don't consider it a bug. -- Edit this bug report at http://bugs.php.net/?id=24919edit=1
#24177 [Asn-Csd]: header() call doesn't replace 404 status code
ID: 24177
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: Closed
Bug Type: Apache2 related
Operating System: Linux
PHP Version: 4.3.3RC2-dev
Assigned To: iliaa
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-08-01 05:05:21] [EMAIL PROTECTED]
Summer is a killer on productivity. :)
Finally, here's the testcase I promised. It ended up pretty short...
Put the following lines in handler.php
?
header (location: http://www.php.net/;);
flush ();
?
Add ErrorDocument 404 /handler.php to your Apache config.
# lynx --head --dump http://mysite.com/nonexistant
HTTP/1.1 404 Not Found
Date: Fri, 01 Aug 2003 09:54:16 GMT
Server: Apache/2.0.46 (Unix) mod_ssl/2.0.46 OpenSSL/0.9.6b
PHP/4.3.3RC3-dev
X-Powered-By: PHP/4.3.3RC3-dev
location: http://www.php.net/
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Incorrect status 404, should be 302.
Remove flush(); from handler.php and try again:
# lynx --head --dump http://mysite.com/nonexistant
HTTP/1.1 302 Found
Date: Fri, 01 Aug 2003 09:56:17 GMT
Server: Apache/2.0.46 (Unix) mod_ssl/2.0.46 OpenSSL/0.9.6b
PHP/4.3.3RC3-dev
X-Powered-By: PHP/4.3.3RC3-dev
location: http://www.php.net/
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Now it works as expected. Apparently, somewhere inside flush() the
status is reset to 404.
Regards,
Fredrik
[2003-07-17 10:10:56] [EMAIL PROTECTED]
I've just tried out php4-STABLE-200307171330 and the problem is still
present.
I'll write a small testcase during the weekend so that you can easily
verify the bug.
Regards,
Fredrik
[2003-07-10 23:48:19] [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
Can you do a favor and test the latest CVS?
I have no time to setup a mirror just to test this.. :)
[2003-06-15 10:20:54] [EMAIL PROTECTED]
Yes. Odd at first.
After some experimentation I figured it out.
do-download.inc calls flush() on line 31. This causes the 'original'
status to be sent instead of the one specified by the call to
header().
If 4096 bytes or more are written before the flush the correct status
is sent.
I guess the codepath that handles an expicit flush manages to loose the
new status code somewhere.
I replaced echo with echo str_repeat(' ', 4096) and now our mirror
works fine and dandy again.
[2003-06-13 15:19:17] [EMAIL PROTECTED]
# lynx -dump -head http://se.php.net/imap
HTTP/1.1 200 OK
Date: Fri, 13 Jun 2003 19:17:17 GMT
Server: Apache/2.0.46 (Unix) mod_ssl/2.0.46 OpenSSL/0.9.6b PHP/4.3.2
X-Powered-By: PHP/4.3.2
Content-language: en
Set-Cookie: COUNTRY=FIN%2C213.243.181.8; expires=Fri, 20-Jun-2003
19:17:17 GMT;
path=/; domain=.php.net
Status: 200 OK
Last-Modified: Fri, 13 Jun 2003 19:09:38 GMT
Vary: Cookie
Connection: close
Content-Type: text/html;charset=ISO-8859-1
That works just fine?
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/24177
--
Edit this bug report at http://bugs.php.net/?id=24177edit=1
#24919 [Bgs]: PHP File Uploads in RAM
ID: 24919 Updated by: [EMAIL PROTECTED] Reported By: jgiglio at smythco dot com Status: Bogus Bug Type: Feature/Change Request Operating System: Linux PHP Version: Irrelevant New Comment: There's an inofficial patch for progress-bars, you can find it at http://pdoru.from.ro/ Previous Comments: [2003-08-02 13:26:05] jgiglio at netmar dot com Correct me if I am wrong, but since PHP caches the whole file in RAM before writing it out, that temp file name would be useless for purposes for letting the user know the progress of their upload (such as percentage complete). [2003-08-02 12:28:56] [EMAIL PROTECTED] From http://www.php.net/manual/en/features.file-upload.php : Files will by default be stored in the server's default temporary directory, unless another location has been given with the upload_tmp_dir directive in php.ini. $_FILES['userfile']['tmp_name'] The temporary filename of the file in which the uploaded file was stored on the server. [2003-08-02 12:16:42] jgiglio at smythco dot com Description: PHP loads entire uploaded files into RAM, which makes the feature useless except for toy websites. PHP should be smart enough to spool large uploads to disk, like CGI.pm does. It would also be very nice if there were a way to get the name of the temp file spooled to, so that the user can be given feedback on their upload as it progresses, but this is not necessary. I'm putting this in as a feature request, because I know you guys don't consider it a bug. -- Edit this bug report at http://bugs.php.net/?id=24919edit=1
#24909 [Fbk-Opn]: rand function with range always returns low value of range
ID: 24909 User updated by: a0 at hush dot com Reported By: a0 at hush dot com -Status: Feedback +Status: Open Bug Type: Math related Operating System: solaris 8 PHP Version: 4.3.2 New Comment: thanks for the response. i have downloaded 4.3.3RC2 and tried it. first, i configured it using no args. after i compiled it, the rand() function behaves as expected, even with a range specified. this works. i then configured it with --with-nsapi=/usr/local/iws41, which is what we need to use the module with our webserver. after i compiled it, the cli program now returns a 0 whenever a range is specified to rand(). i have not really looked through the code, but i would guess this has something to do with the fact that php is built with -DZTS in the second scenario (a different random function is used in rand.c when this is defined). Previous Comments: [2003-08-02 12:46:58] [EMAIL PROTECTED] I've asked a number of people to replicate the problem, however they were unable to do so using latest PHP and Solaris 8 9. Please try the latest snapshot of 4.3.3 and see if the problem persists. [2003-08-01 14:37:22] a0 at hush dot com Description: when using the rand function with php 4.3.2 on solaris 8, it will return a random value as expected if no range is specified. if a range is specified it will always return the low value of the range. i'm building the module with -DZTS, and it is being loaded into IWS4.1. i've modified the code so it works by changing line 36 of php_rand.h from #if HAVE_LRAND48 to #if (HAVE_LRAND48 !sun) so PHP_RAND_MAX will get a value of RAND_MAX. Reproduce code: --- ? $r = rand(); echo $r\n; $r = rand(0, 100); echo $r\n; ? Expected result: 24384 0 (it will always return 0) -- Edit this bug report at http://bugs.php.net/?id=24909edit=1
#24921 [NEW]: calling function with Class Type Hints arguments cause PHP crush
From: itotakas at msu dot edu
Operating system: Win 2000 Pro SP4
PHP version: 5CVS-2003-08-02 (dev)
PHP Bug Type: Reproducible crash
Bug description: calling function with Class Type Hints arguments cause PHP crush
Description:
calling function with Class Type Hints arguments cause PHP crush
Reproduce code:
---
?
class bug {
function get(bug $bug)
{
return $bug;
}
}
$bug = new bug;
// PHP should report the missing argument here
$bug-get();
?
Expected result:
showing error missing argument
Actual result:
--
PHP crush
--
Edit bug report at http://bugs.php.net/?id=24921edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24921r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24921r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24921r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24921r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24921r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24921r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24921r=support
Expected behavior: http://bugs.php.net/fix.php?id=24921r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24921r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24921r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24921r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24921r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24921r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24921r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24921r=gnused
#24050 [Opn-Csd]: mt_rand() returns 1898087491 too often
ID: 24050 Updated by: [EMAIL PROTECTED] Reported By: ptchristendom at yahoo dot com -Status: Open +Status: Closed Bug Type: Math related Operating System: win32 only PHP Version: 4.3.3-dev New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. This bug was related to a compilation problem on the shapshot box, which resulted in incorrect handling of floats. Previous Comments: [2003-06-06 02:07:37] [EMAIL PROTECTED] Can not reproduce within Linux, must be some windows only issue.. [2003-06-05 18:15:50] ptchristendom at yahoo dot com The function mt_rand() has a preference for the value 1898087491 for a majority (but not all) of the default seedings. As a result, if you don't seed it you will generate far too many collisions on the value 1898087491. If you seed it with values such as 0, 1, 2, 3, etc., the problem will not occur (these are all the seeds that I tried); however, the mt_rand should work properly when not seeded. Further, there SHOULD NOT be any single seed that causes this value to occur more than others. This leads me to believe that mt_rand() is not implemented correctly when not seeded. Here it says that it is not necessary to use mt_srand() to obtain random data: http://us3.php.net/manual/en/function.mt-srand.php - The following shows a test script that reproduces the problem: D:\php4-win32-STABLE-200306052030type unseeded2.php ? for ($i = 0; $i 25; $i++) print `php -q unseeded.php`.\n; ? D:\php4-win32-STABLE-200306052030type unseeded.php ? $j = 0; for ($i = 0; $i 65536; $i++) if (mt_rand() == 1898087491) $j++; print $j; ? D:\php4-win32-STABLE-200306052030php unseeded2.php Content-type: text/html X-Powered-By: PHP/4.3.3-dev 36480 39710 2308 41576 38524 39247 5005 5449 38011 29808 37577 5738 46785 42418 45619 42322 39296 15909 35019 39127 26830 37223 33348 22713 0 -- Edit this bug report at http://bugs.php.net/?id=24050edit=1
#24909 [Opn-Fbk]: rand function with range always returns low value of range
ID: 24909 Updated by: [EMAIL PROTECTED] Reported By: a0 at hush dot com -Status: Open +Status: Feedback Bug Type: Math related Operating System: solaris 8 PHP Version: 4.3.2 New Comment: I've tried the ZTS version on both Linux Windows and it worked perfectly in both cases. Did you run test via the nsapi module or using PHP cli or cgi binaries? Previous Comments: [2003-08-02 13:55:00] a0 at hush dot com thanks for the response. i have downloaded 4.3.3RC2 and tried it. first, i configured it using no args. after i compiled it, the rand() function behaves as expected, even with a range specified. this works. i then configured it with --with-nsapi=/usr/local/iws41, which is what we need to use the module with our webserver. after i compiled it, the cli program now returns a 0 whenever a range is specified to rand(). i have not really looked through the code, but i would guess this has something to do with the fact that php is built with -DZTS in the second scenario (a different random function is used in rand.c when this is defined). [2003-08-02 12:46:58] [EMAIL PROTECTED] I've asked a number of people to replicate the problem, however they were unable to do so using latest PHP and Solaris 8 9. Please try the latest snapshot of 4.3.3 and see if the problem persists. [2003-08-01 14:37:22] a0 at hush dot com Description: when using the rand function with php 4.3.2 on solaris 8, it will return a random value as expected if no range is specified. if a range is specified it will always return the low value of the range. i'm building the module with -DZTS, and it is being loaded into IWS4.1. i've modified the code so it works by changing line 36 of php_rand.h from #if HAVE_LRAND48 to #if (HAVE_LRAND48 !sun) so PHP_RAND_MAX will get a value of RAND_MAX. Reproduce code: --- ? $r = rand(); echo $r\n; $r = rand(0, 100); echo $r\n; ? Expected result: 24384 0 (it will always return 0) -- Edit this bug report at http://bugs.php.net/?id=24909edit=1
#24899 [Opn-Fbk]: errors compiling whith sybase
ID: 24899 Updated by: [EMAIL PROTECTED] Reported By: ejantos at yahoo dot com -Status: Open +Status: Feedback Bug Type: Sybase (dblib) related Operating System: redhat 9.0 PHP Version: 4.3.2 New Comment: Try adding --disable-ctype flag to your configure line and see if that resolves the problem. Previous Comments: [2003-08-01 02:34:45] ejantos at yahoo dot com Description: Hello, i'm trying to install php with sybase but i always get errors. what should i do? thanks in advance. tomio when i compile it i get this errors: /opt/sybase-11.9.2/lib/libsybdb.so: undefined reference to `__ctype_b' /opt/sybase-11.9.2/lib/libsybdb.so: undefined reference to `__ctype_tolower' collect2: ld returned 1 exit status make: *** [sapi/cli/php] Error 1 my configuration: ./configure \ --prefix=/usr/local/apache/httpd_1.3.28/php4 \ --with-apxs=/usr/local/apache/httpd_1.3.28/bin/apxs \ --disable-debug --enable-tracks-vars --enable-libgcc --enable-EAPI --enable-bcmath \ --with-tsrm-pthreads --enable-calendar --enable-ccvs --enable-cdb --enable-cpdflib --enable-ctype \ --enable-curl --enable-dba=shared --enable-dbase --enable-dbx --enable-dom --enable-exif --enable-ftp \ --enable-gd --enable-gdbm --enable-gettext --enable-hyperwave --enable-icap --enable-imap --enable-imap-ssl \ --enable-jpeg-dir --enable-kerberos --enable-mailparse --enable-magic-quotes --enable-mbstring \ --enable-mcal --enable-mcrypt --enable-mhash --enable-pdflib \ --enable-shmop --enable-sigchild --enable-snmp --enable-sysvsem --enable-sysvshm \ --with-pgsql=/usr \ --enable-tiff-dir --enable-trans-sid --enable-ttf --enable-unixODBC --enable-wddx \ --with-gmp --with-mysql=/usr \ --with-openssl=/usr --with-xml --enable-t1lib --with-t1lib=/usr/local --with-jpeg-dir=/usr/local \ --with-gd=/usr/local --enable-gd-native-ttf --enable-gd-imgstrttf \ --with-freetype-dir=/usr/local \ --enable-xpm --with-xpm-dir=/usr/X11R6 \ --with-png-dir=/usr/local --enable-png \ --enable-zlib --with-zlib-dir=/usr --enable-sockets \ --with-mm=/usr/local --with-bz2\ --enable-mbstr-enc-trans --enable-mbstring --enable-dbx --enable-dio \ --with-sybase=/opt/sybase-11.9.2 -- Edit this bug report at http://bugs.php.net/?id=24899edit=1
#19327 [Opn-Fbk]: java.lang.UnsatisfiedLinkError: no php_java in java.library.path
ID: 19327 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Java related Operating System: linux debian PHP Version: 4CVS-2002-09-10 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: [2003-03-05 01:37:07] robustwu at sina dot com I have searched many documents on phpbuilder ,but can not worked. your information of the linux order ln saved me .I am so thankful to you .:) and If somebody have the same problem ,you can contact me by mail [EMAIL PROTECTED] [2002-10-31 12:02:54] [EMAIL PROTECTED] yep, the java-extension works on my system, but only when i make this symlink. chregu [2002-10-31 11:52:43] [EMAIL PROTECTED] Did you setup the ini settings that tell the java.so where to look for javalibs classes? [2002-09-10 03:20:57] [EMAIL PROTECTED] I looked a little bit at the code php_java.jar tries to load the external library libphp_java.so in reflect.java with: System.loadLibrary(bundle.getString(library)); library is defined in Makefile.frag ) as @echo library=php_java $(srcdir)/net/php/reflect.properties but we can't change php_java to just java, because then we get conflicts with the main libjava.so. furthermore System.loadLibrary prepends lib before the library name, and searches for this name (libphp_java.so in this example). I didn't find a solution to tell java to look for just php_java.so ... Does anyone know a solution to this problem? chregu [2002-09-10 02:37:17] [EMAIL PROTECTED] A simple java test-script gives me the following error: java.lang.UnsatisfiedLinkError: no php_java in java.library.path when i make a symbolic link from $extensiondir$/java.so to $extensiondir$/libphp_java.so it works. Didn't find a quick solution for solving that problem. chregu -- Edit this bug report at http://bugs.php.net/?id=19327edit=1
#24909 [Fbk-Opn]: rand function with range always returns low value of range
ID: 24909 User updated by: a0 at hush dot com Reported By: a0 at hush dot com -Status: Feedback +Status: Open Bug Type: Math related Operating System: solaris 8 PHP Version: 4.3.2 New Comment: i used the cli binary in both cases Previous Comments: [2003-08-02 15:00:52] [EMAIL PROTECTED] I've tried the ZTS version on both Linux Windows and it worked perfectly in both cases. Did you run test via the nsapi module or using PHP cli or cgi binaries? [2003-08-02 13:55:00] a0 at hush dot com thanks for the response. i have downloaded 4.3.3RC2 and tried it. first, i configured it using no args. after i compiled it, the rand() function behaves as expected, even with a range specified. this works. i then configured it with --with-nsapi=/usr/local/iws41, which is what we need to use the module with our webserver. after i compiled it, the cli program now returns a 0 whenever a range is specified to rand(). i have not really looked through the code, but i would guess this has something to do with the fact that php is built with -DZTS in the second scenario (a different random function is used in rand.c when this is defined). [2003-08-02 12:46:58] [EMAIL PROTECTED] I've asked a number of people to replicate the problem, however they were unable to do so using latest PHP and Solaris 8 9. Please try the latest snapshot of 4.3.3 and see if the problem persists. [2003-08-01 14:37:22] a0 at hush dot com Description: when using the rand function with php 4.3.2 on solaris 8, it will return a random value as expected if no range is specified. if a range is specified it will always return the low value of the range. i'm building the module with -DZTS, and it is being loaded into IWS4.1. i've modified the code so it works by changing line 36 of php_rand.h from #if HAVE_LRAND48 to #if (HAVE_LRAND48 !sun) so PHP_RAND_MAX will get a value of RAND_MAX. Reproduce code: --- ? $r = rand(); echo $r\n; $r = rand(0, 100); echo $r\n; ? Expected result: 24384 0 (it will always return 0) -- Edit this bug report at http://bugs.php.net/?id=24909edit=1
#20110 [Com]: input in flex scanner failed in directory :)
ID: 20110 Comment by: olus at artcurie dot com Reported By: jeroen at unfix dot org Status: Closed Bug Type: Scripting Engine problem Operating System: Linux, Net|Free|OpenBSD, others? PHP Version: 4.2.3 Assigned To: derick New Comment: I have PHP Version 4.0.6 and Fatal error: input in flex scanner failed in directoryname on line 1 WHY WHY WHY!!! Previous Comments: [2003-07-12 20:05:07] daten at breitraum dot com hi, I got this bug too. PHP Version 4.2.3 I got a class CAdminBorder - extends CAdmin CAdmin extents CAdminAttitudes if the construktor of cadmin i used a function in CAdminAttitudes like this: $this-PasswordFile = $this-getPasswordFile(); result: Fatal error: input in flex scanner failed in mypath on line 1 Then I try this: $this-PasswordFile = parent::getPasswordFile(); everything works fine. [2003-03-20 16:59:41] bostjan dot skufca at domenca dot com you can view the bug at: http://www.avtomobilizem.com/dev/modules/gallery2 this project is using Smarty template engine and bug only occurs when i set $smarty-force_compile = false; email me to provide you relevant source files [2002-12-24 20:27:44] gunnar at start dot no This error also appears with other functions. More specifically I've experienced it with the parse_ini_file() function. I do not have access to test it with PHP CVS version, do I don't know wether it has been fixed for just the include function, or all functions affected by this problem. [2002-10-27 18:28:18] [EMAIL PROTECTED] This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. [2002-10-26 15:05:14] jeroen at unfix dot org Severity: Cosmetic for error reporting PHP Fatal error: input in flex scanner failed in directoryname When doing a: 8 include(/tmp/); 8 For instance will produce above error, maybe a You can't include directories would be nice? -- Edit this bug report at http://bugs.php.net/?id=20110edit=1
#24282 [NoF-Opn]: Strange Open Base Dir Restriction Errors
ID: 24282 User updated by: matzrek at shw-networks dot de Reported By: matzrek at shw-networks dot de -Status: No Feedback +Status: Open Bug Type: Apache related Operating System: Suse Linux 8.2 / Apache 1.3.27 PHP Version: 4.3.2 New Comment: Setting an empty open Basedir doesnt help. The only Solution at the moment is to activate teh safemode for the vhost. Previous Comments: [2003-07-29 07:25:46] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2003-07-24 20:59:15] [EMAIL PROTECTED] If you set an empty open_basedir for virtual host 'a', does the problem go away? [2003-06-24 13:01:21] matzrek at shw-networks dot de the error happend at two different configurations : a) VirtualHost 213.203.204.143 ServerAdmin [EMAIL PROTECTED] ServerName www.shw-network.de ServerAlias shw-network.de ServerAlias www.shw-networks.de ServerAlias shw-networks.de DocumentRoot /home/shw-network.de/htdocs ErrorLog /home/shw-network.de/log/error_log.log CustomLog /home/shw-network.de/log/access_log.log combined CustomLog /var/log/httpd/access_log.log combined /VirtualHost an b ) VirtualHost 213.203.204.143 ServerAdmin [EMAIL PROTECTED] DocumentRoot /home/cusomerdomain.de/htdocs/admin ServerName admin.cusomerdomain.de ServerAlias www.cusomerdomain.de ServerAlias cusomerdomain.de ErrorLog /home/cusomerdomain.de/log/error_log.log CustomLog /home/cusomerdomain.de/log/access_log.log combined CustomLog /var/log/httpd/access_log.log combined php_admin_flag safe_mode off php_admin_value open_base_dir /home/cusomerdomain.de php_admin_value safe_mode_exec_dir /bin /VirtualHost if the error happens or not seems to depend on the apache process wich handles the request. The Apache uptime may also have some effect - it did not happen, directly after an apache restart. [2003-06-23 21:48:57] [EMAIL PROTECTED] Do you set open_basedir in every vhost? What is open_basedir set to in your php.ini? What exactly is the open_basedir line like in your httpd.conf for the vhost you get this everytime for the first page request? Do you set any other php ini options there? Do any .htaccess files set any php ini options? [2003-06-21 20:49:35] matzrek at shw-networks dot de Description: Executing my PHP Script sometimes produces errors like this : Warning: Unknown(): open_basedir restriction in effect. File(/home/Domain1.com/htdocs/admin/index.php) is not within the allowed path(s): (/home/Domain2.de/) in Unknown on line 0 if i hit Reload the scripts will work fine. Of couse the script doesn't try to include files from /home/Domain2.de. Its not a problem of a spezial script, because many customers complained about this. Setting php_admin_value open_base_dir to none or / or /home doesnt solve this problem. safemode is disables (in vhost) Seems to be the same bug discussed here http://bugs.php.net/bug.php?id=19292 for a former Version Reproduce code: --- % phpinfo() ; % Expected result: PHP Info Page Actual result: -- requesting www.shw-networks.de/info.php : this error sems to apear only at the first page request !! Warning: Unknown(): open_basedir restriction in effect. File(/home/shw-network.de/htdocs/info.php) is not within the allowed path(s): (/home/xyz.de/) in Unknown on line 0 Warning: Unknown(/home/shw-network.de/htdocs/info.php): failed to open stream: Operation not permitted in Unknown on line 0 Warning: (null)(): Failed opening '/home/shw-network.de/htdocs/info.php' for inclusion (include_path='.:/usr/share/php') in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=24282edit=1
#22947 [Com]: mail function hang-up
ID: 22947
Comment by: phpbugs at pligplob dot com
Reported By: me at mattbeale dot plus dot com
Status: Bogus
Bug Type: Mail related
Operating System: Windows 2000 SP4
PHP Version: 4CVS-2003-04-29 (stable)
New Comment:
This does seem to be a fault in the Windows code, the Ack() function in
sendmail.c:
win32/sendmail.c(Ack):
...
if ((buf[Received - 4] == ' ' buf[Received - 3] == '-') ||
...
It is specifically disallowing SPACE HYPHEN at the end of the SMTP
reply text that PlusNet's server is sending, but that seems to be
allowed by RFC2821.
However, since someone has deliberately blocked this pattern there must
be a reason for it, but it seems invalid to me.
When I modifed the php4ts.dll to use EHLO instead of HELO the SMTP
exchange completed successfully. PlusNet's server avoids the illegal
SPACE HYPHEN in its extended reply, so the hangup doesn't occur.
Previous Comments:
[2003-07-30 15:39:46] me at mattbeale dot plus dot com
In addition to my previous message:
This PHP code works fine on both machines that have problems. I doubt I
need to tell you what it does?:
?php
function bytesleft($fp) {
$status = socket_get_status($fp);
$bytes = $status['unread_bytes'];
return $bytes;
}
function sendtext($str) {
global $fp;
echo $str;
flush();
fwrite($fp, $str);
$ret = fread($fp, 1);
$ret.= fread($fp, bytesleft($fp));
return $ret;
}
$fp = false;
if ($fp = fsockopen('relay.plus.net', 25, $errno, $errstr, 1)) {
socket_set_timeout($fp, 1);
$hash = md5(uniqid(rand()));
echo sendtext(HELO server\r\n);
echo sendtext(MAIL FROM: [EMAIL PROTECTED]);
echo sendtext(RCPT TO: [EMAIL PROTECTED]);
echo sendtext(DATA\r\n);
echo sendtext(From: Matt Beale [EMAIL PROTECTED]\r\n);
echo sendtext(Subject: [PHP] Test Subject - {$hash}\r\n);
echo sendtext(To: Matt Beale [EMAIL PROTECTED]\r\n);
echo sendtext(\r\n);
echo sendtext(This is a test message sent from PHP\r\n);
echo sendtext(\r\n);
echo sendtext(Hash: {$hash}\r\n);
echo sendtext(.\r\n);
echo sendtext(QUIT\r\n);
fclose($fp);
}
?
If Andrew happens to read this, I'd be interested to know if it works
for him. Plus I'd be very interested in what the PHP developers think
might be going on.
[2003-07-30 07:54:51] me at mattbeale dot plus dot com
I wouldn't know what else to try and eliminate. I've tried two
operating systems with different service packs and two methods of
Internet Connection (Router and USB Modem). The only thing I can't
change is my ISP.
I can only conclude that there must be something 'up' with my ISPs mail
server, but if that is the case why do I only get problems with PHP?
Everything else works fine - I can send mail from Outlook/Outlook
Express/Mozilla fine and I also use POPFile 0.19.1 on my server which
has no problems with communicating with my ISPs mail server. If there
were really problems with my ISPs mail server, wouldn't I experience
similar problems in the other applications I use?
[2003-07-30 02:05:33] [EMAIL PROTECTED]
I can't reproduce this either, must be local problem to you only. (we'd
have hundreds of reports about this if it really was a bug)
[2003-07-29 16:05:54] me at mattbeale dot plus dot com
There does appear to be a very slight change. PHP now appears to be
replying to the server after the initial HELO machinename command,
but the reply always consists of just header and no data. I have
created a second csv export which shows the changes if it is of any
use:
http://www.mattbeale.plus.com/phpbug22947/phpbug22957-4.3.3RC2.csv
I have also tested this snapshot on my Windows XP machine, as well as
on my Windows 2000 machine (which has now been upgraded to Service Pack
4) both running Apache 1.3.28 and the latest PHP snapshot and have also
tried using a non-NAT connection via ye-olde-faithful Alcatel
Speedtouch USB Modem rather than my DSL router, but the same problems
still occur on both machines.
[2003-07-29 12:58:22] [EMAIL PROTECTED]
I can't replicate this on win98 with either 4.3.2-RC3-dev
or 5.0.0b2-dev (though it's noticeably faster with PHP 5).
Can someone on a later version of windows please test with a recent PHP
snapshot and confirm whether there's still a problem?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view
#22546 [Com]: fread (maybe in connection with fseek) do not read length bytes
ID: 22546
Comment by: diz at ysagoon dot com
Reported By: 4u at direct-netware dot de
Status: Bogus
Bug Type: Filesystem function related
Operating System: WinNT
PHP Version: 4.3.1
New Comment:
Ok, well the problem I spoke about is solved with PHP 4.3.2.
Gabriel
Previous Comments:
[2003-08-02 05:56:38] diz at ysagoon dot com
I don't know if this is related, but I think so. Please tell me if I
should better submit this as a new bug.
The fseek teleports my file pointer to some strange places. I'm using
Win2K (NT5 SP4) with administrative rights and I'm running EasyPhp
1.6.0.0 that contains PHP 4.2.0. But the same script works on Debian
GNU/Linux 2.2.20 with PHP 4.1.2!
Here's my example script (note that none of the two fseek methods
work):
function getChar($fp, $c)
{
$c=fgetc($fp);
if(feof($fp))
return false;
return true;
}
$fp=fopen('parseTest.txt','r');
while(true)
{
$c=fgetc($fp);
if(feof($fp))
break;
echo($c);
//fseek($fp, -1, SEEK_CUR);
fseek($fp, ftell($fp)-1);
$c=fgetc($fp);
if(feof($fp))
break;
echo($c);
}
fclose($fp);
echo('EOF');
The file that I read contains just this:
Hello World!
The correct output on Debian GNU/Linux 2.2.20 with PHP 4.1.2:
hheeoo wwoorrlldd!!
EOF
The problematic output on Win2k with PHP 4.2.0:
hEOF
Ok that's it. Thank you for your support! :)
Gabriel
[2003-03-05 08:17:52] 4u at direct-netware dot de
Strange things happening here - I will check it before getting on your
nerves again ;)
[2003-03-05 07:54:57] 4u at direct-netware dot de
I know how to install PHP using a ZIP-file...
1,22 MB (1.286.144 Bytes) - Is this the right dll? (At least this is
the dll in the snapshot I downloaded - Last edited today)
The error still exists with the dll, mentioned above!
[2003-03-05 06:48:56] [EMAIL PROTECTED]
Just replace every existing php4ts.dll with the new one from the
snapshot package..and make sure nothing is running when you do this.
[2003-03-05 06:25:52] 4u at direct-netware dot de
I'm sorry, but then the bug isn't (completly?) removed - used snapshot
resulting fread-error: php4-win32-STABLE-200303050930
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/22546
--
Edit this bug report at http://bugs.php.net/?id=22546edit=1
