#38791 [NEW]: oci_new_collection is working incorrectly
From: ces dot fci at gmail dot com
Operating system: any
PHP version: 5.1.6
PHP Bug Type: OCI8 related
Bug description: oci_new_collection is working incorrectly
Description:
I am trying to use oci_new_collection but I have not yet had any success.
I have only been able to test it up to PHP 5.1.4. I found a post on Google
Groups that suggests "it works only for VARRAY types"(Mladen Gogala).
Reproduce code:
---
$dbh = oci_connect('apps', '..', "(DESCRIPTION = (ADDRESS_LIST = (ADDRESS
= (PROTOCOL = TCP)(Host = ..)(Port = 1522))) (CONNECT_DATA =(SID =
test)))");
oci_new_collection($dbh, 'HZ_PARTY_SEARCH.CONTACT_POINT_LIST', 'APPS');
In PL/SQL the collection is declared as:
TYPE contact_point_list IS TABLE OF contact_point_search_rec_type
INDEX BY BINARY_INTEGER;
TYPE contact_point_search_rec_type IS RECORD (
CONTACT_POINT_TYPE VARCHAR2(30)-- HZ_CONTACT_POINTS
,CPT_SOURCE_SYSTEM_REFVARCHAR2(4000) -- CUSTOM
,TELEPHONE_TYPE VARCHAR2(30)-- HZ_CONTACT_POINTS
,TELEX_NUMBER VARCHAR2(50)-- HZ_CONTACT_POINTS
/* . . . */
,WEB_TYPE VARCHAR2(60)-- HZ_CONTACT_POINTS
,STATUS VARCHAR2(1) -- HZ_CONTACT_POINTS
,CONTACT_POINT_PURPOSEVARCHAR2(30)-- HZ_CONTACT_POINTS
);
Expected result:
I do not expect to experience any errors.
Actual result:
--
Warning: oci_new_collection() [function.oci-new-collection]: OCI-22303:
type "APPS"."HZ_PARTY_SEARCH.CONTACT_POINT_LIST" not found in
C:\wamp\www\test.php on line 18
--
Edit bug report at http://bugs.php.net/?id=38791&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=38791&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=38791&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=38791&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=38791&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=38791&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=38791&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=38791&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=38791&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=38791&r=support
Expected behavior:http://bugs.php.net/fix.php?id=38791&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=38791&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=38791&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=38791&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38791&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=38791&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=38791&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=38791&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=38791&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=38791&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=38791&r=mysqlcfg
#38430 [NEW]: Can't get table name from result
From: ces dot fci at gmail dot com Operating system: any PHP version: 5.2.0RC1 PHP Bug Type: OCI8 related Bug description: Can't get table name from result Description: It is not possible to get the table name from a result set. This breaks desired behavior in frameworks such as CakePHP . Is it all possible to have a function like oci_field_table? MySQL has support for this kind of behavior in mysql_fetch_field. -- Edit bug report at http://bugs.php.net/?id=38430&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38430&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38430&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38430&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38430&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38430&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38430&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38430&r=needscript Try newer version:http://bugs.php.net/fix.php?id=38430&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38430&r=support Expected behavior:http://bugs.php.net/fix.php?id=38430&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38430&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38430&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38430&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38430&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38430&r=dst IIS Stability:http://bugs.php.net/fix.php?id=38430&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38430&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38430&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38430&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38430&r=mysqlcfg
#20033 [Fbk->Opn]: Echoing/fputsing ~11k+ of data to STDOUT causes problem
ID: 20033
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Sockets related
Operating System: Red Hat 7.3
PHP Version: 4CVS-2002-10-22
New Comment:
PHP doesn't eat a lot of cycles when it crashes. As I corrected in a
subsequent revision to the post, the connection is being closed and the
script terminates--it even goes through the registered shutdown
function as it terminates. So no cycles are being eaten.
I've not used gdb. I could, but I'm not sure if it is applicable in
this case. If I run the script from the command-line, it works fine.
If I run it by telneting into the port connected to the script, it
works fine. It only crashes if a raw (non-Telnet-based) connection is
established to the script by, for example, Eudora mail client or by a
test VB script that opens a raw connection without any potential telnet
connection control.
As for output buffer options, I'm using the default php.ini. If you
tell me what parameters specifically you'd like to know, I can look
those up and/or change them.
Again, what surprises me is that it works in command-line, works when I
connect to it as a daemon via Telnet, but it fails in the
above-described manner when I connect to the same daemon but using a
non-Telnet client; i.e., Eudora connects and fails. If I write a
custom VB app to just connect to the daemon to observe the problem,
this fails as well.
Previous Comments:
[2002-10-23 16:07:57] [EMAIL PROTECTED]
Does PHP eat a lot of CPU when it hangs?
Are you capable of running it under gdb and obtaining a backtrace?
make sure you are running an --enable-debug build of PHP.
gdb ./sapi/cli/php
run nameofyourscript.php
[hit CTRL-C when it hangs]
bt full
This would be ideal, because then we would know 100%
what was going on.
In light of your comments about shutdown, what happens if you comment
out the fclose() line?
Also, what are your ini settings for output buffer related options?
(and does changing those affect the problem?)
[2002-10-23 12:13:57] [EMAIL PROTECTED]
I added requested fflush on $logfile after each fputs. It still
indicates that it is dying on the "echo". I.e., logfile shows "Echoing
line" but never reports "Sent."
Additional important correction: I'm not sure whether behavior has
changed or if I was just wrong before, but when the problem presents
itself the script IS shutting down and the TCP/IP connection IS
disconnected. In fact, it does so cleanly. It executes my registered
shutdown function. In that function I had it write to the logfile and
it shows that after the last "Echoing" line it DOES go through the
shutdown function. Connection_status() within the shutdown function
reports "1" (aborted), but the client side definitely didn't request
the abort.
I have also refined the loop so that the possible infinite loop
situation is handled. This is a welcome improvement to my code to
handle an "impossible" situation (impossible because it is constrained
elsewhere by logic) but it didn't have any effect on the current
problem.
[2002-10-23 06:26:33] [EMAIL PROTECTED]
while(ftell($mailfile) < $EndOfMessagePos)
This line has the potential to cause a indefinete loop and there's no
escape code in the loop, which breaks it.
ftell will return FALSE if an error occurs, which in numerical
comparison resolves to 0.
Can you change that to:
while(ftell($mailfile) and ftell($mailfile) < $EndOfMessagePos)
[2002-10-23 03:54:00] [EMAIL PROTECTED]
It's more likely to be a problem with fgets; could you
try fflush($logfile) ing after the fputs lines, just to make sure that
they're not waiting in the buffer.
Also, when php hangs, is it using a lot of CPU?
[2002-10-22 17:42:38] [EMAIL PROTECTED]
Code I am using is:
while(ftell($mailfile) < $EndOfMessagePos)
{
fputs($logfile, "Getting line\n");
$line = fgets($mailfile, 4096);
fputs($logfile, "Echoing line\n");
echo "$line\r\n";
$fst += strlen($line);
fputs($logfile, "Sent $fst: $line\n");
}
echo ".\r\n";
fputs($logfile, "Sent: CRLF\n");
fclose($logfile);
End of log file returns:
--START--
Getting line
Echoing line
Sent 11060: (unimportant email content)
Getting line
Echoing line
Sent 11147: (unimportant email content)
Getting line
Echoing line
--END--
Thus it appears to be hanging on the "echo" line.
Again, this problem only presents itself when the script is running as
a full server on a "clean" connection. If the same exact test is run
connecting via the telnet command to po
#20290 [NEW]: UPDATE works, rows updated, but mysql_affected_rows=0
From: [EMAIL PROTECTED]
Operating system: RedHat 7.3
PHP version: 4.2.3
PHP Bug Type: MySQL related
Bug description: UPDATE works, rows updated, but mysql_affected_rows=0
I have a simple section of code that attempts to UPDATE a row in a MySQL
table. If mysql_affected_rows() = 0 I assume the row didn't exist so I go
ahead and INSERT it. This works about 95% of the time.
The other 5% of the time, the row does exist and IS updated, but
mysql_affected_rows() returns 0--so I go ahead and INSERT it. I then end
up with a duplicate entry. I could define the appropriate columns as
"unique" so that the INSERT would fail, but I feel that something else is
wrong here and doing this would be a work-around for what might be a real
problem.
My table is entirely numeric, no strings. It's not a case of updating a
row to its same values and so it's not counted as an affected row. The
value DOES change.
My code is:
$SQL = "UPDATE UserStats SET MS=MS+$Var,MC=MC+1
WHERE idUser=$idUser AND Month=$Month";
$updateStats = mysql_db_query ($sDB, $SQL, $nConnection);
if(mysql_affected_rows($nConnection) == 0)
{
$SQL = "INSERT INTO UserStats SET idUser=$idUser,
Month=$Month, MS=$Var,MC=1";
$updateStats = mysql_db_query ($sDB, $SQL, $nConnection);
}
MS, MC, and idUser are all BigInts. Month is MediumInt. The $Var variable
is always non-zero. I've dumped the SQL queries to a logfile--they are
always valid queries, so it's not an issue of one of my variables not
being defined and producing an improper SQL. I've also tried the
mysql_affected_rows without the $nConnection paramter.
In summary, the above UPDATE *ALWAYS* works in that the actual row in
question is always updated correctly in the MySQL database. However,
sometimes the mysql_affected_rows() returns 0 instead of 1; so my code
continues to INSERT a new row and I end up with a duplicate.
MySQL version is 3.23.49. Same UPDATE instruction works fine when
executed manually multiple times in MySQL command-line, etc. Always
returns the correct number of rows having been updated.
I am not sure if this is a PHP problem or a MySQL problem, but I lean
towards PHP since MySQL *IS* updating the row as requested and I can't
duplicate the problem outside of PHP. I'm also open to it being a code
problem on my end, but at this point I don't see how.
--
Edit bug report at http://bugs.php.net/?id=20290&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20290&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20290&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20290&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20290&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20290&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20290&r=support
Expected behavior: http://bugs.php.net/fix.php?id=20290&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20290&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20290&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20290&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20290&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20290&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20290&r=isapi
#20033 [Fbk->Opn]: Echoing/fputsing ~11k+ of data to STDOUT causes problem
ID: 20033
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: Sockets related
Operating System: Red Hat 7.3
PHP Version: 4CVS-2002-10-22
New Comment:
I added requested fflush on $logfile after each fputs. It still
indicates that it is dying on the "echo". I.e., logfile shows "Echoing
line" but never reports "Sent."
Additional important correction: I'm not sure whether behavior has
changed or if I was just wrong before, but when the problem presents
itself the script IS shutting down and the TCP/IP connection IS
disconnected. In fact, it does so cleanly. It executes my registered
shutdown function. In that function I had it write to the logfile and
it shows that after the last "Echoing" line it DOES go through the
shutdown function. Connection_status() within the shutdown function
reports "1" (aborted), but the client side definitely didn't request
the abort.
I have also refined the loop so that the possible infinite loop
situation is handled. This is a welcome improvement to my code to
handle an "impossible" situation (impossible because it is constrained
elsewhere by logic) but it didn't have any effect on the current
problem.
Previous Comments:
[2002-10-23 06:26:33] [EMAIL PROTECTED]
while(ftell($mailfile) < $EndOfMessagePos)
This line has the potential to cause a indefinete loop and there's no
escape code in the loop, which breaks it.
ftell will return FALSE if an error occurs, which in numerical
comparison resolves to 0.
Can you change that to:
while(ftell($mailfile) and ftell($mailfile) < $EndOfMessagePos)
[2002-10-23 03:54:00] [EMAIL PROTECTED]
It's more likely to be a problem with fgets; could you
try fflush($logfile) ing after the fputs lines, just to make sure that
they're not waiting in the buffer.
Also, when php hangs, is it using a lot of CPU?
[2002-10-22 17:42:38] [EMAIL PROTECTED]
Code I am using is:
while(ftell($mailfile) < $EndOfMessagePos)
{
fputs($logfile, "Getting line\n");
$line = fgets($mailfile, 4096);
fputs($logfile, "Echoing line\n");
echo "$line\r\n";
$fst += strlen($line);
fputs($logfile, "Sent $fst: $line\n");
}
echo ".\r\n";
fputs($logfile, "Sent: CRLF\n");
fclose($logfile);
End of log file returns:
--START--
Getting line
Echoing line
Sent 11060: (unimportant email content)
Getting line
Echoing line
Sent 11147: (unimportant email content)
Getting line
Echoing line
--END--
Thus it appears to be hanging on the "echo" line.
Again, this problem only presents itself when the script is running as
a full server on a "clean" connection. If the same exact test is run
connecting via the telnet command to port 110 or by running the script
from the command-line there is no problem. It is my guess that the
telnet command introduces some kind of flow control that is not present
when I open a "real" POP3 connection to the same port.
[2002-10-22 16:57:05] [EMAIL PROTECTED]
Can you isolate the line of code that causes the hang?
Use printf to output a note before each function you suspect of causing
the problem; the last line output
by the script will tell you which one has hung.
We need to narrow it down to either sockets (as in ext/socket), or
streams (fgets, fread, fwrite etc.),
or output buffer -- three unrelated areas.
[2002-10-22 16:34:52] [EMAIL PROTECTED]
Additional info: If I switch my binary back to php 4.1.3, my POP3
server script works 100% inasmuch as this bug is concerned.
Additionally, I can confirm that something is crashing in PHP in that
if I dump data to a log file, the logfile ends where the data turns to
garbage. An additional log entry should be made when the message dump
is complete. This is never executed.
This is a weird problem that seems to cause PHP to hang, not core dump,
and not terminate the TCP/IP connection but causes PHP to just dump
garbage and just hang.
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/20033
--
Edit this bug report at http://bugs.php.net/?id=20033&edit=1
#19944 [Fbk->Opn]: fgets() returns garbage when STDIN set to non-blocking
ID: 19944 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Sockets related Operating System: RedHat 7.3 PHP Version: 4.3.0-pre1 New Comment: Rats, just changing status to "Open"--already added comment above... Previous Comments: [2002-10-18 20:11:03] [EMAIL PROTECTED] As of snap-200210181500 it still doesn't work. Results are the same with garbage returned when using fgets() on STDIN when in non-blocking mode. Last two snaps I've tried (10/17 and 200210181500) have the added feature of also core dumping when fgets() is used on a non-blocking socket opened with fsockopen(). Previous versions of PHP work as expected with fgets() on a non-blocking socket, but the snaps seem to core dump. 10/17 snap would core dump on first call to fgets() whereas today's snap seems to go through the while loop three times and then core dumps when it hits fgets() again. Thus, the current observation is that when using fgets in non-blocking mode: 1. STDIN returns garbage. 2. Sockets core dump. [2002-10-17 21:59:58] [EMAIL PROTECTED] As an aside: you can use stream_select() to acheive this (see docs for socket_select; they work the same way, but on different things). Also, you should use if ($string !== false) to 100% correct in your script. [2002-10-17 17:07:37] [EMAIL PROTECTED] Try this one again: http://snaps.php.net/php4-latest.tar.bz2 You might have got the snapshot which didn't have the fixes. [2002-10-17 12:52:36] [EMAIL PROTECTED] I just tried with the latest from snaps.php.net. Problem still exists as of php4-200210170600. [2002-10-17 02:15:13] [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. Use a snapshot from http://snaps.php.net/php4-latest.tar.bz2 fgets had some real nasty problems. 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/19944 -- Edit this bug report at http://bugs.php.net/?id=19944&edit=1
#19944 [Com]: fgets() returns garbage when STDIN set to non-blocking
ID: 19944
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Sockets related
Operating System: RedHat 7.3
PHP Version: 4.3.0-pre1
New Comment:
As of snap-200210181500 it still doesn't work. Results are the same
with garbage returned when using fgets() on STDIN when in non-blocking
mode.
Last two snaps I've tried (10/17 and 200210181500) have the added
feature of also core dumping when fgets() is used on a non-blocking
socket opened with fsockopen(). Previous versions of PHP work as
expected with fgets() on a non-blocking socket, but the snaps seem to
core dump. 10/17 snap would core dump on first call to fgets() whereas
today's snap seems to go through the while loop three times and then
core dumps when it hits fgets() again.
Thus, the current observation is that when using fgets in non-blocking
mode:
1. STDIN returns garbage.
2. Sockets core dump.
Previous Comments:
[2002-10-17 21:59:58] [EMAIL PROTECTED]
As an aside:
you can use stream_select() to acheive this (see docs for
socket_select; they work the same way, but on different things).
Also, you should use if ($string !== false) to 100% correct in your
script.
[2002-10-17 17:07:37] [EMAIL PROTECTED]
Try this one again: http://snaps.php.net/php4-latest.tar.bz2
You might have got the snapshot which didn't have the fixes.
[2002-10-17 12:52:36] [EMAIL PROTECTED]
I just tried with the latest from snaps.php.net. Problem still exists
as of php4-200210170600.
[2002-10-17 02:15:13] [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.
Use a snapshot from
http://snaps.php.net/php4-latest.tar.bz2
fgets had some real nasty problems.
[2002-10-16 23:32:19] [EMAIL PROTECTED]
I am trying to use the CLI version of 4.3.0-pre1. My script needs to
act if there hasn't been input within a certain amount of time. I've
used the following function to accomplish this with TCP/IPsockets in
non-blocking mode:
function GetSocketLine($socket, $timeout)
{
$timeout += time();
$holdString = "";
while(time() < $timeout)
{
$string = fgets($socket, 1024);
if($string != false)
break;
}
return($string);
}
However, if I use set_stream_blocking() to set STDIN to non-blocking,
the above code returns garbage instead of "false" when there is nothing
to receive. It would seem to me that if STDIN is set to non-blocking
and STDIN is passed to the above function as $socket, it ought to
return "false" when blocking would occur--it shouldn't return garbage.
--
Edit this bug report at http://bugs.php.net/?id=19944&edit=1
#19944 [Csd->Opn]: fgets() returns garbage when STDIN set to non-blocking
ID: 19944
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Closed
+Status: Open
Bug Type: Sockets related
Operating System: RedHat 7.3
PHP Version: 4.3.0-pre1
New Comment:
I just tried with the latest from snaps.php.net. Problem still exists
as of php4-200210170600.
Previous Comments:
[2002-10-17 02:15:13] [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.
Use a snapshot from
http://snaps.php.net/php4-latest.tar.bz2
fgets had some real nasty problems.
[2002-10-16 23:32:19] [EMAIL PROTECTED]
I am trying to use the CLI version of 4.3.0-pre1. My script needs to
act if there hasn't been input within a certain amount of time. I've
used the following function to accomplish this with TCP/IPsockets in
non-blocking mode:
function GetSocketLine($socket, $timeout)
{
$timeout += time();
$holdString = "";
while(time() < $timeout)
{
$string = fgets($socket, 1024);
if($string != false)
break;
}
return($string);
}
However, if I use set_stream_blocking() to set STDIN to non-blocking,
the above code returns garbage instead of "false" when there is nothing
to receive. It would seem to me that if STDIN is set to non-blocking
and STDIN is passed to the above function as $socket, it ought to
return "false" when blocking would occur--it shouldn't return garbage.
--
Edit this bug report at http://bugs.php.net/?id=19944&edit=1
#19944 [NEW]: fgets() returns garbage when STDIN set to non-blocking
From: [EMAIL PROTECTED]
Operating system: RedHat 7.3
PHP version: 4.3.0-pre1
PHP Bug Type: Sockets related
Bug description: fgets() returns garbage when STDIN set to non-blocking
I am trying to use the CLI version of 4.3.0-pre1. My script needs to act
if there hasn't been input within a certain amount of time. I've used the
following function to accomplish this with TCP/IPsockets in non-blocking
mode:
function GetSocketLine($socket, $timeout)
{
$timeout += time();
$holdString = "";
while(time() < $timeout)
{
$string = fgets($socket, 1024);
if($string != false)
break;
}
return($string);
}
However, if I use set_stream_blocking() to set STDIN to non-blocking, the
above code returns garbage instead of "false" when there is nothing to
receive. It would seem to me that if STDIN is set to non-blocking and
STDIN is passed to the above function as $socket, it ought to return
"false" when blocking would occur--it shouldn't return garbage.
--
Edit bug report at http://bugs.php.net/?id=19944&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=19944&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=19944&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=19944&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=19944&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=19944&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=19944&r=support
Expected behavior: http://bugs.php.net/fix.php?id=19944&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=19944&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=19944&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=19944&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=19944&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=19944&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=19944&r=isapi
