#25800 [NEW]: unable to parse url http://1.2.3.4:/abc.def...

[xuefer at 21cn dot com]

From: xuefer at 21cn dot com
Operating system: linux
PHP version:  4.3.3
PHP Bug Type: URL related
Bug description:  unable to parse url http://1.2.3.4:/abc.def...

Description:

parse_url(http://1.2.3.4:/abc.asp?a=1&b=2): Unable to parse url
the empty port make parse_url failed
but browsers treat this url ok


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

#17908 [Com]: Can't retrieve info using OCIColumnIsNULL()

[tumman at sec dot or dot th]

 ID:   17908
 Comment by:   tumman at sec dot or dot th
 Reported By:  ThorpeJ at gao dot gov
 Status:   Assigned
 Bug Type: OCI8 related
 Operating System: Linux 7.1
 PHP Version:  4.0CVS-2002-06-21
 Assigned To:  maxim
 New Comment:

Your fix It still not work.


Previous Comments:


[2002-10-20 15:33:55] [EMAIL PROTECTED]

true,

actually, what i noticed is that if you do a fetch *before* calling
OCIColumnIsNULL() you then get the right results.

/**/
$conn = OCILogon($user, $pwd, $db);
$stmt = OCIParse($conn, "select * from $table");
OCIExecute($stmt);
$nrows = OCIFetchStatement($stmt, $res);  // adding this
$ncols = OCINumCols($stmt);
for ( $i = 1; $i <= $ncols; $i++ ) {
  echo "NAME: " . OCIColumnName($stmt,$i) . "";
  echo "TYPE: " . OCIColumnType($stmt,$i) . "";
  echo "SIZE: " . OCIColumnSize($stmt,$i) . "";
  echo "ISNULL: " . OCIColumnIsNULL($stmt,$i) . ""; //Function does
not return any information
}
/**/

Will go to fix that.



[2002-06-21 14:20:29] ThorpeJ at gao dot gov

I've tried using OCIColumnIsNULL() to retrieve info on which fields
were NULL/NOT NULL in an Oracle database table, and the function did
not return anything (using OCIColumnName, OCIColumnType, and
OCIColumnSize in the same program worked fine). The script below is a
simple example:

/**/
$conn = OCILogon($user, $pwd, $db);
$stmt = OCIParse($conn, "select * from $table");
OCIExecute($stmt);
$ncols = OCINumCols($stmt);
for ( $i = 1; $i <= $ncols; $i++ ) {
  echo "NAME: " . OCIColumnName($stmt,$i) . "";
  echo "TYPE: " . OCIColumnType($stmt,$i) . "";
  echo "SIZE: " . OCIColumnSize($stmt,$i) . "";
  echo "ISNULL: " . OCIColumnIsNULL($stmt,$i) . ""; //Function does
not return any information
}
/**/




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

#25793 [Opn]: special POST or GET query crashes PHP under Windows

[valyala at tut dot by]

 ID:   25793
 User updated by:  valyala at tut dot by
 Reported By:  valyala at tut dot by
 Status:   Open
 Bug Type: Reproducible crash
-Operating System: Win2k sp3
+Operating System: Win2k sp3, WinXP, Win2003
-PHP Version:  4.3.3
+PHP Version:  4.3.3 and older
 New Comment:

2 Stephen at ediassociates dot com:
Is your webserver running under windows NT ?
If yes, try this link to reproduce the bug:
http://localhost/login/link.php?32432[]

I think, this bug is useful for dos-attacks ;)


Previous Comments:


[2003-10-08 14:32:00] Stephen at ediassociates dot com

Close, mine doesn't crash the server; however, it doesn't return any
values.

My link is "http://localhost/login/link.php?SesId=67394710";

but when I place the following code in link.php I get "The sessionId
is" and nothing else.




[2003-10-08 09:34:18] valyala at tut dot by

Description:

this query strings crashes PHP under Windows:
1[]
437378[index]
232[index]=value&something_else

the query string must begins with any decimal number, following braces
with optional index string.

Sorry for my English :)

Reproduce code:
---
GET /any_php_script.php?1[] HTTP/1.1


Expected result:

If my script looks like this:


I expected:
Array
(
[1] => Array
(
[0] => 
)

)


Actual result:
--
No response headers received because request failed :
ERROR_INTERNET_CONNECTION_RESET

And windows shows error message: "Apache.exe has generated errors and
will be closed by Windows. You will need to restart the program"





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

#23220 [Asn->Fbk]: fgets() causes warning while reading data via SSL channel (HTTPS)

[sniper]

 ID:   23220
 Updated by:   [EMAIL PROTECTED]
 Reported By:  storozhilov at mail dot ru
-Status:   Assigned
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: FreeBSD 4.8
 PHP Version:  4-STABLE-200307070330
 Assigned To:  wez


Previous Comments:


[2003-10-08 07:30:39] [EMAIL PROTECTED]

Could you try the next stable snapshot (due in a few minutes)?

I comitted a fix for a different bug that might make a
difference to this one.

If it hasn't fixed it, could you post an https:// URL
that reproduces the problem, so that I can investigate
further?




[2003-09-24 11:36:55] chris dot edwards at obinet dot com

Getting the exact same error.  Same OS, same version of PHP.

Changing the length of the string offered no changes.  I still get:

 SSL: fatal protocol error 

I'm getting this for fread() and fgets().



[2003-08-21 20:25:22] info at splendense dot nl

Using '$buff = fgets ($f, 355);' does not give any error, however 356
does for me (php 4.3.2 solaris).

My script seems to work fine but maybe a response string greater than
355 chars will not work?!?



[2003-08-21 20:18:33] scottm at spamcop dot net

I've not verified this patch will work and I'll hopefully test it
tomorrow.

I believe it is reaching the end of the file and nr_bytes is returning
0 and this is being caught by an if statement which should be looking
for -1.

--- network.c   Thu Aug 21 21:06:43 2003
+++ network.c.patched   Thu Aug 21 21:13:09 2003
@@ -1011,13 +1011,14 @@
do {
nr_bytes = SSL_read(sock->ssl_handle, buf,
count);
 
-   if (nr_bytes <= 0) {
+   if (nr_bytes < 0) {
retry = handle_ssl_error(stream,
nr_bytes TSRMLS_CC);
if (retry == 0 &&
!SSL_pending(sock->ssl_handle)) {
stream->eof = 1;
}
} else {
-   /* we got the data */
+   /* we got the data */
+   stream->eof = 1;
break;
}
} while (retry);



[2003-08-05 09:43:36] uk at access dot lv

php4.3.2 configured with-openssl

if ($f = fopen('https://site', 'r')) {
while (!feof($f)) {
$buff = fgets ($f, 1024);
echo $buff;
}
}
fclose ($f);

Warning: fgets(): SSL: fatal protocol error

if i read just some bits then no 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/23220

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

#25639 [NoF->Csd]: problem with rand()

[sniper]

 ID:   25639
 Updated by:   [EMAIL PROTECTED]
 Reported By:  adamm at nycap dot rr dot com
-Status:   No Feedback
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: windows
 PHP Version:  4.3.3
 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-10-08 09:30:00] paul dot vaughan at weston dot ac dot uk

I was having this problem (PHP 4.3.3 on WinNT 4) but in response to
[EMAIL PROTECTED]'s question, the function 'srand()' does indeed fix the
problem.

The code:
for ($j=1; $j<10001; $j++) {
   print (rand(0, $j)."");
}
...produced the same ten thousand random numbers each and every time.
Putting srand() before the loop stopped this happening.

I hope this info is useful to someone; not sure anyone will read
this...!

