#29258 [Com]: conversion between unix timestamp and variant VT_date
ID: 29258
Comment by: norny at yahoo dot com
Reported By: arnout at argeweb dot nl
Status: Closed
Bug Type: COM related
Operating System: Windows 2003 server,standard
PHP Version: 5.0.0
New Comment:
Was this applied to php 4.3.9? I'm having a similar problem with times
after applying some Win2k3 server critical updates.
Previous Comments:
[2004-07-28 09:13:36] arnout at argeweb dot nl
Seems to be fixed in CVS. Thanks!
[2004-07-22 14:49:13] [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
Please try a snapshot.
[2004-07-19 15:19:43] arnout at argeweb dot nl
Description:
Converting dates using variant_date_from_timestamp() loses 2 hours.
Might be some timezone-like thing but then again:
variant_date_to_timestamp() does give a precise translation.
I'm running apache 2 with php 5.0.0 RC 2. I tried both CGI and through
apache.
Reproduce code:
---
?
$nu = date('Ymd');
echo now: $nu\n;
$timestamp = mktime( 0, 0, 0, date('m'), date('d'), date('Y') ); //
Ymd = 2004 07 19
echo now timestamp: $timestamp\n;
echo a.k.a. : .$timestamp. = .date('Ymd', $timestamp ).\n;
$variant = variant_date_from_timestamp( $timestamp );
//$variant = variant_date_from_timestamp( time() );
echo variant: .$variant.\n;
$var_timestamp = variant_date_to_timestamp( $variant );
echo and back again: .$var_timestamp. = .date('Ymd', $var_timestamp
).\n;
?
Expected result:
now: 20040719
now timestamp: 1090188000
a.k.a. : 1090188000 = 20040719
variant: 19-7-2004 0:00:00
and back again: 1090188000 = 20040719
Actual result:
--
now: 20040719
now timestamp: 1090188000
a.k.a. : 1090188000 = 20040719
variant: 18-7-2004 22:00:00
and back again: 1090180800 = 20040718
// 2 hours gone! And even worse: The date changed!
--
Edit this bug report at http://bugs.php.net/?id=29258edit=1
#24822 [NEW]: order of function scope searching doesn't match docs
From: norny at yahoo dot com
Operating system: Windows XP
PHP version: 5CVS-2003-07-26 (dev)
PHP Bug Type: Zend Engine 2 problem
Bug description: order of function scope searching doesn't match docs
Description:
According to http://www.php.net/ZEND_CHANGES.txt,
WIth both constants and functions, if you don't specify a class context
the current class will be searched first and if the search fails then the
global scope will be searched. If you want to force PHP to only check the
global scope you can use the main:: accessor.
The snap I just downloaded seems to be search global first then the class
second. Main:: doesn't seem to exist.
Reproduce code:
---
?php
function asdf() {
echo 'global';
}
class FooClass {
function asdf() {
echo 'class';
}
function printFoo() {
asdf(); // outputs 'global'
self::asdf(); // outputs 'class'
main::asdf(); // Fatal error: Class 'main' not found in
C:\Apache2\htdocs\test.php on line 14
}
}
$qwerty = new FooClass;
$qwerty-printFoo();
?
Expected result:
The first call to asdf() in printFoo should produce 'class'. The second
self::asdf() seems to be correct, and the main::asdf() should print
'global'
Actual result:
--
The first call to asdf() in printFoo() should print 'class', not 'global'.
The main:: accessor doesn't seem to be known but ZEND_CHANGES.txt says it
does exist.
--
Edit bug report at http://bugs.php.net/?id=24822edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24822r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24822r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=24822r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=24822r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24822r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=24822r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24822r=support
Expected behavior: http://bugs.php.net/fix.php?id=24822r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24822r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24822r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=24822r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24822r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=24822r=dst
IIS Stability: http://bugs.php.net/fix.php?id=24822r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24822r=gnused
#16676 [Com]: ob_implicit_flush not turning off ob
ID: 16676 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won\'t fix Bug Type: Output Control Operating System: Slackware 8.0 PHP Version: 4.2.0 New Comment: We don't seem to be communicating very well. I've been wanting to shut off buffering this whole time. Your suggestion to not buffer if I don't need it is just telling me what I already want to do. I've been trying to use the functions documented in the manual that are supposed to shut it off, but they have a big Won't fix label on them in the bug database. How about if I word it differently. I want the default buffer handling set in php.ini for my webpage output, but I don't want buffers for my command line scripts. I want those to output something to STDOUT as soon as it comes to a echo/print. If I don't use ob_end_flush, ob_implicit_flush, or ini_set, then what should I use to turn off buffering in my command line scripts. Previous Comments: [2003-01-11 17:08:45] [EMAIL PROTECTED] And don't forget that some buffers should never be deleted once it's started. The error message is raised, since some users don't know it shouldn't. [2003-01-11 17:05:17] [EMAIL PROTECTED] Since current output buffer is statelss even if some buffers need stateful handling to prevent crashes/malformed output/ etc. Don't start buffer if you don't need it. Complain people who insisted this behavior. Search php-dev archive ;) [2003-01-10 12:32:43] [EMAIL PROTECTED] Now I'm getting a PHP notice in Windows XP using PHP 4.3.0 from the cmd line. PHP Notice: ob_end_flush() [a href='http://www.php.net/ref.outcontrol'ref.outcontrol/a]: failed to delete buffer default output handler. in C:\Apache\cgi-bin\mybot.php on line 58 In previous versions, ob_end_flush was my workaround to ob_implicit_flush not working. In 4.3.0 ob_end_flush isn't working for me and it does work in 4.2.3. Could someone make at least one of the two work again instead of keeping the Won't fix status? [2002-12-27 08:35:57] [EMAIL PROTECTED] Should have been won't fix [2002-12-27 08:16:53] [EMAIL PROTECTED] It is easy to make it actually flush output. Difficult part is make it work always. Some output buffers shouldn't be deleted and cannot be deleted. i.e. Some browsers will freeze if server send malformed compressed output. Thus ob_end_flush() wouldn't and shouldn't work in some cases. If it works, it's a bug should be fixed. Fix is simple, but you have to live with that. If you are interested, search php-dev archive. BTW, ob_implicit_flush() simply enable SAPI level auto flushing even if its name imply PHP output buffer flushing. Don't blame me, I'm for fixing it ;) 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/16676 -- Edit this bug report at http://bugs.php.net/?id=16676edit=1
#16676 [Com]: ob_implicit_flush not turning off ob
ID: 16676 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Won\'t fix Bug Type: Output Control Operating System: Slackware 8.0 PHP Version: 4.2.0 New Comment: Now I'm getting a PHP notice in Windows XP using PHP 4.3.0 from the cmd line. PHP Notice: ob_end_flush() [a href='http://www.php.net/ref.outcontrol'ref.outcontrol/a]: failed to delete buffer default output handler. in C:\Apache\cgi-bin\mybot.php on line 58 In previous versions, ob_end_flush was my workaround to ob_implicit_flush not working. In 4.3.0 ob_end_flush isn't working for me and it does work in 4.2.3. Could someone make at least one of the two work again instead of keeping the Won't fix status? Previous Comments: [2002-12-27 08:35:57] [EMAIL PROTECTED] Should have been won't fix [2002-12-27 08:16:53] [EMAIL PROTECTED] It is easy to make it actually flush output. Difficult part is make it work always. Some output buffers shouldn't be deleted and cannot be deleted. i.e. Some browsers will freeze if server send malformed compressed output. Thus ob_end_flush() wouldn't and shouldn't work in some cases. If it works, it's a bug should be fixed. Fix is simple, but you have to live with that. If you are interested, search php-dev archive. BTW, ob_implicit_flush() simply enable SAPI level auto flushing even if its name imply PHP output buffer flushing. Don't blame me, I'm for fixing it ;) [2002-12-24 21:39:37] [EMAIL PROTECTED] You can solve your problem by putting @ob_end_flush(); on top of your command line scripts. [2002-12-24 16:25:58] [EMAIL PROTECTED] iliaa, I appreciate you trying to point me to help, but I still think I'm right about this bug report. I've tried it on several machines with each stable version of PHP since the report. Now still with 4.2.3 I'm seeing the same thing. Again, I'm not using zlib output compression cause I let mod_gzip do that in apache. This is for a php shell script. As you said, flush would send the output, but according to the documentation, ob_implicit_flush() should result in a flush operation after every output call, so that explicit calls to flush() will no longer be needed. I'm saying ob_implicit_flush is broken in 4.2.x and does not call flush() after each echo, or if it does, it's still not outputting to STDOUT. By default, php.ini has 4k of output buffering. I want to leave that for the rest of the applications I'm running and since you can't modify the ini value with ini_set(), I'm resorting to the ob_* functions. Instead of calling ob_end_flush() at the start of the script cause according to the docs on that, as part of its functionality, it turns off ob. Either way, I'm getting output buffering turned off while leaving 4k buffering in php.ini, but I doesn't mean that ob_implicit_flush() might still be not working right. I guess I'll just wait a few more days for 4.3.0 and try that out. [2002-09-26 16:47:23] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. if you are not using ob and do not have gzip compression enabled, then by simply doing flush(); you'll get the data your are outputing sent to screen without any output buffering. 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/16676 -- Edit this bug report at http://bugs.php.net/?id=16676edit=1
#16676 [Com]: ob_implicit_flush not turning off ob
ID: 16676 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Output Control Operating System: Slackware 8.0 PHP Version: 4.2.0 New Comment: iliaa, I appreciate you trying to point me to help, but I still think I'm right about this bug report. I've tried it on several machines with each stable version of PHP since the report. Now still with 4.2.3 I'm seeing the same thing. Again, I'm not using zlib output compression cause I let mod_gzip do that in apache. This is for a php shell script. As you said, flush would send the output, but according to the documentation, ob_implicit_flush() should result in a flush operation after every output call, so that explicit calls to flush() will no longer be needed. I'm saying ob_implicit_flush is broken in 4.2.x and does not call flush() after each echo, or if it does, it's still not outputting to STDOUT. By default, php.ini has 4k of output buffering. I want to leave that for the rest of the applications I'm running and since you can't modify the ini value with ini_set(), I'm resorting to the ob_* functions. Instead of calling ob_end_flush() at the start of the script cause according to the docs on that, as part of its functionality, it turns off ob. Either way, I'm getting output buffering turned off while leaving 4k buffering in php.ini, but I doesn't mean that ob_implicit_flush() might still be not working right. I guess I'll just wait a few more days for 4.3.0 and try that out. Previous Comments: [2002-09-26 16:47:23] [EMAIL PROTECTED] Sorry, but the bug system is not the appropriate forum for asking support questions. 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 Thank you for your interest in PHP. if you are not using ob and do not have gzip compression enabled, then by simply doing flush(); you'll get the data your are outputing sent to screen without any output buffering. [2002-04-18 11:34:07] [EMAIL PROTECTED] If you need to flush, do not use output buffers at all. That's what I'm trying to do, use ob_implicit_flush() at the beginning of my script to turn off ob. Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work. I'm not wanting to change encoding or turn zlib compression on/off the middle of a script. I just have a basic 400 line script I'd like to output. I simply don't want to have ob turned on. [2002-04-18 06:12:03] [EMAIL PROTECTED] Don't worray, it's known issue. I can make it flush when all output buffers registered may be flushed, otherwise it just does not work. Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work. If you need to flush, do not use output buffers at all. Note: Older PHP is just deleted the last output buffer registered with ob_implicit_flush. This is wrong behavior. [2002-04-18 03:50:26] [EMAIL PROTECTED] I tried leaving output_buffering = 4096 in php.ini and turning on implicit_flush in php.ini, and it's still not flushing my echo lines till the end of script execution, so neither the function or the ini config are working for me. If I make output_buffering = 0, it flushes correctly as expected, but as I understand it, the whole point of ob_implicit_flush() in runtime is to override the default ini config which is what I want to do. [2002-04-18 03:43:38] [EMAIL PROTECTED] I can't change the status to 'Open', but I can say zlib.output_compression is off. 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/16676 -- Edit this bug report at http://bugs.php.net/?id=16676edit=1
Bug #16676: ob_implicit_flush not turning off ob
From: [EMAIL PROTECTED] Operating system: Slackware 8.0 PHP version: 4.2.0 PHP Bug Type: Output Control Bug description: ob_implicit_flush not turning off ob I have a php shell script that outputs ~100 char lines using echo. I'm trying to work around the default php.ini configuration of a 4k automatic buffer and flush the lines to the console for debugging. Calling ob_flush() after each echo, echos the lines immediately, putting ob_end_flush() at the beginning of the script turns off ob so I get immediate output, but ob_implicit_flush() and ob_implicit_flush(1) don't seem to automatically flush after each echo. I have to wait till the end of the script execution to see the output when I try ob_implicit_flush. Using ob_end_flush() is my workaround for now. Same difference whether I use echo or print. This is for RC4. -- Edit bug report at http://bugs.php.net/?id=16676edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16676r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16676r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16676r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16676r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16676r=support Expected behavior: http://bugs.php.net/fix.php?id=16676r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16676r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16676r=submittedtwice
Bug #16676 Updated: ob_implicit_flush not turning off ob
ID: 16676 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Output Control Operating System: Slackware 8.0 PHP Version: 4.2.0 New Comment: I can't change the status to 'Open', but I can say zlib.output_compression is off. Previous Comments: [2002-04-18 02:57:57] [EMAIL PROTECTED] I guess you are enabling zlib.output_compression. If you are not, please change Status to Open. Thank you. [2002-04-18 02:19:29] [EMAIL PROTECTED] I have a php shell script that outputs ~100 char lines using echo. I'm trying to work around the default php.ini configuration of a 4k automatic buffer and flush the lines to the console for debugging. Calling ob_flush() after each echo, echos the lines immediately, putting ob_end_flush() at the beginning of the script turns off ob so I get immediate output, but ob_implicit_flush() and ob_implicit_flush(1) don't seem to automatically flush after each echo. I have to wait till the end of the script execution to see the output when I try ob_implicit_flush. Using ob_end_flush() is my workaround for now. Same difference whether I use echo or print. This is for RC4. -- Edit this bug report at http://bugs.php.net/?id=16676edit=1
Bug #16676 Updated: ob_implicit_flush not turning off ob
ID: 16676 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Output Control Operating System: Slackware 8.0 PHP Version: 4.2.0 New Comment: I tried leaving output_buffering = 4096 in php.ini and turning on implicit_flush in php.ini, and it's still not flushing my echo lines till the end of script execution, so neither the function or the ini config are working for me. If I make output_buffering = 0, it flushes correctly as expected, but as I understand it, the whole point of ob_implicit_flush() in runtime is to override the default ini config which is what I want to do. Previous Comments: [2002-04-18 03:43:38] [EMAIL PROTECTED] I can't change the status to 'Open', but I can say zlib.output_compression is off. [2002-04-18 02:57:57] [EMAIL PROTECTED] I guess you are enabling zlib.output_compression. If you are not, please change Status to Open. Thank you. [2002-04-18 02:19:29] [EMAIL PROTECTED] I have a php shell script that outputs ~100 char lines using echo. I'm trying to work around the default php.ini configuration of a 4k automatic buffer and flush the lines to the console for debugging. Calling ob_flush() after each echo, echos the lines immediately, putting ob_end_flush() at the beginning of the script turns off ob so I get immediate output, but ob_implicit_flush() and ob_implicit_flush(1) don't seem to automatically flush after each echo. I have to wait till the end of the script execution to see the output when I try ob_implicit_flush. Using ob_end_flush() is my workaround for now. Same difference whether I use echo or print. This is for RC4. -- Edit this bug report at http://bugs.php.net/?id=16676edit=1
Bug #16676 Updated: ob_implicit_flush not turning off ob
ID: 16676 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Output Control Operating System: Slackware 8.0 PHP Version: 4.2.0 New Comment: If you need to flush, do not use output buffers at all. That's what I'm trying to do, use ob_implicit_flush() at the beginning of my script to turn off ob. Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work. I'm not wanting to change encoding or turn zlib compression on/off the middle of a script. I just have a basic 400 line script I'd like to output. I simply don't want to have ob turned on. Previous Comments: [2002-04-18 06:12:03] [EMAIL PROTECTED] Don't worray, it's known issue. I can make it flush when all output buffers registered may be flushed, otherwise it just does not work. Imagine turning on/off compression, converting one encoding to another, etc in the middle of transmission. It just does not work. If you need to flush, do not use output buffers at all. Note: Older PHP is just deleted the last output buffer registered with ob_implicit_flush. This is wrong behavior. [2002-04-18 03:50:26] [EMAIL PROTECTED] I tried leaving output_buffering = 4096 in php.ini and turning on implicit_flush in php.ini, and it's still not flushing my echo lines till the end of script execution, so neither the function or the ini config are working for me. If I make output_buffering = 0, it flushes correctly as expected, but as I understand it, the whole point of ob_implicit_flush() in runtime is to override the default ini config which is what I want to do. [2002-04-18 03:43:38] [EMAIL PROTECTED] I can't change the status to 'Open', but I can say zlib.output_compression is off. [2002-04-18 02:57:57] [EMAIL PROTECTED] I guess you are enabling zlib.output_compression. If you are not, please change Status to Open. Thank you. [2002-04-18 02:19:29] [EMAIL PROTECTED] I have a php shell script that outputs ~100 char lines using echo. I'm trying to work around the default php.ini configuration of a 4k automatic buffer and flush the lines to the console for debugging. Calling ob_flush() after each echo, echos the lines immediately, putting ob_end_flush() at the beginning of the script turns off ob so I get immediate output, but ob_implicit_flush() and ob_implicit_flush(1) don't seem to automatically flush after each echo. I have to wait till the end of the script execution to see the output when I try ob_implicit_flush. Using ob_end_flush() is my workaround for now. Same difference whether I use echo or print. This is for RC4. -- Edit this bug report at http://bugs.php.net/?id=16676edit=1
Bug #15646 Updated: the flush() does not flush the output buffer
ID: 15646 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Output Control Operating System: Windows 2000 SP2 PHP Version: 4.1.1 New Comment: I don't think this is a bug, although I do think bug #16676 is a bug. The default configuration of php.ini automatically buffers 4k of output whether you called ob_start() in the script or not. Since you only have 5 bytes of output, it'll fit well within the 4k of default buffering. Instead of using plain flush(), use ob_flush(), ob_end_flush() at the start of your script, or change the amount of default buffering in your php.ini. If ob_implicit_flush() worked right, you could use it just once at the beginning of your script. See bug #16676 for discoveries with ob. Previous Comments: [2002-02-25 03:13:51] [EMAIL PROTECTED] Well, I dont think its a browser nor http server issue - I do not use any of these (as I wrote in the original post), only the command-line version. regards, [2002-02-24 11:44:37] [EMAIL PROTECTED] well..another thing... I have the same problem... but it's the same server (apache 1.3.23, php 4.1.1 on linux). the problem occurs in ms ie, but not in nn4 or or mozilla. so maybe it's a browser issue [2002-02-24 11:43:02] [EMAIL PROTECTED] well..another thing... I have the same problem... but it's the same server (apache 1.3.23, php 4.1.1 on linux). the problem occurs in ms ie, but not in nn4 or or mozilla. so maybe it's a browser issue [2002-02-24 05:55:53] [EMAIL PROTECTED] flush feature is needed to be fixed ;) If you really need to flush, do not use output buffering. (Without output buffering, PHP always outputs immediately when output is issued) [2002-02-21 04:55:32] [EMAIL PROTECTED] another $0.02: i compiled PHP succesfully using cygwin environment and it 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/15646 -- Edit this bug report at http://bugs.php.net/?id=15646edit=1
Bug #16601 Updated: php_bz2.dll won't load
ID: 16601 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Documentation problem Operating System: Windows 2000 PHP Version: 4.2.0RC4 New Comment: I resolved the interbase and mssql issues with the comment from jtate, but I still can't get bz2 to load without error. qa.php.net also mentions a xslt dll. I haven't seen one in the 4.2.0RC4, but I have seen sablot.dll and expat.dll that would go with it. Previous Comments: [2002-04-15 12:23:24] [EMAIL PROTECTED] Dll's won't load if the dll's that it depends on aren't in the path. Use the dependency walker that comes with Vis Studio to see what you're missing. Same with the php_mssql.dll or whatever bug you reported with this one. This should be documented IMO. [2002-04-14 20:22:58] [EMAIL PROTECTED] I'm just trying to make sure we're talking about the same files. Md5 hashes of the extensions: 1c9a9f9ae388b133dbeab61063815948 *php_bz2.dll 61d87a3f4ec9422ee9e20b56ab2b3b43 *php_ctype.dll 6e09ae3bc21c4cc728aa782d9234dde2 *php_db.dll 22645ae3539be2772a07e043dbe190c2 *php_dbase.dll 26f38f936ed167b8fc5708188df7e766 *php_dbx.dll dc5870f7c29b9f7df69319faea1303cb *php_exif.dll 19bcf59e0d961de84a15da848b35b151 *php_filepro.dll 91678442412c2a4518843df3306f2220 *php_hyperwave.dll bed398dccac4ff7d38f93c8c9e7ff5c8 *php_interbase.dll 776f46de368bb1d73fa1cdb771375ab6 *php_mbstring.dll 8d56fd8a95be55b8ff2e457a1b4d0a0b *php_msql.dll 585cfb220aab52b6b2f449ae7ce18c6c *php_mssql.dll d7b11b5c22cd81b7b4fbf1f66197ee12 *php_shmop.dll 224ece12a772b6644e72fc8a082d9e4e *php_sockets.dll cc4edd5f195184b276d5dc8f6766a9b0 *php_tokenizer.dll 0282c8433060d40285b0b17dd7b077d2 *php_w32api.dll 75b316bbeea00450120f0202b6f50bc1 *php-cli.exe 98651ce0e734f67c75be03f44a7ab39b *php.exe a8ce4d9eeba45b6b4e38df24fb778c41 *php.ini-dist 9725886dbee0c3cb820146d75563cb8a *php.ini-recommended 93bb56a327068002f2ce96e991d9ce62 *php4ts.lib 52d05cf883b6e0410add9e15b2352f7b *php4ts.dll [2002-04-14 20:13:50] [EMAIL PROTECTED] I rolled up all my stuff for previous versions of php into one big zip file so I could have only 1 php4ts.dll on my system, located in c:\winnt\system32. Then I did a file search for php4ts.dll to double check. The filesize of the php4ts.dll in my directory is 1,028,096 bytes with a md5 hash of 52d05cf883b6e0410add9e15b2352f7b. Then I did a search for php* in c:\winnt and it found php4ts.dll and php.ini. I still get errors for bz2, interbase, and mssql. [2002-04-14 19:53:10] [EMAIL PROTECTED] it seems you have conflicting php4ts.dll's. I suggest you remove all of the files you had during install, and start again. This is probably the easiest method of trying it out. as far as i can see, that module loads fine for me. [2002-04-14 19:48:38] [EMAIL PROTECTED] The 'expose_php' header also appears in the regular page output for phpinfo() when there's an error popup. X-Powered-By: PHP/4.2.0RC4 Content-type: text/html 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/16601 -- Edit this bug report at http://bugs.php.net/?id=16601edit=1
Bug #16601: php_bz2.dll won't load
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.2.0 PHP Bug Type: Bzip2 Related Bug description: php_bz2.dll won't load I tried just to load all the extensions in 4.2.0RC4. I get a popup notice that says php_bz2.dll can't be found even though it's in the same directory with all the other extensions that load fine. -- Edit bug report at http://bugs.php.net/?id=16601edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16601r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16601r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16601r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16601r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16601r=support Expected behavior: http://bugs.php.net/fix.php?id=16601r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16601r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16601r=submittedtwice
Bug #16602: php_interbase.dll won't load
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.2.0 PHP Bug Type: InterBase related Bug description: php_interbase.dll won't load I tried just to load all the extensions in 4.2.0RC4. I get a popup notice that says php_interbase.dll can't be found even though it's in the same directory with all the other extensions that load fine. -- Edit bug report at http://bugs.php.net/?id=16602edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16602r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16602r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16602r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16602r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16602r=support Expected behavior: http://bugs.php.net/fix.php?id=16602r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16602r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16602r=submittedtwice
Bug #16603: php_mssql.dll won't load
From: [EMAIL PROTECTED] Operating system: Windows 2000 PHP version: 4.2.0 PHP Bug Type: MSSQL related Bug description: php_mssql.dll won't load I tried just to load all the extensions in 4.2.0RC4. I get a popup notice that says php_mssql.dll can't be found even though it's in the same directory with all the other extensions that load fine. -- Edit bug report at http://bugs.php.net/?id=16603edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16603r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16603r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16603r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16603r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16603r=support Expected behavior: http://bugs.php.net/fix.php?id=16603r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16603r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16603r=submittedtwice
Bug #16601 Updated: php_bz2.dll won't load
ID: 16601 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Dynamic loading Operating System: Windows 2000 PHP Version: 4.2.0 New Comment: It is from the same package and I did replace the old 4.1.1 php4ts.dll with the one in the 4.2.0RC4 package. ctype, db, dbase, dbx, filepro, hyperwave, mbstring, shmop, sockets, tokenizer, and w32api are the ones that load without error. Previous Comments: [2002-04-14 18:37:25] [EMAIL PROTECTED] And have you replaced php4ts.dll with the one found in the RC4 package? And do some other extensions load? which ones? have you copied the bundled dlls from the package? http://www.php.net/manual/en/install.windows.php#install.windows.extensions (And please don't open multiple bug reports about same issues) [2002-04-14 18:34:46] [EMAIL PROTECTED] Is that file from the same package or is it some old dll? [2002-04-14 17:14:33] [EMAIL PROTECTED] I tried just to load all the extensions in 4.2.0RC4. I get a popup notice that says php_bz2.dll can't be found even though it's in the same directory with all the other extensions that load fine. -- Edit this bug report at http://bugs.php.net/?id=16601edit=1
Bug #16601 Updated: php_bz2.dll won't load
ID: 16601 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Dynamic loading Operating System: Windows 2000 PHP Version: 4.2.0 New Comment: I'm not sure if it helps, but I click the OK button for the error message on a phpinfo() page once for php_bz2.dll, once for php_interbase.dll, and once for php_mssql.dll, then I have to go again for another round of clicking OK, but with clicking twice for each extension. Previous Comments: [2002-04-14 19:10:01] [EMAIL PROTECTED] It is from the same package and I did replace the old 4.1.1 php4ts.dll with the one in the 4.2.0RC4 package. ctype, db, dbase, dbx, filepro, hyperwave, mbstring, shmop, sockets, tokenizer, and w32api are the ones that load without error. [2002-04-14 18:37:25] [EMAIL PROTECTED] And have you replaced php4ts.dll with the one found in the RC4 package? And do some other extensions load? which ones? have you copied the bundled dlls from the package? http://www.php.net/manual/en/install.windows.php#install.windows.extensions (And please don't open multiple bug reports about same issues) [2002-04-14 18:34:46] [EMAIL PROTECTED] Is that file from the same package or is it some old dll? [2002-04-14 17:14:33] [EMAIL PROTECTED] I tried just to load all the extensions in 4.2.0RC4. I get a popup notice that says php_bz2.dll can't be found even though it's in the same directory with all the other extensions that load fine. -- Edit this bug report at http://bugs.php.net/?id=16601edit=1
Bug #16601 Updated: php_bz2.dll won't load
ID: 16601 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Dynamic loading Operating System: Windows 2000 PHP Version: 4.2.0RC4 New Comment: It's a CGI to Apache 1.3.22. I have php4ts.dll in two places according to a windows file search, C:\winnt and c:\winnt\system32. I tried also keeping it with php.exe and tried without. Same result. Previous Comments: [2002-04-14 19:25:33] [EMAIL PROTECTED] Are you running PHP as CGI or some webserver module? And if the latter, which webserver and version? Are you sure you have really replaced the correct php4ts.dll? And that you don't have some older one laying around somewhere? Tried booting yet? :) [2002-04-14 19:18:46] [EMAIL PROTECTED] I'm not sure if it helps, but I click the OK button for the error message on a phpinfo() page once for php_bz2.dll, once for php_interbase.dll, and once for php_mssql.dll, then I have to go again for another round of clicking OK, but with clicking twice for each extension. [2002-04-14 19:10:01] [EMAIL PROTECTED] It is from the same package and I did replace the old 4.1.1 php4ts.dll with the one in the 4.2.0RC4 package. ctype, db, dbase, dbx, filepro, hyperwave, mbstring, shmop, sockets, tokenizer, and w32api are the ones that load without error. [2002-04-14 18:37:25] [EMAIL PROTECTED] And have you replaced php4ts.dll with the one found in the RC4 package? And do some other extensions load? which ones? have you copied the bundled dlls from the package? http://www.php.net/manual/en/install.windows.php#install.windows.extensions (And please don't open multiple bug reports about same issues) [2002-04-14 18:34:46] [EMAIL PROTECTED] Is that file from the same package or is it some old dll? 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/16601 -- Edit this bug report at http://bugs.php.net/?id=16601edit=1
Bug #16601 Updated: php_bz2.dll won't load
ID: 16601 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Dynamic loading Operating System: Windows 2000 PHP Version: 4.2.0RC4 New Comment: I went on a limb and rebooted. No change. Errors remain. Previous Comments: [2002-04-14 19:38:08] [EMAIL PROTECTED] It's a CGI to Apache 1.3.22. I have php4ts.dll in two places according to a windows file search, C:\winnt and c:\winnt\system32. I tried also keeping it with php.exe and tried without. Same result. [2002-04-14 19:25:33] [EMAIL PROTECTED] Are you running PHP as CGI or some webserver module? And if the latter, which webserver and version? Are you sure you have really replaced the correct php4ts.dll? And that you don't have some older one laying around somewhere? Tried booting yet? :) [2002-04-14 19:18:46] [EMAIL PROTECTED] I'm not sure if it helps, but I click the OK button for the error message on a phpinfo() page once for php_bz2.dll, once for php_interbase.dll, and once for php_mssql.dll, then I have to go again for another round of clicking OK, but with clicking twice for each extension. [2002-04-14 19:10:01] [EMAIL PROTECTED] It is from the same package and I did replace the old 4.1.1 php4ts.dll with the one in the 4.2.0RC4 package. ctype, db, dbase, dbx, filepro, hyperwave, mbstring, shmop, sockets, tokenizer, and w32api are the ones that load without error. [2002-04-14 18:37:25] [EMAIL PROTECTED] And have you replaced php4ts.dll with the one found in the RC4 package? And do some other extensions load? which ones? have you copied the bundled dlls from the package? http://www.php.net/manual/en/install.windows.php#install.windows.extensions (And please don't open multiple bug reports about same issues) 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/16601 -- Edit this bug report at http://bugs.php.net/?id=16601edit=1
Bug #16601 Updated: php_bz2.dll won't load
ID: 16601 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Dynamic loading Operating System: Windows 2000 PHP Version: 4.2.0RC4 New Comment: The 'expose_php' header also appears in the regular page output for phpinfo() when there's an error popup. X-Powered-By: PHP/4.2.0RC4 Content-type: text/html Previous Comments: [2002-04-14 19:45:33] [EMAIL PROTECTED] I went on a limb and rebooted. No change. Errors remain. [2002-04-14 19:38:08] [EMAIL PROTECTED] It's a CGI to Apache 1.3.22. I have php4ts.dll in two places according to a windows file search, C:\winnt and c:\winnt\system32. I tried also keeping it with php.exe and tried without. Same result. [2002-04-14 19:25:33] [EMAIL PROTECTED] Are you running PHP as CGI or some webserver module? And if the latter, which webserver and version? Are you sure you have really replaced the correct php4ts.dll? And that you don't have some older one laying around somewhere? Tried booting yet? :) [2002-04-14 19:18:46] [EMAIL PROTECTED] I'm not sure if it helps, but I click the OK button for the error message on a phpinfo() page once for php_bz2.dll, once for php_interbase.dll, and once for php_mssql.dll, then I have to go again for another round of clicking OK, but with clicking twice for each extension. [2002-04-14 19:10:01] [EMAIL PROTECTED] It is from the same package and I did replace the old 4.1.1 php4ts.dll with the one in the 4.2.0RC4 package. ctype, db, dbase, dbx, filepro, hyperwave, mbstring, shmop, sockets, tokenizer, and w32api are the ones that load without error. 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/16601 -- Edit this bug report at http://bugs.php.net/?id=16601edit=1
Bug #16601 Updated: php_bz2.dll won't load
ID: 16601 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Dynamic loading Operating System: Windows 2000 PHP Version: 4.2.0RC4 New Comment: I rolled up all my stuff for previous versions of php into one big zip file so I could have only 1 php4ts.dll on my system, located in c:\winnt\system32. Then I did a file search for php4ts.dll to double check. The filesize of the php4ts.dll in my directory is 1,028,096 bytes with a md5 hash of 52d05cf883b6e0410add9e15b2352f7b. Then I did a search for php* in c:\winnt and it found php4ts.dll and php.ini. I still get errors for bz2, interbase, and mssql. Previous Comments: [2002-04-14 19:53:10] [EMAIL PROTECTED] it seems you have conflicting php4ts.dll's. I suggest you remove all of the files you had during install, and start again. This is probably the easiest method of trying it out. as far as i can see, that module loads fine for me. [2002-04-14 19:48:38] [EMAIL PROTECTED] The 'expose_php' header also appears in the regular page output for phpinfo() when there's an error popup. X-Powered-By: PHP/4.2.0RC4 Content-type: text/html [2002-04-14 19:45:33] [EMAIL PROTECTED] I went on a limb and rebooted. No change. Errors remain. [2002-04-14 19:38:08] [EMAIL PROTECTED] It's a CGI to Apache 1.3.22. I have php4ts.dll in two places according to a windows file search, C:\winnt and c:\winnt\system32. I tried also keeping it with php.exe and tried without. Same result. [2002-04-14 19:25:33] [EMAIL PROTECTED] Are you running PHP as CGI or some webserver module? And if the latter, which webserver and version? Are you sure you have really replaced the correct php4ts.dll? And that you don't have some older one laying around somewhere? Tried booting yet? :) 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/16601 -- Edit this bug report at http://bugs.php.net/?id=16601edit=1
Bug #15667 Updated: problems with include()
ID: 15667 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Unknown/Other Function Operating System: FreeBSD 4.4-RELEASE PHP Version: 4.1.1 New Comment: We worked out a solution in #php on OPN. Had to turn off expose_php. Rasmus said the problem was completely gone in 4.3.0. *shrug* Previous Comments: [2002-03-21 16:52:58] [EMAIL PROTECTED] I figured this one out. Turns out his Server: string was massive overflowing our HTTP_HEADER_BLOCK_SIZE giving a weird effect. The problem seems to be gone in the 4.3 streams code. But a fix has been committed to 4.2. [2002-03-19 02:07:10] [EMAIL PROTECTED] It seems that this problem has something to do with the mode change of php engine when it meets include() function; I heard that when php engine meet include(), it turns into html mode. If it's true, there seems a high probablity that php engine recognize the mode change as having begun some output to the browser with html mode - not so consistently. Pls check this possibility. I hope my comment could help solving the problem. [2002-02-22 00:58:54] [EMAIL PROTECTED] Whenever I include (or require) a page, using an http url as the file value (i.e. include(http://www.its-explosive.net/~davey/info.php;);) I get this header added to the top of the page I've included. This does not happen when I use a relative path. http://www.its-explosive.net/~davey/header.php show what happen when I include the file info.php using a http url to it. --- ?php include(http://www.its-explosive.net/~davey/header.php;); ? --- The contents of info.php are ?php phpinfo(); ?. http://www.its-explosive.net/~davey/noheader.php shows what happens when I include it using the relative path: --- ?php include(info.php); ? --- The only difference (in case you didn't go, or you missed it) is the text: --- X-Powered-By: PHP/4.1.1 Connection: close Content-Type: text/html --- is just added onto the top. If you goto the urls you will see my phpinfo(); and can perhaps glean some othre info from there. I do know that if someone else includes my PHP files in their website using the include(http://...;); code they also see the x-powered-by header... I've been looking around for a solution to this for weeks, I bet it's something simple, but I just can't find it. I hope you can help - Davey -- Edit this bug report at http://bugs.php.net/?id=15667edit=1
Bug #15583 Updated: thttpd patching fails
ID: 15583
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Other web server
Operating System: Slackware 8
PHP Version: 4.1.1
New Comment:
I did it again with a php4-latest from snaps.php.net against
thttpd-2.22beta4.
It asked me if I wanted to patch fdimage.c cause it thinks it's already
patched. I said no this time.
This is the output of the patching:
patching Makefile.in
Hunk #3 succeeded at 155 (offset 2 lines).
patching config.h
patching fdwatch.c
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
Skipping patch.
2 of 2 hunks ignored -- saving rejects to file fdwatch.c.rej
patching file libhttpd.c
Hunk #2 succeeded at 249 with fuzz 1 (offset 5 lines).
Hunk #3 succeeded at 255 (offset 2 lines).
Hunk #4 succeeded at 322 (offset 5 lines).
Hunk #5 succeeded at 396 with fuzz 2 (offset 5 lines).
Hunk #6 succeeded at 2401 (offset 40 lines).
Hunk #7 FAILED at 3077.
Hunk #8 succeeded at 3604 (offset 35 lines).
1 out of 8 hunks FAILED -- saving rejects to file libhttpd.c.rej
patching libhttpd.h
Hunk #1 succeeded at 1373 with fuzz 1 (offset 40 lines).
Hunk #3 succeeded at 1546 (offset 40 lines).
patching file mime_encodings.txt
patching file libhttpd.c
Hunk #1 succeeded at 3702 (offset 91 lines).
make[1]: ***[install-sapi] Error 1
make[1]: Leaving directory `/root/sources/php4-200202161800'
make: *** [install-recursive] Error 1
***
start contents of fdwatch.c.rej
***
*** 454,460
ridx = 0;
for ( i = 0; i npollfds; ++i )
- if ( pollfds[i].revents ( POLLIN | POLLOUT ) )
poll_rfdidx[ridx++] = pollfds[i].fd;
return r;
--- 454,460
ridx = 0;
for ( i = 0; i npollfds; ++i )
+ if ( pollfds[i].revents ( POLLIN | POLLOUT | POLLERR | POLLHUP |
POLLNVAL ) )
poll_rfdidx[ridx++] = pollfds[i].fd;
return r;
***
*** 466,473
{
switch ( fd_rw[fd] )
{
- case FDW_READ: return pollfds[poll_fdidx[fd]].revents POLLIN;
- case FDW_WRITE: return pollfds[poll_fdidx[fd]].revents POLLOUT;
default: return 0;
}
}
--- 466,473
{
switch ( fd_rw[fd] )
{
+ case FDW_READ: return pollfds[poll_fdidx[fd]].revents ( POLLIN |
POLLERR | POLLHUP | POLLNVAL );
+ case FDW_WRITE: return pollfds[poll_fdidx[fd]].revents (
POLLOUT | POLLERR | POLLHUP | POLLNVAL );
default: return 0;
}
}
**
end contents fdwatch.c.rej
**
start contents libhttpd.c.rej
***
*** 3066,3076
post_post_garbage_hack( httpd_conn* hc )
{
char buf[2];
- int r;
- r = recv( hc-conn_fd, buf, sizeof(buf), MSG_PEEK );
- if ( r 0 )
- (void) read( hc-conn_fd, buf, r );
}
--- 3077,3085
post_post_garbage_hack( httpd_conn* hc )
{
char buf[2];
+ fcntl(hc-conn_fd, F_SETFL, O_NONBLOCK);
+ (void) read( hc-conn_fd, buf, 2 );
}
Previous Comments:
[2002-02-15 20:13:52] [EMAIL PROTECTED]
Patching of the thttpd source fails when I try to compile php as a sapi
thttpd module. Tried with thttpd versions 2.19, 2.20c, and 2.22beta4.
Report contents apply to thttpd-2.20c (the latest stable version), but
I think the error is the same for all.
Details:
unpackaged php-4.1.1 and thttpd into the same directory and cd to
php-4.1.1.
./configure --with-thttpd=../thttpd-2.20c
configure works fine.
then do make install per the readme by Sascha
gcc gets a workout and then Hunks 1 2 fail on fdwatch.c on lines 460
and 472 and Hunks 6 7 fail on libhttpd.c at lines 2349 and 3025
contents of fdwatch.c.rej
***
*** 460,466
ridx = 0;
for ( i = 0; i npollfds; ++i )
- if ( pollfds[i].revents ( POLLIN | POLLOUT ) )
poll_rfdidx[ridx++] = pollfds[i].fd;
return r;
--- 460,466
ridx = 0;
for ( i = 0; i npollfds; ++i )
+ if ( pollfds[i].revents ( POLLIN | POLLOUT | POLLERR | POLLHUP |
POLLNVAL ) )
poll_rfdidx[ridx++] = pollfds[i].fd;
return r;
***
*** 472,479
{
switch ( fd_rw[fd] )
{
- case FDW_READ: return pollfds[poll_fdidx[fd]].revents POLLIN;
- case FDW_WRITE: return pollfds[poll_fdidx[fd]].revents POLLOUT;
default: return 0;
}
}
--- 472,479
{
switch ( fd_rw[fd] )
{
+ case FDW_READ: return pollfds[poll_fdidx[fd]].revents ( POLLIN |
POLLERR | POLLHUP | POLLNVAL );
+ case FDW_WRITE: return
Bug #15583: thttpd patching fails
From: [EMAIL PROTECTED]
Operating system: Slackware 8
PHP version: 4.1.1
PHP Bug Type: Other web server
Bug description: thttpd patching fails
Patching of the thttpd source fails when I try to compile php as a sapi
thttpd module. Tried with thttpd versions 2.19, 2.20c, and 2.22beta4.
Report contents apply to thttpd-2.20c (the latest stable version), but I
think the error is the same for all.
Details:
unpackaged php-4.1.1 and thttpd into the same directory and cd to
php-4.1.1.
./configure --with-thttpd=../thttpd-2.20c
configure works fine.
then do make install per the readme by Sascha
gcc gets a workout and then Hunks 1 2 fail on fdwatch.c on lines 460 and
472 and Hunks 6 7 fail on libhttpd.c at lines 2349 and 3025
contents of fdwatch.c.rej
***
*** 460,466
ridx = 0;
for ( i = 0; i npollfds; ++i )
- if ( pollfds[i].revents ( POLLIN | POLLOUT ) )
poll_rfdidx[ridx++] = pollfds[i].fd;
return r;
--- 460,466
ridx = 0;
for ( i = 0; i npollfds; ++i )
+ if ( pollfds[i].revents ( POLLIN | POLLOUT | POLLERR | POLLHUP |
POLLNVAL ) )
poll_rfdidx[ridx++] = pollfds[i].fd;
return r;
***
*** 472,479
{
switch ( fd_rw[fd] )
{
- case FDW_READ: return pollfds[poll_fdidx[fd]].revents POLLIN;
- case FDW_WRITE: return pollfds[poll_fdidx[fd]].revents POLLOUT;
default: return 0;
}
}
--- 472,479
{
switch ( fd_rw[fd] )
{
+ case FDW_READ: return pollfds[poll_fdidx[fd]].revents ( POLLIN |
POLLERR | POLLHUP | POLLNVAL );
+ case FDW_WRITE: return pollfds[poll_fdidx[fd]].revents ( POLLOUT |
POLLERR | POLLHUP | POLLNVAL );
default: return 0;
}
}
**
end contents of fdwatch.c.rej
**
contents of libhttpd.c.rej
***
*** 2341,2347
{
make_log_entry( hc, nowP );
- if ( hc-file_address != (char*) 0 )
{
mmc_unmap( hc-file_address, (hc-sb), nowP );
hc-file_address = (char*) 0;
--- 2349,2358
{
make_log_entry( hc, nowP );
+ if ( hc-file_address == (char*) 1 )
+ {
+ thttpd_closed_conn(hc-conn_fd);
+ } else if ( hc-file_address != (char*) 0 )
{
mmc_unmap( hc-file_address, (hc-sb), nowP );
hc-file_address = (char*) 0;
***
*** 3014,3024
post_post_garbage_hack( httpd_conn* hc )
{
char buf[2];
- int r;
- r = recv( hc-conn_fd, buf, sizeof(buf), MSG_PEEK );
- if ( r 0 )
- (void) read( hc-conn_fd, buf, r );
}
--- 3025,3033
post_post_garbage_hack( httpd_conn* hc )
{
char buf[2];
+ fcntl(hc-conn_fd, F_SETFL, O_NONBLOCK);
+ (void) read( hc-conn_fd, buf, 2 );
}
--
Edit bug report at http://bugs.php.net/?id=15583edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=15583r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=15583r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=15583r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=15583r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=15583r=support
Expected behavior: http://bugs.php.net/fix.php?id=15583r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=15583r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=15583r=submittedtwice