Vaughany.



[2003-09-29 05:55:49] [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-09-23 22:29:00] [EMAIL PROTECTED]

Does this happen if you call srand() prior to calling the rand()
function?



[2003-09-23 18:37:38] adamm at nycap dot rr dot com

I downgraded to 4.3.2 and I dont have this problem. I also found
several posts on the net about many people on Win XP having this
problem with 4.3.3.

Definate bug id say.



[2003-09-23 18:21:40] adamm at nycap dot rr dot com

Description:

I am developing on a newly setup Windows XP Box running PHP 4.3.3 on
IIS as CGI.

The rand() function is not generating random numbers. Even with a
min/max declared it will only once generate a number in that range...
and than any other time called (even across browser sessions) it will
always and forever generate the same number.

The code below is broken down to the smallest example possible.

Reproduce code:
---


Expected result:

I expect to see a random number.

Actual result:
--
The same number is always displayed.





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

#25797 [Opn->Bgs]: Running the php cli more than once at the same command line causes it to hang.

[sniper]

 ID:   25797
 Updated by:   [EMAIL PROTECTED]
 Reported By:  brian at centurionservice dot com
-Status:   Open
+Status:   Bogus
 Bug Type: CGI related
 Operating System: Windows XP Pro
 PHP Version:  4.3.3
 New Comment:

Works fine for me.



Previous Comments:


[2003-10-08 12:32:23] brian at centurionservice dot com

Updated my summary



[2003-10-08 12:29:28] brian at centurionservice dot com

Description:

I am not running a webserver, this is for command line scripting only.

Running the PHP CLI binary more than once on the same command line
causes it to hang.  For example, running "C:\php\cli>php -v" twice in a
row causes the executable to hang.  Also, running "C:\php\cli>php
testfile.php" twice also causes it to hang.  Sourcecode of the test
file was simple .  Running "php -h" multiple times
in a row will not cause the problem.

I have tested this using the CGI binary as well and received the same
results.  Same results were achieved with 4.3.4RC1 as well.

Reproduce code:
---
not applicable

Expected result:

return to command line

Actual result:
--
program hangs.





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

#25797 [Bgs]: Running the php cli more than once at the same command line causes it to hang.

[sniper]

 ID:   25797
 Updated by:   [EMAIL PROTECTED]
 Reported By:  brian at centurionservice dot com
 Status:   Bogus
 Bug Type: CGI related
 Operating System: Windows XP Pro
 PHP Version:  4.3.3
 New Comment:

Works fine for me using latest STABLE CVS snapshot.



Previous Comments:


[2003-10-09 06:44:46] [EMAIL PROTECTED]

Works fine for me.




[2003-10-08 12:29:28] brian at centurionservice dot com

Description:

I am not running a webserver, this is for command line scripting only.

Running the PHP CLI binary more than once on the same command line
causes it to hang.  For example, running "C:\php\cli>php -v" twice in a
row causes the executable to hang.  Also, running "C:\php\cli>php
testfile.php" twice also causes it to hang.  Sourcecode of the test
file was simple .  Running "php -h" multiple times
in a row will not cause the problem.

I have tested this using the CGI binary as well and received the same
results.  Same results were achieved with 4.3.4RC1 as well.

Reproduce code:
---
not applicable

Expected result:

return to command line

Actual result:
--
program hangs.





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

#25254 [Opn->Bgs]: Using /r/n in mailheaders causes mailbody to become currupt

[sniper]

 ID:   25254
 Updated by:   [EMAIL PROTECTED]
 Reported By:  ts at dreamcoder dot dk
-Status:   Open
+Status:   Bogus
 Bug Type: Mail related
 Operating System: Linux
 PHP Version:  4.3.3
 New Comment:

Works fine with sendmail.



Previous Comments:


[2003-10-08 13:52:16] ts at dreamcoder dot dk

I just tested this with 4.3.4RC2-dev (as requested), it's exactly the
same problem

I also tried sending mail using PHPMailer (the class).
Sending mails directly to the SMTP with \r\n works just fine

However when using PHP's mail() and \r\n, it fails to send correctly,
as described in the original bug

I have PostFix 2.0.16 installed - if that has any relevance
I cannot rule out this could be a bug in Postfix, but I doubt it



[2003-10-07 19:16:11] [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





[2003-08-27 01:13:50] ts at dreamcoder dot dk

It's still an issue in terms of BC.

As I mentioned, it worked fine in 4.3.2



[2003-08-26 23:50:45] [EMAIL PROTECTED]

Either using \r\n or just \n works just fine for me.
Not PHP bug.




[2003-08-26 11:59:33] ts at dreamcoder dot dk

Description:

When running the attached code, the mail headers will not be sent
correctly

This results in the mailheaders becomming corrupt and send two
linebreaks, thus dumping the remaining headers to the mail body. Notice
how two Message-Id's and Date headers are sent with the mail

The attached code worked fine in PHP 4.3.2. But also works when using
\n instead of \r\n

Reproduce code:
---
\r\n"
."X-Engine: This\r\n"
."X-Mailer: PHP/" . phpversion());
?>

Expected result:

Headers:

From: John <[EMAIL PROTECTED]>
X-Engine: This
X-Mailer: PHP/4.3.3
Message-Id: <[EMAIL PROTECTED]>
Date: Tue, 26 Aug 2003 18:48:02 +0200 (CEST)

Hello

Actual result:
--
Headers:

From: John <[EMAIL PROTECTED]>
X-Engine: This
Message-ID: <[EMAIL PROTECTED]>
Date: Tue, 26 Aug 2003 18:48:09 +0200

X-Mailer: PHP/4.3.3
Message-Id: <[EMAIL PROTECTED]>
Date: Tue, 26 Aug 2003 18:48:02 +0200 (CEST)

Hello





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

#25799 [Opn->Bgs]: Problem again with Getimagesize

[sniper]

 ID:   25799
 Updated by:   [EMAIL PROTECTED]
 Reported By:  renato at ostorero dot it
-Status:   Open
+Status:   Bogus
 Bug Type: GetImageSize related
 Operating System: Windows 2003 Server
 PHP Version:  4.3.3
 New Comment:

Works fine with latest STABLE CVS snapshot.



Previous Comments:


[2003-10-08 14:29:43] renato at ostorero dot it

Description:

I check the bug database and I see that my problem could be the same of
Bug #21676.

Sometimes Getimagesize doesn't work with external image doesn't return
size, type etc ... and freeze the code until the timeout of the web
server.

In many cases the image was a png file.







Reproduce code:
---
$size = getimagesize("http://www.mysql.com/images/mysql.png";);
print_r($size); echo "\n";

Expected result:

Array ( [0] => 81 [1] => 43 [2] => 3 [3] => width="81" height="43"
[bits] => 8 [mime] => image/png ) 

Actual result:
--
Nothing.





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

#25803 [NEW]: xml_get_current_byte_index always returns 0 on windows

[j dot spit at uptime dot nl]

From: j dot spit at uptime dot nl
Operating system: Windows XP
PHP version:  5.0.0b1 (beta1)
PHP Bug Type: XML related
Bug description:  xml_get_current_byte_index always returns 0 on windows

Description:

xml_get_current_byte_index always returns 0 on windows xp, it works fine
on Linux systems. Using PHP5 beta 1 on both platforms.

Reproduce code:
---
";
}

function endElement($parser,$name) {
  echo "End : ".xml_get_current_byte_index( $parser )."";
}

$parser = xml_parser_create();
xml_set_element_handler($parser,'startElement','endElement');
xml_parser_set_option($parser,XML_OPTION_CASE_FOLDING,0);
xml_parse($parser,
  "testblaat");
xml_parser_free($parser);
?>


Expected result:

Start : 0
Start : 13
End : 21
End : 25

This is the output on a Linux system.

Actual result:
--
Start : 0
Start : 0
End : 0
End : 0

This is the output on a Windows XP system.

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

#25804 [NEW]: _SERVER['REQUEST_URI'] does not capture fragment

[greg at freephile dot com]

From: greg at freephile dot com
Operating system: RH Linux 8.0
PHP version:  4.3.3
PHP Bug Type: HTTP related
Bug description:  _SERVER['REQUEST_URI'] does not capture fragment

Description:

When a URI includes a fragment, that fragment is not captured as part of
the $_SERVER['REQUEST_URI'] variable, so it is not possible to use
parse_url() to get the fragment.  As an example,  the following request
will NOT have the fragment in the $_SERVER['REQUEST_URI'] variable:
http://www.freephile.com/admin/test.php?foo=bar#fragment

Instead, the $_SERVER['REQUEST_URI'] is given as
'/admin/test.php?foo=bar'

I use PHP to process outgoing site links on http://www.buzgate.org, but
due to this problem, I cannot redirect to external URIs containing a
fragment.  The workaround is to recode those URIs into two querystring
variables and then reconstruct the URI:
to=http://somewhere.com/somepage.html&fragment=named_anchor

$externalSiteURI = $_REQUEST['to'] . $_REQUEST['fragment'];

Reproduce code:
---
See
http://www.freephile.com/admin/test.php?foo=bar#fragment

and 
http://buzgate.org/referral.php?to=http://www.sba.gov/library/pubs.html#success4
(this link may be fixed with a workaround by the time you get this
message)

Expected result:

$_SERVER['REQUEST_URI'] = '/admin/test.php?foo=bar#fragment'

Actual result:
--
$_SERVER['REQUEST_URI'] = '/admin/test.php?foo=bar'

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

#25804 [Opn->Bgs]: _SERVER['REQUEST_URI'] does not capture fragment

[edink]

 ID:   25804
 Updated by:   [EMAIL PROTECTED]
 Reported By:  greg at freephile dot com
-Status:   Open
+Status:   Bogus
 Bug Type: HTTP related
 Operating System: RH Linux 8.0
 PHP Version:  4.3.3
 New Comment:

Browsers never send this part of URI to the server so there is no way
it can be "captured".


Previous Comments:


[2003-10-09 09:31:52] greg at freephile dot com

Description:

When a URI includes a fragment, that fragment is not captured as part
of the $_SERVER['REQUEST_URI'] variable, so it is not possible to use
parse_url() to get the fragment.  As an example,  the following request
will NOT have the fragment in the $_SERVER['REQUEST_URI'] variable:
http://www.freephile.com/admin/test.php?foo=bar#fragment

Instead, the $_SERVER['REQUEST_URI'] is given as
'/admin/test.php?foo=bar'

I use PHP to process outgoing site links on http://www.buzgate.org, but
due to this problem, I cannot redirect to external URIs containing a
fragment.  The workaround is to recode those URIs into two querystring
variables and then reconstruct the URI:
to=http://somewhere.com/somepage.html&fragment=named_anchor

$externalSiteURI = $_REQUEST['to'] . $_REQUEST['fragment'];

Reproduce code:
---
See
http://www.freephile.com/admin/test.php?foo=bar#fragment

and 
http://buzgate.org/referral.php?to=http://www.sba.gov/library/pubs.html#success4
(this link may be fixed with a workaround by the time you get this
message)

Expected result:

$_SERVER['REQUEST_URI'] = '/admin/test.php?foo=bar#fragment'

Actual result:
--
$_SERVER['REQUEST_URI'] = '/admin/test.php?foo=bar'





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

#25805 [NEW]: Problem Accessing Network Shares

[mattj at exitcare dot com]

From: mattj at exitcare dot com
Operating system: Windows 2003 Web Server
PHP version:  4.3.3
PHP Bug Type: Directory function related
Bug description:  Problem Accessing Network Shares

Description:

I've looked at the documentation for opendir() and it says:
opendir -- open directory handle
resource opendir ( string path)

It doesn't specifiy exactly what a valid path is, so maybe this isn't a
bug and is working as intended, but I don't know.

I used the following code to just test opendir() accross a network to a
windows share. The computer's name I am trying to access is 'matt', the IP
is '192.168.0.6', and the name of the share is 'F Drive'. I tried it with
both the UNC and the IP with the proper escaping and they didn't work. I
also tried them with forward slashes, didn't work either.

The 'F Drive' share on the XP machine PHP is trying to access has
Permissions set up to allow read access to 'Everyone', but with the nature
of the error, I don't think permissions is even relevant, but I figured I
should just mention that in case.

Are windows network shares / UNC's not supported by PHP? I couldn't find
any documentation on PHP's manual about network shares. They all returned
Invalid Argument.

Reproduce code:
---


Expected result:

Shouldn't error. No output.

Actual result:
--
Warning: opendir(\\matt\F Drive): failed to open dir: Invalid argument in
C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 6

Warning: opendir(\\192.168.0.6\F Drive): failed to open dir: Invalid
argument in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 7

Warning: opendir(//matt/F Drive): failed to open dir: Invalid argument in
C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 8

Warning: opendir(//192.168.0.6/F Drive): failed to open dir: Invalid
argument in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 9

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

#25807 [NEW]: Cant`t configure with OpenSSL support

[Richard dot Lacroix at USherbrooke dot ca]

From: Richard dot Lacroix at USherbrooke dot ca
Operating system: Solaris 8
PHP version:  4.3.4RC1
PHP Bug Type: OpenSSL related
Bug description:  Cant`t configure with OpenSSL support

Description:

OpenSSL 9.9.7c, PHP 4.3.4RC1, Solaris 8, GCC 2.95.3

Can't configure PHP with Openssl support.

./configure --with-openssl=/opt/local/openssl
returns configure: error: libssl not found!

Reproduce code:
---
In the config.log file, I have:
configure:16214: checking for SSL_CTX_set_ssl_version in -lssl
configure:16233: gcc -o conftest -g 02 -D_POSIX_PTHREAD_SEMANTICS
-R/opt/local/openssl/lib
-L /opt/local/openssl/lib ...etc...
Undefinedfirst referenced
 symbolin file
RSA_site  /opt/local/openssl/lib/libssl.a(ssl_lib.o)
...
...
...
ld:fatal: Symbol referencing errors. No output written to conftest
collect2: ld return 1 exit status


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

#25805 [Opn->Fbk]: Problem Accessing Network Shares

[wez]

 ID:   25805
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mattj at exitcare dot com
-Status:   Open
+Status:   Feedback
 Bug Type: Directory function related
 Operating System: Windows 2003 Web Server
 PHP Version:  4.3.3
 New Comment:

MSDN docs on FindFirstFile (the win32 API that underlies opendir)
state:

-
... Similarly, on network shares, you can use an lpFileName of the form
"\\server\service\*" but you cannot use an lpFileName that points to
the share itself, such as "\\server\service".

To examine any directory other than a root directory, use an
appropriate path to that directory, with no trailing backslash. For
example, an argument of "C:\windows" will return information about the
directory "C:\windows", not about any directory or file in
"C:\windows". An attempt to open a search with a trailing backslash
will always fail.
-

So, try it with a trailing backslash.


Previous Comments:


[2003-10-09 12:16:40] mattj at exitcare dot com

Description:

I've looked at the documentation for opendir() and it says:
opendir -- open directory handle
resource opendir ( string path)

It doesn't specifiy exactly what a valid path is, so maybe this isn't a
bug and is working as intended, but I don't know.

I used the following code to just test opendir() accross a network to a
windows share. The computer's name I am trying to access is 'matt', the
IP is '192.168.0.6', and the name of the share is 'F Drive'. I tried it
with both the UNC and the IP with the proper escaping and they didn't
work. I also tried them with forward slashes, didn't work either.

The 'F Drive' share on the XP machine PHP is trying to access has
Permissions set up to allow read access to 'Everyone', but with the
nature of the error, I don't think permissions is even relevant, but I
figured I should just mention that in case.

Are windows network shares / UNC's not supported by PHP? I couldn't
find any documentation on PHP's manual about network shares. They all
returned Invalid Argument.

Reproduce code:
---


Expected result:

Shouldn't error. No output.

Actual result:
--
Warning: opendir(\\matt\F Drive): failed to open dir: Invalid argument
in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 6

Warning: opendir(\\192.168.0.6\F Drive): failed to open dir: Invalid
argument in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 7

Warning: opendir(//matt/F Drive): failed to open dir: Invalid argument
in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 8

Warning: opendir(//192.168.0.6/F Drive): failed to open dir: Invalid
argument in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 9





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

#25808 [NEW]: echo output ok in cmd but not in web browser

[david dot nicholls at camden dot gov dot uk]

From: david dot nicholls at camden dot gov dot uk
Operating system: Windows 2000
PHP version:  4.3.3
PHP Bug Type: Output Control
Bug description:  echo output ok in cmd but not in web browser

Description:

Data sourced from a CSV file does not echo when a script is invoked via
web browser from IIS 5 but does output when invoked from a cmd via
php.exe.

A simple change of commenting out the line

$csv = get_csv ($csvname);

and uncommenting

// $csv = array ($line,$line,$line);

produces output in the browser and the console as expected

I have checked the CSV file and the data only contains alphanumeric
characters.


Reproduce code:
---
";
/*** CSV INPUT ***/
$csvname = 'camden-pdc\\logs$\\logon.csv';

echo "Loading CSV from $csvname";
$csv = get_csv ($csvname);

$line = array(1,"a",3,4,"b",6,7,8,9);
// $csv = array ($line,$line,$line);

echo "Got CSV Printing CSV";


foreach ($csv as $field)
{
$strecho = $field[2]."\t\t".$field[5]."\n\r";echo
addslashes($strecho);   
}



function get_csv($filename, $delim=',')
{
$row = 0;
$dump = array();
echo "get_csv function";
$f = fopen ($filename,"r");
$size = filesize($filename)+1;
while ($data = fgetcsv($f, $size, $delim)) {
$dump[$row] = $data;
$row++;
}
fclose ($f);

return $dump;
}
 
?>

Expected result:

Console Sample

C:\Inetpub\wwwroot>php av.php
Content-type: text/html
X-Powered-By: PHP/4.3.3

Read CSV and Output resultLoading CSV from
\\camden-pdc\logs$\logon.csvget
_csv functionGot CSV Printing CSVX039482  ENVIRONMENT
X034800 HOUSING
W024792 LEISURE
X030990 ENVIRONMENT
X036399 ITD
X041971 ENVIRONMENT
X033233 ENVIRONMENT
X031711 ENVIRONMENT
X036189 ENVIRONMENT
X047548 HOUSING
X035445 ENVIRONMENT
X039397 HOUSING
X033244 ENVIRONMENT
X026376 ENVIRONMENT

Actual result:
--
HTML Output

1 Read CSV and Output resultLoading CSV from
\\camden-pdc\logs$\logon.csvget_csv functionGot CSV Printing CSV

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

#25808 [Opn->Fbk]: echo output ok in cmd but not in web browser

[wez]

 ID:   25808
 Updated by:   [EMAIL PROTECTED]
 Reported By:  david dot nicholls at camden dot gov dot uk
-Status:   Open
+Status:   Feedback
 Bug Type: Output Control
 Operating System: Windows 2000
 PHP Version:  4.3.3
 New Comment:

My theory:

Your command prompt runs under your credentials, and you
have permission to access the network share.

IUSR_, the user under which IIS is running,
does not have permissions to access the share.

However, I would expect to see a warning in that case.


Previous Comments:


[2003-10-09 12:36:50] david dot nicholls at camden dot gov dot uk

Description:

Data sourced from a CSV file does not echo when a script is invoked via
web browser from IIS 5 but does output when invoked from a cmd via
php.exe.

A simple change of commenting out the line

$csv = get_csv ($csvname);

and uncommenting

// $csv = array ($line,$line,$line);

produces output in the browser and the console as expected

I have checked the CSV file and the data only contains alphanumeric
characters.


Reproduce code:
---
";
/*** CSV INPUT ***/
$csvname = 'camden-pdc\\logs$\\logon.csv';

echo "Loading CSV from $csvname";
$csv = get_csv ($csvname);

$line = array(1,"a",3,4,"b",6,7,8,9);
// $csv = array ($line,$line,$line);

echo "Got CSV Printing CSV";


foreach ($csv as $field)
{
$strecho = $field[2]."\t\t".$field[5]."\n\r";echo
addslashes($strecho);   
}



function get_csv($filename, $delim=',')
{
$row = 0;
$dump = array();
echo "get_csv function";
$f = fopen ($filename,"r");
$size = filesize($filename)+1;
while ($data = fgetcsv($f, $size, $delim)) {
$dump[$row] = $data;
$row++;
}
fclose ($f);

return $dump;
}
 
?>

Expected result:

Console Sample

C:\Inetpub\wwwroot>php av.php
Content-type: text/html
X-Powered-By: PHP/4.3.3

Read CSV and Output resultLoading CSV from
\\camden-pdc\logs$\logon.csvget
_csv functionGot CSV Printing CSVX039482  ENVIRONMENT
X034800 HOUSING
W024792 LEISURE
X030990 ENVIRONMENT
X036399 ITD
X041971 ENVIRONMENT
X033233 ENVIRONMENT
X031711 ENVIRONMENT
X036189 ENVIRONMENT
X047548 HOUSING
X035445 ENVIRONMENT
X039397 HOUSING
X033244 ENVIRONMENT
X026376 ENVIRONMENT

Actual result:
--
HTML Output

1 Read CSV and Output resultLoading CSV from
\\camden-pdc\logs$\logon.csvget_csv functionGot CSV Printing
CSV





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

#25808 [Fbk]: echo output ok in cmd but not in web browser

[wez]

 ID:   25808
 Updated by:   [EMAIL PROTECTED]
 Reported By:  david dot nicholls at camden dot gov dot uk
 Status:   Feedback
 Bug Type: Output Control
 Operating System: Windows 2000
 PHP Version:  4.3.3
 New Comment:

Just thought that it could be that filesize() is returning
-1 for the csv file; -1 + 1 == 0, which means that the fgetcsv()
function is returning no data at all, because you
have asked it for none.

Check the permissions on the file, and check the return value.  You
probably don't need the filesize() call at all; just use a reasonable
line length (1024 seems ok to me).



Previous Comments:


[2003-10-09 12:45:09] [EMAIL PROTECTED]

My theory:

Your command prompt runs under your credentials, and you
have permission to access the network share.

IUSR_, the user under which IIS is running,
does not have permissions to access the share.

However, I would expect to see a warning in that case.



[2003-10-09 12:36:50] david dot nicholls at camden dot gov dot uk

Description:

Data sourced from a CSV file does not echo when a script is invoked via
web browser from IIS 5 but does output when invoked from a cmd via
php.exe.

A simple change of commenting out the line

$csv = get_csv ($csvname);

and uncommenting

// $csv = array ($line,$line,$line);

produces output in the browser and the console as expected

I have checked the CSV file and the data only contains alphanumeric
characters.


Reproduce code:
---
";
/*** CSV INPUT ***/
$csvname = 'camden-pdc\\logs$\\logon.csv';

echo "Loading CSV from $csvname";
$csv = get_csv ($csvname);

$line = array(1,"a",3,4,"b",6,7,8,9);
// $csv = array ($line,$line,$line);

echo "Got CSV Printing CSV";


foreach ($csv as $field)
{
$strecho = $field[2]."\t\t".$field[5]."\n\r";echo
addslashes($strecho);   
}



function get_csv($filename, $delim=',')
{
$row = 0;
$dump = array();
echo "get_csv function";
$f = fopen ($filename,"r");
$size = filesize($filename)+1;
while ($data = fgetcsv($f, $size, $delim)) {
$dump[$row] = $data;
$row++;
}
fclose ($f);

return $dump;
}
 
?>

Expected result:

Console Sample

C:\Inetpub\wwwroot>php av.php
Content-type: text/html
X-Powered-By: PHP/4.3.3

Read CSV and Output resultLoading CSV from
\\camden-pdc\logs$\logon.csvget
_csv functionGot CSV Printing CSVX039482  ENVIRONMENT
X034800 HOUSING
W024792 LEISURE
X030990 ENVIRONMENT
X036399 ITD
X041971 ENVIRONMENT
X033233 ENVIRONMENT
X031711 ENVIRONMENT
X036189 ENVIRONMENT
X047548 HOUSING
X035445 ENVIRONMENT
X039397 HOUSING
X033244 ENVIRONMENT
X026376 ENVIRONMENT

Actual result:
--
HTML Output

1 Read CSV and Output resultLoading CSV from
\\camden-pdc\logs$\logon.csvget_csv functionGot CSV Printing
CSV





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

#25807 [Opn->Bgs]: Cant`t configure with OpenSSL support

[elmicha]

 ID:   25807
 Updated by:   [EMAIL PROTECTED]
 Reported By:  Richard dot Lacroix at USherbrooke dot ca
-Status:   Open
+Status:   Bogus
 Bug Type: OpenSSL related
 Operating System: Solaris 8
 PHP Version:  4.3.4RC1
 New Comment:

Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.

Thank you for your interest in PHP.

See http://bugs.php.net/bug.php?id=25719; it's fixed in the latest
stable snapshot from http://snaps.php.net.


Previous Comments:


[2003-10-09 12:32:03] Richard dot Lacroix at USherbrooke dot ca

Description:

OpenSSL 9.9.7c, PHP 4.3.4RC1, Solaris 8, GCC 2.95.3

Can't configure PHP with Openssl support.

./configure --with-openssl=/opt/local/openssl
returns configure: error: libssl not found!

Reproduce code:
---
In the config.log file, I have:
configure:16214: checking for SSL_CTX_set_ssl_version in -lssl
configure:16233: gcc -o conftest -g 02 -D_POSIX_PTHREAD_SEMANTICS
-R/opt/local/openssl/lib
-L /opt/local/openssl/lib ...etc...
Undefinedfirst referenced
 symbolin file
RSA_site  /opt/local/openssl/lib/libssl.a(ssl_lib.o)
...
...
...
ld:fatal: Symbol referencing errors. No output written to conftest
collect2: ld return 1 exit status






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

#25805 [Fbk->Opn]: Problem Accessing Network Shares

[mattj at exitcare dot com]

 ID:   25805
 User updated by:  mattj at exitcare dot com
 Reported By:  mattj at exitcare dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Directory function related
 Operating System: Windows 2003 Web Server
 PHP Version:  4.3.3
 New Comment:

Looks like it yields the same results.



Warning: opendir(\\matt\F Drive\): failed to open dir: Invalid argument
in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 6

Warning: opendir(\\192.168.0.6\F Drive\): failed to open dir: Invalid
argument in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 7

Warning: opendir(//matt/F Drive/): failed to open dir: Invalid argument
in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 8

Warning: opendir(//192.168.0.6/F Drive/): failed to open dir: Invalid
argument in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 9


Previous Comments:


[2003-10-09 12:32:58] [EMAIL PROTECTED]

MSDN docs on FindFirstFile (the win32 API that underlies opendir)
state:

-
... Similarly, on network shares, you can use an lpFileName of the form
"\\server\service\*" but you cannot use an lpFileName that points to
the share itself, such as "\\server\service".

To examine any directory other than a root directory, use an
appropriate path to that directory, with no trailing backslash. For
example, an argument of "C:\windows" will return information about the
directory "C:\windows", not about any directory or file in
"C:\windows". An attempt to open a search with a trailing backslash
will always fail.
-

So, try it with a trailing backslash.



[2003-10-09 12:16:40] mattj at exitcare dot com

Description:

I've looked at the documentation for opendir() and it says:
opendir -- open directory handle
resource opendir ( string path)

It doesn't specifiy exactly what a valid path is, so maybe this isn't a
bug and is working as intended, but I don't know.

I used the following code to just test opendir() accross a network to a
windows share. The computer's name I am trying to access is 'matt', the
IP is '192.168.0.6', and the name of the share is 'F Drive'. I tried it
with both the UNC and the IP with the proper escaping and they didn't
work. I also tried them with forward slashes, didn't work either.

The 'F Drive' share on the XP machine PHP is trying to access has
Permissions set up to allow read access to 'Everyone', but with the
nature of the error, I don't think permissions is even relevant, but I
figured I should just mention that in case.

Are windows network shares / UNC's not supported by PHP? I couldn't
find any documentation on PHP's manual about network shares. They all
returned Invalid Argument.

Reproduce code:
---


Expected result:

Shouldn't error. No output.

Actual result:
--
Warning: opendir(\\matt\F Drive): failed to open dir: Invalid argument
in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 6

Warning: opendir(\\192.168.0.6\F Drive): failed to open dir: Invalid
argument in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 7

Warning: opendir(//matt/F Drive): failed to open dir: Invalid argument
in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 8

Warning: opendir(//192.168.0.6/F Drive): failed to open dir: Invalid
argument in C:\Inetpub\wwwroot\ExitCareWeb\test.php on line 9





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

#25809 [NEW]: attempting to configure with xslt option breaks configure script for yp

[xirkus at z1r0 dot com]

From: xirkus at z1r0 dot com
Operating system: Linux Kernel 2.4.21
PHP version:  4.3.2
PHP Bug Type: *Compile Issues
Bug description:  attempting to configure with xslt option breaks configure script for 
yp

Description:

When ever I attempt to compile php 4.3.2 with both the :

--enable-xslt
--with-xslt-sablot=/usr/local/lib

options and :

--enable-yp

in my configure script, I receive the following errors:

configure: error: Unable to find required yp/nis library
make: *** No targets sepcified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
make: *** No rule to make target `distclean'. Stop.

If I remove the xslt options, configure compiles php without any problems
what so ever.

Help resolving this issue would be greatly appreciated.

Mel Llaguno


Expected result:

I should be able to compile php with both the --enable-yp and
--enable-xslt options working.


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

#25810 [NEW]: need dmalloc path variable

[sbrennan at southerncountiestitle dot com]

From: sbrennan at southerncountiestitle dot com
Operating system: RH 9 kernel 2.6.0-test6
PHP version:  5.0.0b1 (beta1)
PHP Bug Type: Compile Failure
Bug description:  need dmalloc path variable

Description:

Simple run, without enabling dmalloc, if dmalloc is enabled in another
program that is then compiled into php, php still requires the dmalloc
libs and includes.  I know this is obvious, but other apps allow admins to
place the dmalloc in a particular place, especially if they are testing
multiple installations, etc.

Currently, php5 configure script does not allow for the explicit naming of
a dmalloc path, etc.

Not a bug, but can be confusing for others, if they did not ask for
dmalloc, but it fails because snmp was able to explicitly name the path to
dmalloc, and the user wants snmp functions.

Its splitting hairs, but I figured I'd tell you, since someone reported it
to me as a bug.

I linked the correct version of dmalloc into the /usr/local directories,
and it compiles fine.


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

#25810 [Opn]: need dmalloc path variable

[sbrennan at southerncountiestitle dot com]

 ID:   25810
 User updated by:  sbrennan at southerncountiestitle dot com
 Reported By:  sbrennan at southerncountiestitle dot com
 Status:   Open
 Bug Type: Compile Failure
 Operating System: RH 9 kernel 2.6.0-test6
 PHP Version:  5.0.0b1 (beta1)
 New Comment:

I apologise for the above.  I just read it and I thought English was my
second language.

Step 1: Compile DMALLOC for testing in a version specific path (ex.
/usr/local/dmalloc.v.X)

Step 2: Compile NET-SNMP with DMALLOC libs (./configure
...--with-dmalloc[=DIR]  ...

Step 3: Run configure in PHP5 source, and --with-snmp[=DIR].
(no --enable-dmalloc)


running the configure script returns no errors, but a make kicks out
with a "can't find dmalloc.h" error.
 
Simple solution would be to give --with-dmalloc[=DIR] instead of
--enable-dmalloc

OR in the manual, (common sense, I know) remind everyone that if no
path is allowed for a particular switch, then it must be in the search
path of the makefile, or, if looking in a makefile is too much,
directions to symbolicly link the necessary lib and include files to
/usr/local/ or whatever.


Previous Comments:


[2003-10-09 14:47:31] sbrennan at southerncountiestitle dot com

Description:

Simple run, without enabling dmalloc, if dmalloc is enabled in another
program that is then compiled into php, php still requires the dmalloc
libs and includes.  I know this is obvious, but other apps allow admins
to place the dmalloc in a particular place, especially if they are
testing multiple installations, etc.

Currently, php5 configure script does not allow for the explicit naming
of a dmalloc path, etc.

Not a bug, but can be confusing for others, if they did not ask for
dmalloc, but it fails because snmp was able to explicitly name the path
to dmalloc, and the user wants snmp functions.

Its splitting hairs, but I figured I'd tell you, since someone reported
it to me as a bug.

I linked the correct version of dmalloc into the /usr/local
directories, and it compiles fine.






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

#25811 [NEW]: version_compare fails on some versions

[pmateescu at novosadhayes dot com]

From: pmateescu at novosadhayes dot com
Operating system: Windows XP
PHP version:  4.3.2
PHP Bug Type: PHP options/info functions
Bug description:  version_compare fails on some versions

Description:

version_compare seems to return invalid results in two cases:
0.1a vs 0.1 and 1.0.a vs 1.0. in both cases the value on the left should
be the newest version.
If the a (alpha) is confusing it, then it does the same for other letters
(e.g. M).

Reproduce code:
---
$test = array (
array('0.1', '0.1', 0),
array('0.1', '0.2', -1),
array('0.3', '0.2', 1),
array('0.1.0', '0.1', 1),
array('0.1a', '0.1', 1),
array('0.1m', '0.1', 1),
array('0.1z', '0.1', 1),
array('0.1a', '0.1b', -1),
array('0.1.a', '0.1', 1),
array('0.1.a', '0.1.b', -1),
array('0.1-pre2', '0.1-pre1', 1),
array('0.11', '0.2', 1),
array('0.11.1', '0.2.3', 1)
);

foreach($test as $vals) {
$ret = version_compare($vals[0], $vals[1]);
echo "$vals[0] vs $vals[1] should be $vals[2] and is $ret ...[". ($ret
=== $vals[2] ? 'PASSED' : 'FAILED') ."]\n";
}


Expected result:

all of them should return PASSED.

Actual result:
--
0.1 vs 0.1 should be 0 and is 0 ...[PASSED]
0.1 vs 0.2 should be -1 and is -1 ...[PASSED]
0.3 vs 0.2 should be 1 and is 1 ...[PASSED]
0.1.0 vs 0.1 should be 1 and is 1 ...[PASSED]
0.1a vs 0.1 should be 1 and is -1 ...[FAILED]
0.1m vs 0.1 should be 1 and is -1 ...[FAILED]
0.1z vs 0.1 should be 1 and is -1 ...[FAILED]
0.1a vs 0.1b should be -1 and is -1 ...[PASSED]
0.1.a vs 0.1 should be 1 and is -1 ...[FAILED]
0.1.a vs 0.1.b should be -1 and is -1 ...[PASSED]
0.1-pre2 vs 0.1-pre1 should be 1 and is 1 ...[PASSED]
0.11 vs 0.2 should be 1 and is 1 ...[PASSED]
0.11.1 vs 0.2.3 should be 1 and is 1 ...[PASSED]

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

#25809 [Opn->Bgs]: attempting to configure with xslt option breaks configure script for yp

[elmicha]

 ID:   25809
 Updated by:   [EMAIL PROTECTED]
 Reported By:  xirkus at z1r0 dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *Compile Issues
 Operating System: Linux Kernel 2.4.21
 PHP Version:  4.3.2
 New Comment:

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

Please try with the latest stable snapshot from .


Previous Comments:


[2003-10-09 13:30:25] xirkus at z1r0 dot com

Description:

When ever I attempt to compile php 4.3.2 with both the :

--enable-xslt
--with-xslt-sablot=/usr/local/lib

options and :

--enable-yp

in my configure script, I receive the following errors:

configure: error: Unable to find required yp/nis library
make: *** No targets sepcified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
make: *** No rule to make target `distclean'. Stop.

If I remove the xslt options, configure compiles php without any
problems what so ever.

Help resolving this issue would be greatly appreciated.

Mel Llaguno


Expected result:

I should be able to compile php with both the --enable-yp and
--enable-xslt options working.






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

#25812 [NEW]: php_SSL_new_from_context needs to be merged from 4.3

[[EMAIL PROTECTED]]

From: [EMAIL PROTECTED]
Operating system: Any
PHP version:  5CVS-2003-10-09 (dev)
PHP Bug Type: OpenSSL related
Bug description:  php_SSL_new_from_context needs to be merged from 4.3

Description:

The SSL context options need to be ported up to HEAD
from the 4.3 branch before PHP 5 is released.


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

#25812 [Opn->Asn]: php_SSL_new_from_context needs to be merged from 4.3

[wez]

 ID:   25812
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: OpenSSL related
 Operating System: Any
 PHP Version:  5CVS-2003-10-09 (dev)
-Assigned To:  
+Assigned To:  wez


Previous Comments:


[2003-10-09 18:10:35] [EMAIL PROTECTED]

Description:

The SSL context options need to be ported up to HEAD
from the 4.3 branch before PHP 5 is released.






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

#25809 [Bgs]: attempting to configure with xslt option breaks configure script for yp

[sniper]

 ID:   25809
 Updated by:   [EMAIL PROTECTED]
 Reported By:  xirkus at z1r0 dot com
 Status:   Bogus
 Bug Type: Compile Failure
 Operating System: Linux Kernel 2.4.21
 PHP Version:  4.3.2
 New Comment:

And by using correct configure options might help too:

--with-xslt-sablot=/usr/local



Previous Comments:


[2003-10-09 18:07:00] [EMAIL PROTECTED]

Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.

Please try with the latest stable snapshot from .



[2003-10-09 13:30:25] xirkus at z1r0 dot com

Description:

When ever I attempt to compile php 4.3.2 with both the :

--enable-xslt
--with-xslt-sablot=/usr/local/lib

options and :

--enable-yp

in my configure script, I receive the following errors:

configure: error: Unable to find required yp/nis library
make: *** No targets sepcified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
make: *** No rule to make target `distclean'. Stop.

If I remove the xslt options, configure compiles php without any
problems what so ever.

Help resolving this issue would be greatly appreciated.

Mel Llaguno


Expected result:

I should be able to compile php with both the --enable-yp and
--enable-xslt options working.






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

#25813 [NEW]: persistent socket liveness checks need merging from 4.3

[[EMAIL PROTECTED]]

From: [EMAIL PROTECTED]
Operating system: any
PHP version:  5CVS-2003-10-09 (dev)
PHP Bug Type: *Network Functions
Bug description:  persistent socket liveness checks need merging from 4.3

Description:

The liveness checks for pfsockopen() need to be
ported up to HEAD from the 4.3 branch before PHP 5
is released.


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

#25813 [Opn->Asn]: persistent socket liveness checks need merging from 4.3

[wez]

 ID:   25813
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Open
+Status:   Assigned
 Bug Type: *Network Functions
 Operating System: any
 PHP Version:  5CVS-2003-10-09 (dev)
-Assigned To:  
+Assigned To:  wez


Previous Comments:


[2003-10-09 18:12:41] [EMAIL PROTECTED]

Description:

The liveness checks for pfsockopen() need to be
ported up to HEAD from the 4.3 branch before PHP 5
is released.






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

#24949 [Com]: Requesting a nicer way of setting undefined variables to a default value.

[marcus at deck16 dot com]

 ID:   24949
 Comment by:   marcus at deck16 dot com
 Reported By:  nickj-php at nickj dot org
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Any
 PHP Version:  Irrelevant
 New Comment:

I also came across that "problem" and voted for that "bug".

It is possible to write a function though. Just pass the var Name as a
string:




Previous Comments:


[2003-08-22 12:00:36] xuefer at 21cn dot com

it would be nice to use "?:" operator as new c++ language

$a = isset($a) ? $a : "";
->
$a = $a ?: "";

$a = $a ?: $b ?: $c ?: $d;
better than:
$a = default($a, $b, $c, $d);



[2003-08-18 21:27:38] hurst at webteks dot com

That there is no way to write a function to handle unset vars is also
something I have come across. 

One solution would be to use the @-symbol:

print noUnset(@$x, "not set");

However, the @-symbol is not guaranteed to work, since
a user-defined error handler will ignore it.

Only isset(), unset(), and empty() can handle undefined variables
without implicitly declaring them.


Perhaps a new construct can be made available to handle
this common case.


default($var['not_a_key'],"default_value") => "default_value"


It would work like the following function, but using the
caller environment (which could be from within another function):

function default($var,$default="")
{
return isset($var)?$var:$default;
}

Using "" for the inherent default value makes sense
for web interfaces.



[2003-08-05 05:28:19] nickj-php at nickj dot org

Description:

Requesting a nicer way of setting undefined variables to a default
value.

It gets a bit repetitive and ugly having to use statements like:

$title   = isset($vals["title"])  ? $vals["title"]  :
"";
$first   = isset($vals["first_name"]) ? $vals["first_name"] :
"";
$surname = isset($vals["surname"])? $vals["surname"]:
"";

This seems to be a recurrent requirement, so ideally there would be
some way of doing this, along the lines of :

function noUnset($val, $default="") {
return isset($val) ? $val : $default;
}

Unfortunately a user function such as the above cannot be defined to do
this, since the first argument passed to the function would be unset.

For example, this code will generate an error:

==

error_reporting (E_ALL);

function noUnset($val, $default="") {
return isset($val) ? $val : $default;
}

if (isset($x)) unset ($x);
// $x = 2; // works OK if this line is uncommented
print noUnset($x, "not set");
// Above line generates an error as noUnset cannot be called with $x,
because it is not set - catch-22 !

==

This code generates an "Undefined variable:  x" error.

Ideally there would be slightly nicer way of setting defaults than a
bank is "isset" statements, that would work without generating an
error, even with all error reporting options turned on.






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

#25814 [NEW]: Incorrect flock return

[mike at aqua-helix dot com]

From: mike at aqua-helix dot com
Operating system: Linux RedHat 7.3
PHP version:  4.3.4RC1
PHP Bug Type: Filesystem function related
Bug description:  Incorrect flock return

Description:

>From documentation about 'flock':
The optional third argument is set to TRUE if the lock would block
(EWOULDBLOCK errno condition)

Actualy third argument will never set to true due to error in
implementation. Let see the code (line 253 in 'file.c'):

if ((ret=flock(fd, act)) == -1) {
RETURN_FALSE;
}
if(ret == -1 && errno == EWOULDBLOCK && arg_count == 3) {
ZVAL_LONG(*arg3, 1);
}

The second 'if' will never act as if ret==1 function immediately returns
false in the first 'if'

Here is my version:

if ((ret=flock(fd, act)) == -1) {
 if( errno == EWOULDBLOCK && arg_count == 3)
   ZVAL_LONG(arg3, 1);

 RETURN_FALSE;
}




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

#25803 [Opn->Asn]: xml_get_current_byte_index() always returns 0 on PHP 5.x

[moriyoshi]

 ID:   25803
 Updated by:   [EMAIL PROTECTED]
-Summary:  xml_get_current_byte_index always returns 0 on windows
 Reported By:  j dot spit at uptime dot nl
-Status:   Open
+Status:   Assigned
 Bug Type: XML related
-Operating System: Windows XP
+Operating System: Irrelevant
-PHP Version:  5.0.0b1 (beta1)
+PHP Version:  5CVS-2003-10-10
-Assigned To:  
+Assigned To:  moriyoshi


Previous Comments:


[2003-10-09 09:11:55] j dot spit at uptime dot nl

Description:

xml_get_current_byte_index always returns 0 on windows xp, it works
fine on Linux systems. Using PHP5 beta 1 on both platforms.

Reproduce code:
---
";
}

function endElement($parser,$name) {
  echo "End : ".xml_get_current_byte_index( $parser )."";
}

$parser = xml_parser_create();
xml_set_element_handler($parser,'startElement','endElement');
xml_parser_set_option($parser,XML_OPTION_CASE_FOLDING,0);
xml_parse($parser,
  "testblaat");
xml_parser_free($parser);
?>


Expected result:

Start : 0
Start : 13
End : 21
End : 25

This is the output on a Linux system.

Actual result:
--
Start : 0
Start : 0
End : 0
End : 0

This is the output on a Windows XP system.





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

#25814 [Opn]: Incorrect flock return

[mike at aqua-helix dot com]

 ID:   25814
 User updated by:  mike at aqua-helix dot com
 Reported By:  mike at aqua-helix dot com
 Status:   Open
 Bug Type: Filesystem function related
 Operating System: Linux RedHat 7.3
 PHP Version:  4.3.4RC1
 New Comment:

>From documentation about 'flock':
The optional third argument is set to TRUE if the lock would block
(EWOULDBLOCK errno condition)

Actualy third argument will never set to true due to error in
implementation. Let see the code (line 253 in 'file.c'):

if ((ret=flock(fd, act)) == -1) {
RETURN_FALSE;
}
if(ret == -1 && errno == EWOULDBLOCK && arg_count == 3) {
ZVAL_LONG(*arg3, 1);
}

The second 'if' will never act as if ret==-1 function immediately
returns
false in the first 'if'

Here is my version:

if ((ret=flock(fd, act)) == -1) {
 if( errno == EWOULDBLOCK && arg_count == 3)
   ZVAL_LONG(arg3, 1);

 RETURN_FALSE;
}


Previous Comments:


[2003-10-09 19:13:47] mike at aqua-helix dot com

Description:

>From documentation about 'flock':
The optional third argument is set to TRUE if the lock would block
(EWOULDBLOCK errno condition)

Actualy third argument will never set to true due to error in
implementation. Let see the code (line 253 in 'file.c'):

if ((ret=flock(fd, act)) == -1) {
RETURN_FALSE;
}
if(ret == -1 && errno == EWOULDBLOCK && arg_count == 3) {
ZVAL_LONG(*arg3, 1);
}

The second 'if' will never act as if ret==1 function immediately
returns false in the first 'if'

Here is my version:

if ((ret=flock(fd, act)) == -1) {
 if( errno == EWOULDBLOCK && arg_count == 3)
   ZVAL_LONG(arg3, 1);

 RETURN_FALSE;
}








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

#25623 [NoF->Opn]: Memory leak in function load()

[maoy at fjii dot com]

 ID:   25623
 User updated by:  maoy at fjii dot com
 Reported By:  maoy at fjii dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: OCI8 related
 Operating System: Windows XP
 PHP Version:  4.3.3
 New Comment:

I'm not able to compile a debug-build, but it's undoubted that the
function cause memory leak. Please help me as soon as possible.

I am looking forward to reply. Thank you very much.


Previous Comments:


[2003-09-29 05:57:03] [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-09-24 05:41:54] [EMAIL PROTECTED]

sorry, if the leak does not show on unix there's not much 
i can do as i don't run windows. 
 
can you compile a debug-build and see if php actually 
complains about mem-leaks? 
 



[2003-09-22 06:04:55] maoy at fjii dot com

In fact, I tried to use following codes:

ocifetchinto($stmt, $arr,OCI_ASSOC); 
$result = $arr["CLOB_FLDNAME"]->load(); 

but it always cause memory leak on Windows system. It doesn't cause
memory leak on Linux system.

By the way, running environment is:
Windows XP
Apache 1.3.26
PHP 4.3.3
Oracle 8.1.7

I am looking forward to reply.



[2003-09-22 05:09:45] [EMAIL PROTECTED]

could you plz replace  
$result = OCIResult($stmt, "clob_fldname"); 
if (is_object ($result)) $result = $result->load(); 
against: 
ocifetchinto($stmt, $arr,OCI_ASSOC); 
$result = $arr["CLOB_FLDNAME"]->load(); 
 
as this is the code i use all the time and it doesn't 
(seem) to leak for me. 
 



[2003-09-21 22:55:48] maoy at fjii dot com

memory leak size relate with value of the field, it also increase along
with running times



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/25623

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

#25815 [NEW]: __get & __set will not fire if the object contains reference to variable

[dan at wep dot net]

From: dan at wep dot net
Operating system: Linux (Redhat 9, 2.4.22)
PHP version:  5CVS-2003-10-09 (dev)
PHP Bug Type: Class/Object related
Bug description:  __get & __set will not fire if the object contains reference to 
variable

Description:

When a class definition contains any reference to a variable name that
will be later used in a __set() (or __get()) operation, the setter (or
getter) will not fire.

This variable does not have to be defined or used at all. The code must
simply exist.

In the following example code, simply comment out the print($this->myVar);
line and you will see the 'setter fired' message.

This is NOT similar to bug #24608 as the element never gets created in
this case.

Reproduce code:
---
class test {
  function unusedFunction() {
print($this->myVar);  
  }
  function __set($nm, $vl) {
print('setter fired');
  }
}

$obj = new test();
$obj->myVar = 'some data';

Expected result:

'setter fired'


Actual result:
--
Nothing.

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

#25814 [Opn->Csd]: Incorrect flock return

[iliaa]

 ID:   25814
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mike at aqua-helix dot com
-Status:   Open
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: Linux RedHat 7.3
 PHP Version:  4.3.4RC1
 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-10-09 19:13:47] mike at aqua-helix dot com

Description:

>From documentation about 'flock':
The optional third argument is set to TRUE if the lock would block
(EWOULDBLOCK errno condition)

Actualy third argument will never set to true due to error in
implementation. Let see the code (line 253 in 'file.c'):

if ((ret=flock(fd, act)) == -1) {
RETURN_FALSE;
}
if(ret == -1 && errno == EWOULDBLOCK && arg_count == 3) {
ZVAL_LONG(*arg3, 1);
}

The second 'if' will never act as if ret==1 function immediately
returns false in the first 'if'

Here is my version:

if ((ret=flock(fd, act)) == -1) {
 if( errno == EWOULDBLOCK && arg_count == 3)
   ZVAL_LONG(arg3, 1);

 RETURN_FALSE;
}








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

#25816 [NEW]: Class constants of type array hold directly inaccessible keys/values

[dan at wep dot net]

From: dan at wep dot net
Operating system: Linux (Redhat 9, 2.4.22)
PHP version:  5CVS-2003-10-10 (dev)
PHP Bug Type: Class/Object related
Bug description:  Class constants of type array hold directly inaccessible keys/values

Description:

Constants defined inside classes can be defined as an array prepopulated
with key, value pairs; however this data is not directly accessible.

It is possible to create a local variable copy of the constant at runtime
and use it to access the data.

If class constants are not meant to be able to hold array data, then a
parse error should of been thrown on the 'const' declaration.

Reproduce code:
---
class test {
  const someData = array('foo' => 'bar');

  function __construct() {
$dataCopy = someData;
print($dataCopy['foo']);  // This works
print(var_dump(someData));  // This works (shows all array
information)
print(someData['foo']);  // This throws a parse error
  }

}

$obj = new test();

Expected result:

bar
bar
bar

.. Jackpot! :)

Actual result:
--
Parse error: parse error, unexpected '[' 

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

#25816 [Opn]: Class constants of type array hold directly inaccessible keys/values

[dan at wep dot net]

 ID:   25816
 User updated by:  dan at wep dot net
 Reported By:  dan at wep dot net
 Status:   Open
 Bug Type: Class/Object related
 Operating System: Linux (Redhat 9, 2.4.22)
 PHP Version:  5CVS-2003-10-10 (dev)
 New Comment:

The parse error thrown complains about the print(someData['foo']) line.
Sorry if this wasn't clear. Also expected output would probably be more
like "bar ..var_dump output.. bar.


Previous Comments:


[2003-10-10 00:24:51] dan at wep dot net

Description:

Constants defined inside classes can be defined as an array
prepopulated with key, value pairs; however this data is not directly
accessible.

It is possible to create a local variable copy of the constant at
runtime and use it to access the data.

If class constants are not meant to be able to hold array data, then a
parse error should of been thrown on the 'const' declaration.

Reproduce code:
---
class test {
  const someData = array('foo' => 'bar');

  function __construct() {
$dataCopy = someData;
print($dataCopy['foo']);  // This works
print(var_dump(someData));  // This works (shows all array
information)
print(someData['foo']);  // This throws a parse error
  }

}

$obj = new test();

Expected result:

bar
bar
bar

.. Jackpot! :)

Actual result:
--
Parse error: parse error, unexpected '[' 





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