Bug #49815 [NoF-Opn]: Problem with imagettfbbox

2013-01-19 Thread philip
Edit report at https://bugs.php.net/bug.php?id=49815edit=1

 ID: 49815
 Updated by: phi...@php.net
 Reported by:christian dot roy at orange dot fr
 Summary:Problem with imagettfbbox
-Status: No Feedback
+Status: Open
 Type:   Bug
 Package:GD related
 Operating System:   Linux
 PHP Version:5.2.11
 Assigned To:tabe
 Block user comment: N
 Private report: N



Previous Comments:

[2010-10-31 19:55:31] php at zunderer dot de

It seems like this Bug is still present, both of the Testscripts 
provided by rasmus here and by ch+php in Bug #49600 produce 
correct results in PHP 5.0.5 and 5.2.5 but wrong results 
(x-coord of boundingbox shifted to left or right depending on 
Font and letter) on PHP 5.2.11 and 5.3.3


[2010-01-22 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.


[2010-01-14 05:00:49] t...@php.net

s/#45600/#49600/


[2010-01-14 04:59:07] t...@php.net

rasmus, your observation is essential to understand this bug.
fix for bug#45600 also seems to work well.

With PHP_5_2 or trunk:

bbox returned rectangle for a : -1  *  2  *  38  *  2  *  38  *  -42  *  -1  *  
-42

bbox returned rectangle for k : -1  *  -1  *  42  *  -1  *  42  *  -62  *  -1  
*  -62

bbox returned rectangle for j : -1  *  17  *  23  *  17  *  23  *  -57  *  -1  
*  -57


[2009-12-23 17:49:24] christian dot roy at orange dot fr

Hi,

Did you progress on this issue whicj sticks me to PHP 4.

Thanks for your answer.




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

https://bugs.php.net/bug.php?id=49815


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=49815edit=1


Req #24337 [Wfx-Opn]: additional configure --with-avail, and fix --enable-all

2012-09-16 Thread philip
Edit report at https://bugs.php.net/bug.php?id=24337edit=1

 ID: 24337
 Updated by: phi...@php.net
 Reported by:philip at cornado dot com
 Summary:additional configure --with-avail, and fix
 --enable-all
-Status: Wont fix
+Status: Open
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   all
 PHP Version:4.3.3RC1
 Block user comment: N
 Private report: N

 New Comment:

Not sure how a feature request can be closed like this, and besides, 
--enable-all 
does not work like the --with-avail description.


Previous Comments:

[2010-11-19 01:12:06] j...@php.net

It already works like 'with-avail'. And not very useful either.


[2003-06-25 11:59:34] philip at cornado dot com

Description:

The following configure options would be nice:

New features:
---
--with-avail   : Compiles in all --with-* extensions that 
 are available on a system.  If not
 available/found, they are skipped.
--enable-avail : Alias to --enable-all as I assume all
 enables are available.  Maybe not?
--with-all : Attempts to compile with all --with-*
 extensions, available or not.

Changed behavior:
---
--enable-all   : Attempts to compile in all --enable-*
 extensions.  Currently this attempts to
 compile in --with and --enable, so can
 be considered broken.

There can also be --without-all and --disable-all although   --disable-all 
currently exists, it disables everything, --with or --enable.

So, this is also a request to fix --enable-all or perhaps rename it as 
--with-all (but even then it wouldn't be fully accurate).







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=24337edit=1


Bug #54037 [Csd-ReO]: [PATCH] Adds the ability to pass options to loadHTML

2012-08-07 Thread philip
Edit report at https://bugs.php.net/bug.php?id=54037edit=1

 ID: 54037
 Updated by: phi...@php.net
 Reported by:fxmulder at gmail dot com
 Summary:[PATCH] Adds the ability to pass options to loadHTML
-Status: Closed
+Status: Re-Opened
 Type:   Bug
 Package:DOM XML related
 PHP Version:trunk-SVN-2011-02-17 (SVN)
 Assigned To:tyrael
 Block user comment: N
 Private report: N

 New Comment:

The documentation patch was not committed.


Previous Comments:

[2012-07-22 23:39:47] tyr...@php.net

This bug has been fixed in SVN.

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

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

I've opened a separate bug for the documentation issue: 
https://bugs.php.net/bug.php?id=62635


[2011-08-12 21:07:45] fxmulder at gmail dot com

I've included a patch for proposed documentation changes for the new options


[2011-07-11 11:30:30] chr...@php.net

Committed to trunk and PHP_5_4 branch


[2011-03-29 22:27:40] fxmulder at gmail dot com

That works for me, this still good to be committed to the trunk?


[2011-03-03 08:12:00] chr...@php.net

The following patch has been added/updated:

Patch Name: patch-for-adding-loadhtml-options.patch
Revision:   1299136320
URL:
http://bugs.php.net/patch-display.php?bug=54037patch=patch-for-adding-loadhtml-options.patchrevision=1299136320




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

https://bugs.php.net/bug.php?id=54037


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=54037edit=1


Bug #50696 [Wfx]: number_format when passed a 0 as first function argument, returns null

2012-06-22 Thread philip
Edit report at https://bugs.php.net/bug.php?id=50696edit=1

 ID: 50696
 Updated by: phi...@php.net
 Reported by:endosquid at endosquid dot com
 Summary:number_format when passed a 0 as first function
 argument, returns null
 Status: Wont fix
 Type:   Bug
 Package:Math related
 Operating System:   Linux 32 bit
 PHP Version:5.3.1
 Block user comment: Y
 Private report: N

 New Comment:

This is a bugs database and not a discussion forum (e.g., hacker news) so 
please treat it as such. Sure it's nice to see all of this 
excitement and interest in the PHP project (patches welcome! :) but let's try 
to be productive and reasonable.

The bug status is Won't fix which means it will not change nor be reverted. 
This report is 2.5 years old. And the current behavior 
exists in both the 5.3 and 5.4 branches.

So while the discussion of this bug veered off course, and frustration was 
shown, please consider putting energy towards other tasks like 
submitting patches and creating RFCs.


Previous Comments:

[2012-06-22 05:41:21] izanagisan at gmail dot com

at so many points in this conversation a little understanding from the 
submitter 
of the bug would have been beneficial. He led the thread into a silly fuss 
instead of making it a search for solutions, even when in his situation there 
was 
little hope he'd get one. Surely Rasmus was the perfect person to help him, if 
he'd just asked kindly instead of proposing the whole PHP development team was 
mad for attempting to standardize the language a bit more

months or no months of changing and testing, he handled this poorly


[2012-06-22 04:20:52] contact at joezimjs dot com

I agree with Endosquid. What you did isn't a bug fix. Whether or not it 
complies with your zend_parse_parameters() nonsense is not the point. A 
function should only return values that make sense for that function to return. 
number_format is supposed to return a string of a number in a specific format. 
NULL is neither a string nor a number.

However, the documentation does dictate that number_format's first parameter is 
supposed to be a float, and it is the programmer's job to supply correct 
parameters to the functions they use. If you supply a string when there should 
be a number, you're doing it wrong.

Sooo, you both fail at your jobs. :D


[2011-08-23 01:41:43] jacob at jacobweber dot com

Fun thread! Anyway, I was wondering if anyone has a complete list of the 
functions 
that changed as a result of this zend_parse_parameters() fix. I don't see 
anything 
specific in the upgrade instructions:
  http://www.php.net/manual/en/migration53.incompatible.php

Also, will number_format((float) $x) behave under PHP 5.3.x exactly the same 
way 
that number_format($x) behaved under PHP 5.2.x? Are there any subtle 
differences?

Thanks.


[2010-01-08 23:47:19] bj...@php.net

Sir.

This issue was recently brought to my attention.
On behalf of PHP I would like to apologize. I see that now that you have been 
treated unfairly.

After carefully reviewing this bug report with our board of directors on 4chan, 
we have come to the conclusion that your rusty C skills should be enough to 
fix the issue.
I would therefore like to remind you that ras...@php.net is 
http://en.wikipedia.org/wiki/Rasmus_lerdorf

Again, I sincerely apologize. We will try to stop fixing bugs in PHP.



[2010-01-08 23:22:52] endosquid at endosquid dot com

Just look in the mirror, pal.

You need classes on how to listen to others.




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

https://bugs.php.net/bug.php?id=50696


-- 
Edit this bug report at https://bugs.php.net/bug.php?id=50696edit=1


Bug #61456 [Opn-Nab]: iconv set encoding bug

2012-03-20 Thread philip
Edit report at https://bugs.php.net/bug.php?id=61456edit=1

 ID: 61456
 Updated by: phi...@php.net
 Reported by:tamate at hotmail dot com
 Summary:iconv set encoding bug
-Status: Open
+Status: Not a bug
 Type:   Bug
 Package:ICONV related
 Operating System:   Linux
 PHP Version:5.3.10
 Block user comment: N
 Private report: N

 New Comment:

You're missing a ; on line #4.


Previous Comments:

[2012-03-20 17:10:36] tamate at hotmail dot com

ICONV related*


[2012-03-20 17:08:01] tamate at hotmail dot com

Line 5*

Live example - http://giantcrabby.com/test/test.php


[2012-03-20 17:02:07] tamate at hotmail dot com

Description:

---
From manual page: http://php.net/manual/en/function.iconv-set-encoding.php
---


Test script:
---
?php
if(function_exists('iconv'))
{
iconv_set_encoding('internal_encoding','UTF-8')
iconv_set_encoding('output_encoding','ISO-8859-1//TRANSLIT//IGNORE');
ob_start('ob_iconv_handler');
}
?

Expected result:

Running successfully

Actual result:
--
If you try the above one, you will get this error - 

Parse error: syntax error, unexpected T_STRING in directory/blah/directory on 
line 3

Pointed at iconv_set_encoding('output_encoding','ISO-8859-1//TRANSLIT//IGNORE');

even if you try iconv_set_encoding('output_encoding','ISO-8859-1');

You will see that you will still get an error.
I am not sure why this is happening, I am running on linux php 5.3

Or is there something wrong with my coding?






-- 
Edit this bug report at https://bugs.php.net/bug.php?id=61456edit=1


Bug #55071 [Opn-Csd]: Change in-built web server description

2011-06-30 Thread philip
Edit report at https://bugs.php.net/bug.php?id=55071edit=1

 ID: 55071
 Updated by: phi...@php.net
 Reported by:s...@php.net
 Summary:Change in-built web server description
-Status: Open
+Status: Closed
 Type:   Bug
 Package:Built-in web server
 Operating System:   Linux
 PHP Version:5.4SVN-2011-06-29 (SVN)
-Assigned To:
+Assigned To:philip
 Block user comment: N
 Private report: N

 New Comment:

Fixed in SVN, thank you for the bug report. ;)


Previous Comments:

[2011-06-30 19:50:57] phi...@php.net

Automatic comment from SVN on behalf of philip
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=312743
Log: Updated name to 'PHP Development Server', and CTRL-C to Ctrl-C, as per PHP 
bug #55071


[2011-06-30 19:12:28] s...@php.net

Also I suggest changing CTRL-C to Ctrl-C or Control-C, as these seem to 
be internet preferred capitalization.


[2011-06-29 17:01:05] s...@php.net

Description:

For the in-built web-server in 5.4, Andi suggested:

I'd change:
Server is listening on localhost:8000... Press CTRL-C to quit.
To something like:
PHP Development Server is listening on localhost:8000... Press CTRL-C to quit. 

Andi's original mail is at http://marc.info/?l=php-internalsm=130309968512464







-- 
Edit this bug report at https://bugs.php.net/bug.php?id=55071edit=1


Bug #45712 [Csd-ReO]: $something == NaN returns true with 5.3, false with 5.2.*

2011-05-25 Thread philip
Edit report at http://bugs.php.net/bug.php?id=45712edit=1

 ID: 45712
 Updated by: phi...@php.net
 Reported by:for-bugs at hnw dot jp
 Summary:$something == NaN returns true with 5.3, false with
 5.2.*
-Status: Closed
+Status: Re-Opened
 Type:   Bug
 Package:Variables related
 Operating System:   *
 PHP Version:5.2CVS, 5.3CVS, 6CVS (2008-08-05)
 Assigned To:tony2001
 Block user comment: N
 Private report: N

 New Comment:

Reopening because the associated test tests INF as well. However, this
is about INF:



// 5.3.7-dev (and all past PHP versions, afaict)

$inf = pow(0,-2); var_dump($inf==$inf); var_dump($inf===$inf); // false
true



// 5.4.0-dev

$inf = pow(0,-2); var_dump($inf==$inf); var_dump($inf===$inf); // true
true



Please explain.



And @jwvdveer, it was indeed fixed (in 5.3) and made to return false.


Previous Comments:

[2010-07-28 01:28:53] jwvdveer at gmail dot com

Please, reopen this bug. It's not working in PHP 5.3.3 on Windows
platform (released at 2010-07-21).

The behaviour of a comparison to NAN is the same as noted here.



It's not just a `me too`, but this thread shouln't have been closed.


[2008-08-07 08:36:33] tony2...@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.




[2008-08-07 07:37:04] tony2...@php.net

I'm testing a patch for it.


[2008-08-05 12:52:06] for-bugs at hnw dot jp

NaN is not exact number. So, NaN should not equals itself. Additionaly,
NaN == NaN is false in C. You can see behavior of C as follows.



$ cat nan.c

int main() {double d;d=(-1e300*1e300)/(1e300*1e300);if (d==d) return 1;
else return 2;}

$ gcc nan.c; ./a.out; echo $?

2

$


[2008-08-05 12:33:17] j...@php.net

That $nan == $nan should be true. (like it is with 5.3)




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/bug.php?id=45712


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


[PHP-BUG] Bug #54224 [NEW]: Sum comutative operation fails with minus on front

2011-03-11 Thread philip dot almeida at freedomson dot com
From: 
Operating system: Linux
PHP version:  Irrelevant
Package:  Math related
Bug Type: Bug
Bug description:Sum comutative operation fails with minus on front

Description:

Making a comutative sum operation the result does not return the expected
value.

Test script:
---
echo -6.3536+5+1.3536;

= -2.22044604925E-16



echo -6.3537+5+1.3537

= 0

Expected result:

Always 0

Actual result:
--
-2.22044604925E-16

-- 
Edit bug report at http://bugs.php.net/bug.php?id=54224edit=1
-- 
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54224r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54224r=trysnapshot53
Try a snapshot (trunk):  
http://bugs.php.net/fix.php?id=54224r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54224r=fixed
Fixed in SVN and need be documented: 
http://bugs.php.net/fix.php?id=54224r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54224r=alreadyfixed
Need backtrace:  
http://bugs.php.net/fix.php?id=54224r=needtrace
Need Reproduce Script:   
http://bugs.php.net/fix.php?id=54224r=needscript
Try newer version:   
http://bugs.php.net/fix.php?id=54224r=oldversion
Not developer issue: 
http://bugs.php.net/fix.php?id=54224r=support
Expected behavior:   
http://bugs.php.net/fix.php?id=54224r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=54224r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=54224r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54224r=globals
PHP 4 support discontinued:  http://bugs.php.net/fix.php?id=54224r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54224r=dst
IIS Stability:   
http://bugs.php.net/fix.php?id=54224r=isapi
Install GNU Sed: 
http://bugs.php.net/fix.php?id=54224r=gnused
Floating point limitations:  
http://bugs.php.net/fix.php?id=54224r=float
No Zend Extensions:  
http://bugs.php.net/fix.php?id=54224r=nozend
MySQL Configuration Error:   
http://bugs.php.net/fix.php?id=54224r=mysqlcfg



Req #50563 [Opn-Csd]: removing E_WARNING from parse_url()

2011-02-07 Thread philip
Edit report at http://bugs.php.net/bug.php?id=50563edit=1

 ID: 50563
 Updated by: phi...@php.net
 Reported by:phi...@php.net
 Summary:removing E_WARNING from parse_url()
-Status: Open
+Status: Closed
 Type:   Feature/Change Request
 Package:*General Issues
 Operating System:   N/A
 PHP Version:5.3.2RC1
-Assigned To:
+Assigned To:philip
 Block user comment: N
 Private report: N

 New Comment:

It does not, as of PHP 5.3.3.


Previous Comments:

[2011-02-07 22:00:13] dan at teton dot com

This is STILL throwing E_WARNING.  Not good.


[2010-06-16 20:56:26] paj...@php.net

Automatic comment from SVN on behalf of pajoye
Revision: http://svn.php.net/viewvc/?view=revisionamp;revision=300501
Log: - #50563, removing E_WARNING from parse_url()


[2010-05-24 16:30:57] phi...@php.net

I don't think the bit fields should be used to hide the warning.


[2010-05-24 15:38:58] ka...@php.net

The following patch has been added/updated:

Patch Name: parse-url-bitfields
Revision:   1274708338
URL:   
http://bugs.php.net/patch-display.php?bug=50563patch=parse-url-bitfieldsrevision=1274708338


[2010-05-24 15:36:44] paj...@php.net

Derick, I don't see why you would change the return value here. Please
explain your reasoning.



However the patch to remove the warning can be applied already, as I
explained on internals.




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/bug.php?id=50563


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


Doc-Req #53712 [Opn]: DateTime::createFromFormat using format ('W') doesn't work

2011-01-26 Thread philip
Edit report at http://bugs.php.net/bug.php?id=53712edit=1

 ID: 53712
 Updated by: phi...@php.net
 Reported by:mpchanzy at proxecom dot fr
 Summary:DateTime::createFromFormat using format ('W')
 doesn't work
 Status: Open
-Type:   Documentation Problem
+Type:   Feature/Change Request
-Package:Translation problem
+Package:Date/time related
 Operating System:   XP Pro
 PHP Version:5.3.5
 Block user comment: N
 Private report: N

 New Comment:

Marking as a datetime feature request.


Previous Comments:

[2011-01-12 18:57:54] altrozero at gmail dot com

This is probably more of a feature request than a bug as 'W' isn't
listed in the 

documentation for DateTime::createFromFormat neither are a few other
characters 

that are supported by date.



You may as well just use the date() function if you wish to use 'W'


[2011-01-11 15:51:28] der...@php.net

W is not part of that list at all—it is not supported. The
documentation also states
http://uk.php.net/manual/en/datetime.createfromformat.php:



The format that the passed in string should be in. See the formatting
options below. In *most cases*, the same letters as for the date() can
be used.



Perhaps you're looking at an outdated translation of the manual? It
looks that the French version of the manual is indeed outdated.


[2011-01-11 11:45:24] mpchanzy at proxecom dot fr

I just changed the title to make it more explicit


[2011-01-11 11:35:29] mpchanzy at proxecom dot fr

Description:

---

From manual page: http://www.php.net/datetime.createfromformat#Liste de
paramètres

---



DateTime::createFromFormat('W','1')

returns false when it should probably return the date of the first week
of the year.



'W' is a date() compatible format

Test script:
---
$date = DateTime::createFromFormat('W','1');



Expected result:

it should return something like this:



public 'date' = string '2011-01-03 10:17:40' (length=19)

  public 'timezone_type' = int 3

  public 'timezone' = string 'UTC' (length=3)



Actual result:
--
false






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


Req #44568 [Com]: class name as defined constant

2010-11-30 Thread philip dot preisser at web dot de
Edit report at http://bugs.php.net/bug.php?id=44568edit=1

 ID: 44568
 Comment by: philip dot preisser at web dot de
 Reported by:andrea at 3site dot it
 Summary:class name as defined constant
 Status: Open
 Type:   Feature/Change Request
 Package:Feature/Change Request
 Operating System:   Windows XP
 PHP Version:5.2.6RC3
 Block user comment: N
 Private report: N

 New Comment:

Test2 Fatal error: Class 'Test2' not found in
/var/www/HTTP/devel/current/frameworld/test.php on line 53


Previous Comments:

[2008-03-30 10:59:12] andrea at 3site dot it

Description:

It seems to be an ambiguity issue and a probable future problem.

You can create a class and define a constant with the same name and
vice-versa.

Who is the class and who is the constant?



For future problems: currently, the magic __toString method works as
magic instance method even if it is declared as public static ( ... and
inherited in instances as public without static ... but this is another
problem ... ) If one day PHP would like to support a public static
__toString method this ambiguity will be a problem to understand if we
are trying to get them, or the possible defined constant.

Reproduce code:
---
class Test{}

define('Test', 123);



// defined('Test') or class_exists('Test') ?







define('Test2', 'Test2');

class Test2{}



get_class(new Test2) === Test2; // true

echo Test2; // Test2

$ref = Test2;

new $ref; // an instanceof Test2 ... 



is_string(Test2); // true

Expected result:

A fatal error, because a constant should be a unique and immutable value
with a name that could not be used as class one and a class should be
unique as well (if we cannot use the same name for two different
classes, how can we have two totally different meaning with a sngle
name, the class and the constant)

Actual result:
--
It is possible to create a class and then define a constant with the
same name, and it is possible to define a constant and then a class with
the same name.






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


Req #52173 [Opn]: ext/pcntl doesn't store/report errors

2010-06-24 Thread philip
Edit report at http://bugs.php.net/bug.php?id=52173edit=1

 ID:   52173
 Updated by:   phi...@php.net
 Reported by:  nick dot telford at gmail dot com
 Summary:  ext/pcntl doesn't store/report errors
 Status:   Open
 Type: Feature/Change Request
 Package:  PCNTL related
 Operating System: Linux
 PHP Version:  trunk-SVN-2010-06-24 (SVN)

 New Comment:

I like option #3.


Previous Comments:

[2010-06-24 16:58:59] nick dot telford at gmail dot com

Minor addendum: A solid use-case as to why it is useful for the userland
code to 

read the error code.



When calling pcntl_wait(), -1 will be returned if there are no child
processes 

running (errno == ECHILD) and also if the call is interrupted by a
signal (errno 

== EINTR).



This makes determining whether there are children left to wait on
tricky, as -1 

could simply be an interrupt from a signal being handled.


[2010-06-24 16:40:37] nick dot telford at gmail dot com

Description:

The following ext/pcntl extensions return -1 on failure, yet have
multiple 

possible reasons for failure: pcntl_fork, pcntl_wait, pcntl_waitpid



Each of these functions can fail for several reasons and in some cases 

(especially wait/waitpid) it is useful for the userland code to be able
to 

handle the different error codes.



The Linux man pages for fork(2) and wait/waitpid(2) all specify that the
error 

code is stored in errno when an error occurs. I only have experience
of the 

System V (Linux) way, so I'm not sure if this is interoperable, although
I 

believe so.



The ext/posix function posix_get_last_error() states that it returns the
error 

code for the last posix function that failed. Internally, all of these
functions 

also use errno to store the error code, but explicitly copy that to
another 

variable, which posix_get_last_error() returns 

(http://lxr.php.net/opengrok/xref/PHP_5_2/ext/posix/posix.c#1167)



I see two possible solutions, either:

 - posix_get_last_error() should be used to return these errors.
Although this 

would add a dependency between the two extensions.

 - An optional parameter, $errno, should be added to pcntl_fork(),
pcntl_wait() 

and pcntl_waitpid() that is populated with errno if the result is -1.

 - A function is added to ext/pcntl, pcntl_get_last_error(), that
operates in a 

similar way to posix_get_last_error().



The third option seems simplest and most compatible, although I can't
help but 

feel these two extensions really belong together as one big happy
family. What's 

the reason they're separate in the first place?

Test script:
---
?php

$pid = pcntl_wait($s);

var_dump($pid, posix_get_last_error());

Expected result:

int(-1)

int(10) # ECHILD

Actual result:
--
int(-1)

int(0)






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


Bug #52018 [Opn-Fbk]: Probable cookie problem with 5.3.2

2010-06-07 Thread philip
Edit report at http://bugs.php.net/bug.php?id=52018edit=1

 ID:   52018
 Updated by:   phi...@php.net
 Reported by:  nospam at nospam dot homelinux dot org
 Summary:  Probable cookie problem with 5.3.2
-Status:   Open
+Status:   Feedback
 Type: Bug
 Package:  HTTP related
 Operating System: Linux Debian 5.0.4
 PHP Version:  5.3.2

 New Comment:

Maybe you can reproduce by isolating the phpBB automatic logon
feature? Do the 

phpBB people have any ideas? I suspect they'd do a more efficient job
finding this 

bug.


Previous Comments:

[2010-06-07 21:47:59] nospam at nospam dot homelinux dot org

Description:

There seems to be a problem with PHP 5.3.2: cookies are not working
properly in some cases, for example when running PhpBB 3.0.5 (and
probably other versions also).



The reason **seems** to be that the $_COOKIE super global variable is
not always populated with received cookies, and the most visible effect
is that the users of my phpBB forum are not able to use the “automatic
logon” feature of phpBB.



However, a simple test case with the setcookie function works properly,
so I don’t know exactly what kind of cookie can trigger the bug.



Downgrading to phpBB 5.2.13 or lower effectively fix the problem.



I made multiple tries, using either 5.2.6, 5.2.13 or 5.3.2, either
compiled by myself or installed from Debian packages, with or without
the Debian security patches, while keeping the same php.ini
configuration in all cases, and the result was always the same:

- with 5.2.6 or 5.2.13, cookies are handled properly, and phpBB users
can use the phpBB's automatic “automatic logon” feature.

- with 5.3.2, cookies seem to be blocked, $_COOKIE is not populated
(except maybe by as many empty strings as the number of expected
cookies).



The server also uses Apache 2.2.9 and MySQL 5.1.46, and I tried on two
different Debian 5.0.4 configurations, one as 32 bits at my home and one
as 64 bits in a datacenter.



I used Wireshark for network sniffing, so I can tell that cookies are
truely present in HTTP headers.



I tracked the $_COOKIE variable by adding a error_log(print_r($_COOKIE,
true)) instruction near the beginning of the phpBB common code.

Test script:
---
I'm sorry, I don't know how to make a short test script showing the
problem. I tried a short test with setcookie but it worked properly,
even with 5.3.2. I suppose that there are some combined interactions
within phpBB triggering this problem when they happen altogether.



The only procedure that I can suggest is the following:



- Install a phpBB server (download from http://www.php.net/) with the
default configuration.

- Create a user account with any name.

- Try to login on this account. Don't forget to check the Log me on
automatically each visit option when login.

- Browse a little inside the forum, check that the connexion is kept by
session ID.

- Quit your browser, closing all of its Windows.

- Reopen the browser, and open again the phpBB forum. Use the root
address of the forum, without the session ID parameter.



Expected result:

When opening the forum homepage, login should be already made, kept from
previous session.

This is what happens with 5.2.6 or 5.2.13.



Actual result:
--
Forum open correctly, but previous login is completely forgotten.

This is what happens with 5.3.2.






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


Bug #36073 [Wfx-Opn]: Source-compiled MySQL on x86_64 causes PHP configure failure

2010-06-06 Thread philip
Edit report at http://bugs.php.net/bug.php?id=36073edit=1

 ID:   36073
 Updated by:   phi...@php.net
 Reported by:  chris at spawnordie dot com
 Summary:  Source-compiled MySQL on x86_64 causes PHP configure
   failure
-Status:   Wont fix
+Status:   Open
 Type: Bug
-Package:  Compile Failure
+Package:  MySQL related
 Operating System: Linux/Any
-PHP Version:  5.1.2
+PHP Version:  5.3.2

 New Comment:

Looks like a bug.


Previous Comments:

[2010-06-06 02:29:11] everyminutepies at yahoo dot ca

I can confirm that this does in fact still happen with PHP 5.3.2 on
CentOS 5.5 86_64 when compiling MySQL 5.0.xx and PHP on a standard
installation. Despite being told by the configuration option
--with-libdir=lib64 to use lib64/ it still chooses to use lib/ and fails
to find the necessary files to continue with the ./configure.







The posted workaround by Chris does work flawlessly. I invite the
reviewer to explain either why the documentation is incorrect about the
function of --with-libdir or why it is not respected in regards to mysql
at his leisure. 



Trustfully, I agree not to become enraged when he suggests I know
nothing about computers and post an enraged rant about him in the year
2014.







./configure  --prefix=/usr/local/secure/php
--with-apxs2=/usr/local/secure/apache2/bin/apxs
--with-mysql=/usr/local/mysql/ --with-libdir=lib64


[2010-03-25 23:16:19] chris at spawnordie dot com

Other than the bug reviewer just being a flat-out ass...



It is still a bug in PHP.  The PHP configure process honors the
--with-libdir 

value for PostgreSQL and many, many other packages, but NOT for its
check of 

MySQL.  It is NOT a bug in MySQL, which installs its libraries in lib64,
just 

like every other application that is compiled for 64bit OS.  But PHP
somehow 

magically knows how to find all of those other applications.  At the
very 

least, it is an inconsistency that could have been cleaned up with 15
minutes of 

effort by the PHP team when I reported the bug 4 years ago!



And, based on the fact that I provided a work-around, it should have
been clear 

that I did, in fact, know what I was doing.  Maybe my feelings were a
little 

hurt, but there's no excuse for the rudeness this bug reviewer showed. 
I 

sincerely hope that he/she is no longer in that role -- or doing
anything that 

requires using any level of tact with actual people -- because he/she is
just a 

jerk and is in serious need of therapy.  Maybe he/she didn't get hugged
as a 

child and is displaying a superiority complex to cover up low
self-esteem and 

fear of being hurt.  But I digress.


[2010-03-25 18:32:22] michael at michaelsnet dot us

IMHO this is a documentation bug.  Consider adding a README.64bit file
containing this information and other relevant information.


[2006-01-18 23:53:50] sni...@php.net

Works fine for me.

Hint: Don't try building Mysql yourself if you don't know how to do it
properly. Use the binary packages provided by MySQL.

And last but not least: report this to MySQL. It's not our fault if they
do things wrong.


[2006-01-18 22:14:10] chris at spawnordie dot com

Description:

Please accept my apologies if this is already reported - I searched and
didn't find it.



When configuring PHP for x86_64, it is necessary to use:

--with-libdir=lib64



When you compile MySQL from source, it does not place its files in
lib64, but rather lib.



MySQL was configured using:

--prefix=/usr/local/mysql



Configuring PHP using:

--with-mysql=/usr/local/mysql

fails with this:

checking for MySQL support... yes

checking for specified location of the MySQL UNIX socket... no

checking for MySQL UNIX socket location... no

configure: error: Cannot find libmysqlclient under /usr/local/mysql.

Note that the MySQL client library is not bundled anymore!



This fixes the problem:

cd /usr/local/mysql

ln -s lib lib64



When PHP is configured using --with-mysql=mysql_dir and
--with-libdir=lib_dir, it should search mysql_dir/lib_dir and then
mysql_dir/lib

Reproduce code:
---
./configure --with-mysql=path/to/mysql when MySQL is compiled from
source code

Expected result:

successful configure

Actual result:
--
configure fails with:

checking for MySQL support... yes

checking for specified location of the MySQL UNIX socket... no

checking for MySQL UNIX socket location... no

configure: error: Cannot find libmysqlclient under /usr/local/mysql.

Note that the MySQL client library is not bundled anymore!





Req #50563 [Opn]: removing E_WARNING from parse_url()

2010-05-24 Thread philip
Edit report at http://bugs.php.net/bug.php?id=50563edit=1

 ID:   50563
 Updated by:   phi...@php.net
 Reported by:  phi...@php.net
 Summary:  removing E_WARNING from parse_url()
 Status:   Open
 Type: Feature/Change Request
 Package:  *General Issues
 Operating System: N/A
 PHP Version:  5.3.2RC1

 New Comment:

I don't think the bit fields should be used to hide the warning.


Previous Comments:

[2010-05-24 15:38:58] ka...@php.net

The following patch has been added/updated:

Patch Name: parse-url-bitfields
Revision:   1274708338
URL:   
http://bugs.php.net/patch-display.php?bug=50563patch=parse-url-bitfieldsrevision=1274708338


[2010-05-24 15:36:44] paj...@php.net

Derick, I don't see why you would change the return value here. Please
explain your reasoning.



However the patch to remove the warning can be applied already, as I
explained on internals.


[2010-05-24 15:18:53] ka...@php.net

I did a quick and dirty patch to turn the $component into a bitfield

allowing you to do:

$url = parse_url('http://www.php.net/manual/', PHP_URL_HOST |
PHP_URL_PATH);

printf('%s%s', $url['host'], $url['path']);



At the same point I figured we could disable the warning and therefore

I added a new constant named PHP_URL_SILENT:

$broken_url = 'http:///www.php.net/';

var_dump(parse_url($broken_url), parse_url($broken_url,
PHP_URL_SILENT));



It doesn't alter the actual URL parser code to tell why the parsing

failed, but it kills two flies in one hit. Ofcourse the silent option

can be skipped, but while atleast updating parse_url().



The patch uploaded here does not currently fix any broken tests.



Theres a minor BC break, since it changes the values of the constants,

but it can be fixed by changing the checking code, or the dirty way to

increase the values so they don't conflict with the old ones.


[2009-12-23 16:57:14] der...@php.net

Actually, it should allow for returning *why* the parsing failed as
well. Assigning to myself.


[2009-12-23 16:52:58] phi...@php.net

Description:

parse_url() does not need to emit an E_WARNING upon failure, as instead


it returns false. Doing both basically requires people to use @.







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


Bug #51857 [Opn-Ver]: deleteName() for directories returns True on non-success

2010-05-21 Thread philip
Edit report at http://bugs.php.net/bug.php?id=51857edit=1

 ID:   51857
 Updated by:   phi...@php.net
 Reported by:  nuabaranda at web dot de
 Summary:  deleteName() for directories returns True on
   non-success
-Status:   Open
+Status:   Verified
 Type: Bug
 Package:  Zip Related
 Operating System: Linux 2.6.27
-PHP Version:  5.2.13
+PHP Version:  5.3.3-dev

 New Comment:

And for good measure:



?php

define ('FILEPATH_ZIPFILE', '/tmp/test.zip');



/* Create the Zip file */

$zip = new ZipArchive;

if ($zip-open(FILEPATH_ZIPFILE, ZIPARCHIVE::CREATE) === TRUE) {



$zip-addFromString('foo.txt', 'foo');

$zip-addFromString('bar.txt', 'bar');

$zip-addEmptyDir('EmptyDirectory');

$zip-addEmptyDir('FullDirectory');

$zip-addFromString('FullDirectory/baz.txt', 'baz');

$zip-close();

}



/* Mess with the Zip file */

$zip = new ZipArchive;

if ($zip-open(FILEPATH_ZIPFILE) === TRUE) {



/* Fails to delete */

$r1 = $zip-deleteName('EmptyDirectory');



/* Successful delete (note the appended '/' */

$r2 = $zip-deleteName('EmptyDirectory/');



/* Fails to delete */

$r3 = $zip-deleteName('FullDirectory');



/* Fails to delete, although returns true */

$r4 = $zip-deleteName('FullDirectory/');



$zip-close();

}



/* Display the Zip file contents */

$zip = new ZipArchive;

if ($zip-open(FILEPATH_ZIPFILE) === TRUE) {



echo 'File count: ', $zip-numFiles, PHP_EOL;

echo 'Status: ', $zip-status, PHP_EOL;



for ($i = 0; $i  $zip-numFiles; $i++) {

$stat = $zip-statIndex($i);

echo 'Index: ', $i, ' ', $stat['name'], PHP_EOL;

}



$zip-close();

}



var_dump(

array('r1' = $r1, 'r2' = $r2, 'r3' = $r3, 'r4' = $r4)

);



Returns:



File count: 3

Status: 0

Index: 0 foo.txt

Index: 1 bar.txt

Index: 2 FullDirectory/baz.txt

array(4) {

  [r1]=

  bool(false)

  [r2]=

  bool(true)

  [r3]=

  bool(false)

  [r4]=

  bool(true)

}


Previous Comments:

[2010-05-19 09:43:27] nuabaranda at web dot de

Description:

When trying to delete a non-empty directory in a ZIP file with
deleteName() the function will return True and not delete the directory
if it is not empty. Expectation would be to return False if the
directory can not be deleted.



Also the directory handling should be better documentated (usage of
trailing slashes, examples).

Test script:
---
$zip = new ZipArchive;

if( $zip-open('archive.zip', ZipArchive::CREATE) ) {

  $zip-addEmptyDir('folder');

  $zip-addFile('folder/file.txt');

  if( ! $zip-deleteName('folder/') ) {

echo 'Should end up here if folder not deletable';

  }

}

$zip-close();

Expected result:

Should echo.

Actual result:
--
Will not echo.






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


Bug #51791 [Bgs-Opn]: constant() failed to check undefined constant and php interpreter stoped

2010-05-12 Thread philip
Edit report at http://bugs.php.net/bug.php?id=51791edit=1

 ID:   51791
 Updated by:   phi...@php.net
 Reported by:  iliavlad at mail dot ru
 Summary:  constant() failed to check undefined constant and php
   interpreter stoped
-Status:   Bogus
+Status:   Open
 Type: Bug
 Package:  Reproducible crash
 Operating System: Windows, Linux
 PHP Version:  5.3.2

 New Comment:

I don't see this change mentioned at any of the following locations:

 - http://php.net/php5news

 - http://php.net/migration53

 - http://php.net/function.constant



Therefore, it can't be completely bogus. Please explain if this BC break
in 5_3 

is intentional. constant('IDONOTEXIST') still returns NULL however, with


E_WARNING instead of E_FATAL.


Previous Comments:

[2010-05-13 00:09:29] iliavlad at mail dot ru

Hi Mike,



according to manual http://php.net/manual/en/function.constant.php
constant() eturns the value of the constant, or NULL if the constant is
not defined. And this happens with php 5.2 version. With php 5.3 there
is a fatal error and php interpreter stops. There are no words about
fatal error in manual.


[2010-05-12 08:16:15] m...@php.net

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php




[2010-05-11 12:12:45] iliavlad at mail dot ru

Description:

constant() failed to check undefined constant and php interpreter
stoped, but constant() should return NULL and php interpreter should
continue to work.

Test script:
---
class A 

{

const B = 1;

}

var_dump(constant('A::B1'));

echo 5;



Expected result:

Warning: constant(): Couldn't find constant A::B1

NULL

5

Actual result:
--
php -v 

PHP 5.3.2 (cli) (built: Mar 3 2010 19:40:13) 

Copyright (c) 1997-2010 The PHP Group 

Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies 



php -r class A { const B = 1;} var_dump(@constant('A::B1')); echo 5;




php -r class A { const B = 1;} var_dump(constant('A::B1')); echo 5; 



Fatal error: Undefined class constant 'A::B1' in Command line code on
line 1 



Call Stack: 

0.0003 317608 1. {main}() Command line code:0 

0.0003 317688 2. constant() Command line code:1






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


Bug #48498 [Opn-Ver]: COM object instantiation throws 'Invalid Syntax' exception

2010-04-11 Thread philip
Edit report at http://bugs.php.net/bug.php?id=48498edit=1

 ID:   48498
 Updated by:   phi...@php.net
 Reported by:  will at flourishlib dot com
 Summary:  COM object instantiation throws 'Invalid Syntax'
   exception
-Status:   Open
+Status:   Verified
 Type: Bug
 Package:  COM related
 Operating System: Windows XP SP3
 PHP Version:  5.2.10RC1

 New Comment:

Please let us know when Capicom is (or is not) available because I have
a fresh XP 

install here, with a new PHP 5.3.2 install, and am also getting Failed
to create 

COM object 'CAPICOM.Utilities.1': Invalid syntax


Previous Comments:

[2009-11-03 21:29:36] ksin...@php.net

I was able to use CapiCom.Utilities.1 with PHP 5.2.11. Error is
generated when capicom is not registered and class is not available on
the machine.


[2009-06-27 00:11:06] paul at mantisforge dot org

This functionality seems to work fine in the 5.3.0 rc builds ( PHP 

5.3.0RC5-dev (cli) (built: Jun 27 2009 00:33:01) (DEBUG)).



The following script appears to work for me against most of the 

capicom.utilities functions: 



?php 



try {

$util = new COM('CAPICOM.Utilities.1');

} catch (Exception $e) {

echo $e-getMessage() . \n;

echo 'exception initialising com object... terminating...';

}



$string = 'foo';



$encoded = $util-Base64Encode($string); /* encoded string is \r\n 

terminated */

echo $encoded . ' is base 64 encoded string:' . $util-

Base64Decode($encoded) . \n;

echo \n\n;



$hex = $util-BinaryToHex($string);

echo BinaryToHex:  . $util-BinaryToHex($string) . \n;

echo hextobinary:  . $util-HexToBinary($hex) . \n;

define( 'CAPICOM_ENCODE_BASE64', 0 );



echo Random Number:  . $util-GetRandom(10, CAPICOM_ENCODE_BASE64) . 

\n;



$variant = $util-BinaryStringToByteArray($string);

$i = 0;

foreach( $variant as $v) {

 echo Byte( . $i++ . ):  . $v . \n;

}





Outputing:

ZgBvAG8A

 is base 64 encoded string:foo



BinaryToHex: 66006F006F00

hextobinary: foo

Random Number: PiMSnPtckiHFCQ==



Byte(0): 102

Byte(1): 0

Byte(2): 111

Byte(3): 0

Byte(4): 111

Byte(5): 0



--



1) It might be worth trying a newer version of php

2) it might be worth checking that the com object is registered 

correctly by attempting to access it from a vbscript


[2009-06-08 18:05:57] will at flourishlib dot com

Description:

In previous versions of PHP it was possible to create a COM object for
CAPICOM to generate random data. I'm not sure at what version it broke,
but now trying to instantiate the COM object, an exception is thrown
with the message Failed to create COM object 'CAPICOM.Utilities.1':
Invalid syntax.



This behavior seem to be present on both 5.2.9-2 and 5.2.10RC1.



I've been unable to figure out what this error really means. The ProgID
I'm specifying is valid according to Microsoft -
http://msdn.microsoft.com/en-us/library/aa388176(VS.85).aspx.



Any sort of direction would be useful in trying to solve this issue.

Reproduce code:
---
new COM('CAPICOM.Utilities.1');

Expected result:

A COM object that can be used.

Actual result:
--
An exception with the message:

Failed to create COM object 'CAPICOM.Utilities.1': Invalid syntax






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


Bug #50562 [Opn-Csd]: FILTER_VALIDATE_URL is broken

2010-03-31 Thread philip
Edit report at http://bugs.php.net/bug.php?id=50562edit=1

 ID:   50562
 Updated by:   phi...@php.net
 Reported by:  phi...@php.net
 Summary:  FILTER_VALIDATE_URL is broken
-Status:   Open
+Status:   Closed
 Type: Bug
 Package:  Filter related
 Operating System: N/A
 PHP Version:  5.3.2RC1
-Assigned To:  
+Assigned To:  rasmus

 New Comment:

Rasmus fixed this bug in SVN.

- http://svn.php.net/viewvc?view=revisionrevision=297250


Previous Comments:

[2009-12-23 16:41:06] phi...@php.net

Description:

While attempting to use FILTER_VALIDATE_URL, I notice it gets negative 

press. Here's one such piece of press:



http://www.talkincode.com/php-filter-filter_validate_url-limitations-

124.html



Ideally FILTER_VALIDATE_URL would behave as most would expect, and 

that's checking if an URL is valid... as most people do with long-ish 

regular expressions.



Please also provide tips for how this should be documented. 







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


Bug #51436 [Opn]: LCG entropy fix insufficient, uniqid leaks entropy, leads to weak session IDs

2010-03-30 Thread philip
Edit report at http://bugs.php.net/bug.php?id=51436edit=1

 ID:   51436
 Updated by:   phi...@php.net
 Reported by:  andreas at andreas dot org
 Summary:  LCG entropy fix insufficient, uniqid leaks entropy,
   leads to weak session IDs
 Status:   Open
 Type: Bug
 Package:  *Encryption and hash functions
 Operating System: all
 PHP Version:  5.3.2

 New Comment:

Regarding session.entropy_file and session.entropy_length, please
clarify this 

topic a bit and ideally include an example for Windows users. I see
words like 

ksecdd.sys and CryptoAPI but am unsure how these might apply to 

session.entropy_file.



And, what are the downsides of using these options... performance?


Previous Comments:

[2010-03-30 20:19:27] paj...@php.net

On a related note, we should document session.entropy-file in a better
way. Maybe this page should be a good place to inform the users about
this setting and why it should always be used:



http://www.php.net/manual/en/session.installation.php



Thanks Rasmus for the notice.


[2010-03-30 12:38:31] andreas at andreas dot org

Description:

PHP utilizes a cryptographically weak random number generator to produce
session ID information.  Additionally, not enough entropy is used for
the initial seeding of the RNG, and some of the entropy can leak by
careless use of the uniqid() PHP function.  Under certain circumstances,
these individual weaknesses interact and reduce the number of possible
values of a PHP session ID so much that exhaustive search for a valid
session ID against the web server becomes feasible.



I suggest to make sure that a cryptographically secure RNG is used for
session ID generation, sufficient entropy is used to seed the RNG, and
to change the uniqid() function to always return a hashed value.



A complete discussion of why I think the code is vulnerable, including
estimates on the attack effort, is available from
http://berlin.ccc.de/~andreas/php-entropy-advisory.txt







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


Bug #51436 [Opn]: LCG entropy fix insufficient, uniqid leaks entropy, leads to weak session IDs

2010-03-30 Thread philip
Edit report at http://bugs.php.net/bug.php?id=51436edit=1

 ID:   51436
 Updated by:   phi...@php.net
 Reported by:  andreas at andreas dot org
 Summary:  LCG entropy fix insufficient, uniqid leaks entropy,
   leads to weak session IDs
 Status:   Open
 Type: Bug
 Package:  *Encryption and hash functions
 Operating System: all
 PHP Version:  5.3.2

 New Comment:

As for these session.entropy directives, due to compatibility issues I'm
unsure 

how best to include these recommended values in php.ini-* so the
following 

patch[1] adds information where appropriate, although it does not change
the 

default values. One trouble: it breaks convention, as other directives
are in 

fact changed (and not only recommended). This patch only solves this bug
through 

documentation, which may or may not be our ultimate solution.



We still need to discuss whether changing the default php.ini-* values
is 

appropriate, and the potential impact (e.g. Windows) it would have. And
of 

course explore alternative options that essentially don't require 

/dev/urandom. Like, Rasmus/Scott mentioned something about using
OpenSSL's 

existing abstraction layer to do it.



And lastly, while documenting we should describe:

- Briefly mention the difference between /dev/urandom and /dev/random

- Talk about performance issues

- Alternatives to /dev/random (e.g. EGD, hardware, ...)

- Mention which Operating Systems lack /dev/random (Windows, and Solaris
8 and 

below come to mind)



[1] Patch name: session_entropy_docs_php_ini_default_off_still


Previous Comments:

[2010-03-31 04:43:27] phi...@php.net

The following patch has been added/updated:

Patch Name: session_entropy_docs_php_ini_default_off_still
Revision:   1270003407
URL:   
http://bugs.php.net/patch-display.php?bug=51436patch=session_entropy_docs_php_ini_default_off_stillrevision=1270003407


[2010-03-31 01:08:13] phi...@php.net

Regarding session.entropy_file and session.entropy_length, please
clarify this 

topic a bit and ideally include an example for Windows users. I see
words like 

ksecdd.sys and CryptoAPI but am unsure how these might apply to 

session.entropy_file.



And, what are the downsides of using these options... performance?


[2010-03-30 20:19:27] paj...@php.net

On a related note, we should document session.entropy-file in a better
way. Maybe this page should be a good place to inform the users about
this setting and why it should always be used:



http://www.php.net/manual/en/session.installation.php



Thanks Rasmus for the notice.


[2010-03-30 12:38:31] andreas at andreas dot org

Description:

PHP utilizes a cryptographically weak random number generator to produce
session ID information.  Additionally, not enough entropy is used for
the initial seeding of the RNG, and some of the entropy can leak by
careless use of the uniqid() PHP function.  Under certain circumstances,
these individual weaknesses interact and reduce the number of possible
values of a PHP session ID so much that exhaustive search for a valid
session ID against the web server becomes feasible.



I suggest to make sure that a cryptographically secure RNG is used for
session ID generation, sufficient entropy is used to seed the RNG, and
to change the uniqid() function to always return a hashed value.



A complete discussion of why I think the code is vulnerable, including
estimates on the attack effort, is available from
http://berlin.ccc.de/~andreas/php-entropy-advisory.txt







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


#50348 [Opn]: FDF not on PECL's site as stated

2009-11-30 Thread philip
 ID:   50348
 Updated by:   phi...@php.net
 Reported By:  kevin at icscomp dot com
 Status:   Open
-Bug Type: Documentation problem
+Bug Type: FDF related
 Operating System: N/A
 PHP Version:  5.3.1
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

There are several extensions that get moved from core into PECL but
lack 
a page at pecl.php.net. However, this one (FDF) isn't even in SVN so 
this is a bug. This extension was deleted and not moved, whereas NEWS 
says it was moved.

- http://cvs.php.net/viewvc.cgi/php-src/ext/fdf/?hideattic=0

However, nothing here:

- http://cvs.php.net/viewvc.cgi/pecl/
- http://svn.php.net/viewvc/pecl/

Assigning to Pierre.


Previous Comments:


[2009-12-01 02:43:36] kevin at icscomp dot com

Description:

On this page: http://php.net/releases/5_3_0.php  it states the
following:

¡Moved the following extensions to PECL: ext/ming, ext/fbsql,
ext/ncurses, ext/fdf.

The fdf extension is no where to be found on the PECL website, and the
link points to Adobe website, but doesn't give you a clue where to find
the appropriate files, nor how to install them on your PHP
installation.

I have even tried using the previous php_fdf.dll and fdftk.dll from my
previous installation, but it doesn't seem to recognize that they are
there even after adding extension=php_fdf.dll to the php.ini.  

I would be satisfied just to have the functionality back, but am at a
loss as to how to do this now.  HELP!

Expected result:

A working FDF functionality with instructions on how to install it.

Actual result:
--
No working FDF available.  No documentation on how to implement FDF
with PHP.





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



#50330 [Opn-Bgs]: ( == NULL) == TRUE ?! (and all other empty values)

2009-11-30 Thread philip
 ID:   50330
 Updated by:   phi...@php.net
 Reported By:  wdolek at gmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Feature/Change Request
 Operating System: GNU/Linux
 PHP Version:  5.2.11
 New Comment:

This will never change.

- http://www.php.net/manual/en/types.comparisons.php

It is what it is.


Previous Comments:


[2009-11-30 10:23:04] wdolek at gmail dot com

Description:

when comparing empty string, empty array, FALSE, integer 0 with NULL,
comparison always returns TRUE. but imho empty string, FALSE or 0 are
still any values, instead of NULL is no value.
of course, i can use === but documentation says equals - isn't is
little bit confusing to check also type, when NULL has no type?

in whatever programming lanugage, NULL is NULL and not anything else,
don't know, why PHP behaves differently

Reproduce code:
---
// should be array(), 0, FALSE etc. instead of ''

if ('' == NULL) {
 echo 'hey dummy, empty string should not be NULL!';
} else {
 echo 'yeah, empty string is not NULL at all!';
}

Expected result:

yeah, empty string is not NULL at all!

Actual result:
--
hey dummy, empty string should not be NULL!





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



#50222 [Bgs]: can't disable magic_quotes_gpc support

2009-11-19 Thread philip
 ID:   50222
 Updated by:   phi...@php.net
 Reported By:  carlo dot mendola at gmail dot com
 Status:   Bogus
 Bug Type: *Configuration Issues
 Operating System: mac os x 10.6 snow leopard
 PHP Version:  5.3.0
 New Comment:

Basically this is saying that PHP is looking for /etc/php.ini but not 
finding it. 

And it's looking for php.ini not php.ini-default. So, rename it, then 
restart the web server...


Previous Comments:


[2009-11-19 09:34:02] carlo dot mendola at gmail dot com

1) the php.ini that were you referring to are the same php.ini.default
i 
found in /etc or there is another one to modify?

2) my php.ini.default has already magic_quotes_gpc disabled as you can

see in my previous post.
   magic_quotes_gpc = Off
what else am i supposed to do to disable magic_quotes_gpc?

3) my phpinfo() report tells (none) as you can see beneath 
Configuration File (php.ini) Path   /etc
Loaded Configuration File   (none)
Scan this dir for additional .ini files (none)
Additional .ini files parsed(none)

Could it be related to my problem?



[2009-11-19 08:36:56] j...@php.net

So turn it off in php.ini and you're done.



[2009-11-18 23:21:53] carlo dot mendola at gmail dot com

Description:

i got a problem with mysql_real_escape_string because of this 
assignment:

$myvar=mysql_real_escape_string($_POST['key']);

the value in $_POST['key'] contains a string already escaped.
I think it might be due to magic_quotes_gcp settings.

the phpinfo() tells that magic_quotes_gpc is On for both master and 
local value.

The php.ini.default has the following settings:
; magic_quotes_gpc
;   Default Value: On
;   Development Value: Off
;   Production Value: Off
magic_quotes_gpc = Off
magic_quotes_runtime = Off
magic_quotes_sybase = Off








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



#37177 [NoF-Bgs]: with-libxml option in ./configure ignored

2009-10-03 Thread philip
 ID:   37177
 Updated by:   phi...@php.net
 Reported By:  mhalligan at bitpusher dot com
-Status:   No Feedback
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: SuSE Linux Enterprise 9 SP3
 PHP Version:  5.1.2
 New Comment:

I believe this problem is bogus, although initially I did suffer its 
wrath. Today I added some documentation that may help:

http://svn.php.net/viewvc?view=revisionrevision=289134

In short: If PHP cannot find bin/xml2-config in the directory specified

by --with-libxml-dir, it'll continue on and check the default
locations.  
So for those suffering from this issue, keep that in mind, and ensure 
xml2-config exists there. For those using packages/RPMs, ensure the
-dev 
version is installed too.

See also: http://php.net/libxml.installation

Status change: NoFeedback-Bogus


Previous Comments:


[2006-05-02 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2006-04-24 10:28:13] tony2...@php.net

Did you try the snapshot?
Yes, I can successfully configure and compile it even without libxml2
installed in the system.



[2006-04-24 10:11:46] mhalligan at bitpusher dot com

Do you already have libxml2 installed? I have the normal 
libxml2 isntallation on my servers that come with suse. I can 
compile fine if I remove them, however, if I don't, PHP's 
configure always finds /usr/sbin/xml-config first.



[2006-04-24 10:03:44] tony2...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.1-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.1-win32-latest.zip


What am I doing wrong?

# ./configure --disable-all --enable-xml --with-libxml-dir=/tmp/libxml
--enable-libxml | grep xml
checking libxml2 install dir... /tmp/libxml
checking for xml2-config path... /tmp/libxml/bin/xml2-config
checking whether libxml build works... yes
checking for xml2-config path... (cached) /tmp/libxml/bin/xml2-config
checking whether libxml build works... (cached) yes





[2006-04-24 09:51:29] mhalligan at bitpusher dot com

Ignore the ../php-build.sh: line 3: --with-openssl: command not
found
section, that was me cutting and pasting from an older session. It has
absolutely nothing to do with the fact that php's ./configure script
is
rather broken.



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

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



#49503 [NoF-Opn]: failed to open semaphore file

2009-09-29 Thread philip
 ID:   49503
 Updated by:   phi...@php.net
 Reported By:  mike at fuelsaver-mpg dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: Session related
 Operating System: Linux 2.6.9-023stab048.6-enterpr
 PHP Version:  5.2.10
 New Comment:

There was some feedback, status-open.


Previous Comments:


[2009-09-18 23:18:37] jd at cpanel dot net

Sorry about the multiple comments.  bugs.php.net seemed to be having
some problems when I submitted them.



[2009-09-18 23:09:22] jd at cpanel dot net

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 5.2.9 and 5.2.10 that makes the difference is the
warning added in revision 280733:

 r...@jd:/usr/local/svn/php/PHP_5_2# svn log -r280733 --verbose

r280733 | jani | 2009-05-18 12:23:42 -0500 (Mon, 18 May 2009) | 2
lines
Changed paths:
   M /php/php-src/branches/PHP_5_2/ext/session/mod_files.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
   M /php/php-src/branches/PHP_5_2/ext/session/mod_user.c
   M /php/php-src/branches/PHP_5_2/ext/session/php_session.h
   M /php/php-src/branches/PHP_5_2/ext/session/session.c

MFH: Sync WS / CS changes where applicable




It's not really clear why the warning was added to the 5.2 branch
though, since it doesn't look like it was added to trunk or 5.3 in
revisions 280729 and 280728.

svn diff
http://svn.php.net/repository/php/php-src/branches/PHP_5_2/ext/session/mod_mm.c
http://svn.php.net/repository/php/php-src/trunk/ext/session/mod_mm.c



[2009-09-18 22:48:33] jd at cpanel dot net

Still present in 5.2.11.

This looks like it's identical to bugs 49401, 49427 and 49433 which
were incorrectly marked as bogus.

This happens when the mm session module tries to initialize itself. 
You don't need anything configured to use MM to hit the problem.  As
this particular bug illustrates, even a valid session.save_path setting
wont avoid running into the same spurious warning.

Ex:

j...@jd:~$ /usr/local/bin/php -i | grep -i session
PHP Warning:  PHP Startup: mm_create(0, /session_mm_cli32004) failed,
err mm:core: failed to open semaphore file (Permission denied) in
Unknown on line 0
session
Session Support = enabled
session.auto_start = Off = Off
session.bug_compat_42 = On = On
session.bug_compat_warn = On = On
session.cache_expire = 180 = 180
session.cache_limiter = nocache = nocache
session.cookie_domain = no value = no value
session.cookie_httponly = Off = Off
session.cookie_lifetime = 0 = 0
session.cookie_path = / = /
session.cookie_secure = Off = Off
session.entropy_file = no value = no value
session.entropy_length = 0 = 0
session.gc_divisor = 100 = 100
session.gc_maxlifetime = 1440 = 1440
session.gc_probability = 1 = 1
session.hash_bits_per_character = 4 = 4
session.hash_function = 0 = 0
session.name = PHPSESSID = PHPSESSID
session.referer_check = no value = no value
session.save_handler = files = files
session.save_path = no value = no value
session.serialize_handler = php = php
session.use_cookies = On = On
session.use_only_cookies = Off = Off
session.use_trans_sid = 0 = 0
WDDX Session Serializer = enabled


The change between 

#49332 [Asn]: Make fails with Undefined symbols: _res_9_dn_expand, _res_9_search and _res_9

2009-09-26 Thread philip
 ID:   49332
 Updated by:   phi...@php.net
 Reported By:  vizh at me dot com
 Status:   Assigned
 Bug Type: Compile Failure
 Operating System: Mac OS X 10.6 (10A432)
 PHP Version:  5.2.10
 Assigned To:  scottmac
 New Comment:

Another temp fix: Add -lresolv to EXTRA_LIBS in the generated MakeFile.

See also: http://bit.ly/SJ3YQ


Previous Comments:


[2009-09-07 05:18:55] tmallen at 703designs dot com

Here's a temporary fix: http://trac.macports.org/ticket/19997



[2009-08-26 00:51:27] djem dot v3 at gmail dot com

Since php 5.3 has been preinstalled in Snow Leopard, it is very 
important to have php 5.2 in system.



[2009-08-24 14:43:24] j...@php.net

I would guess Scott meant PHP_5_2 branch.. :)



[2009-08-23 11:31:11] scott...@php.net

This is fixed in 5.3.1-dev, I'll look into backporting changes to the
5.3 branch.



[2009-08-23 03:31:54] vizh at me dot com

Description:

I've download http://snaps.php.net/php5.2-latest.tar.gz, runs 
./configure; make and make fails with undefined symbols: 
_res_9_dn_expand, _res_9_search and _res_9_dn_skipname

Reproduce code:
---
cd /tmp
curl http://snaps.php.net/php5.2-latest.tar.gz;  php.tar.gz
tar -xf php.tar.gz; rm -rf php.tar.gz; mv php* php-build; cd php-build
./configure --disable-all
make

Actual result:
--
Undefined symbols:
  _res_9_search, referenced from:
  _zif_dns_get_mx in dns.o
  _zif_dns_check_record in dns.o
  _res_9_dn_expand, referenced from:
  _zif_dns_get_mx in dns.o
  _res_9_dn_skipname, referenced from:
  _zif_dns_get_mx in dns.o
  _zif_dns_get_mx in dns.o





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



#48885 [Csd-Fbk]: finfo returns mime type + charset when FILEINFO_MIME is used

2009-07-26 Thread philip
 ID:   48885
 Updated by:   phi...@php.net
 Reported By:  majkl578 at gmail dot com
-Status:   Closed
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: Linux Debian
 PHP Version:  5.3.0
 New Comment:


Which version of libmagic changed this? It should be added to the docs.


Also, the docs don't mention how to link to libmagic nor mention that a

bundled version is used [by default]. What's the situation? The only 
option I see with './configure --help' is --disable-fileinfo ...


Previous Comments:


[2009-07-27 03:16:33] s...@php.net

Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revisionrevision=286383
Log: Update documentation to reflect change with the internal libmagic
updates. See bug #48885



[2009-07-27 02:55:44] scott...@php.net

Looked into this tonight again and from 5.3+ there are two new
constants available, FILEINFO_MIME_TYPE provides the old behavior.

I'll add them both to the documentation tonight.



[2009-07-26 22:31:17] scott...@php.net

Matthew, you can get the behavior with PHP 5.2 if you link against a
newer version of libmagic. This wasn't a change to any of the PHP
wrapper code in this case.

So yes it might be a BC break for you, but in reality its a bug fix.



[2009-07-26 21:48:21] paj...@php.net

Matthew,

That's exactly why the status of this report is set to to be
documented.



[2009-07-26 21:43:19] matthew at zend dot com

I beg to differ a bit here with the assertion that the change is not a
BC break.

Consider this: in versions prior to 5.3.0, one could do a match like
this:

$finfo = new finfo(FILEINFO_MIME);
$type = $finfo-file($filename);
if (!in_array($type, array('image/jpeg', 'image/jpg'))) {
echo Invalid image type.;
} else {
echo JPEG found.
}

Now, with 5.3.0, this changes; the same assertion no longer works. This
is in fact exactly an issue we had with Zend_Validate_File_MimeType when
testing against PHP 5.3.0 -- matching that worked in 5.2.x now no longer
works in 5.3.0. We have altered our library to handle the strings
returned by both versions, but that exactly disproves your point: if the
new behavior were BC, we wouldn't *need* to update our code.

I feel at the very least, the fact that the MIME type returned also
includes encoding information, and the format of this encoding
information, needs to be documented in the manual, and likely the
UPGRADING guide.



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

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



#48195 [Fbk-Opn]: iconv link failure

2009-06-10 Thread philip
 ID:   48195
 Updated by:   phi...@php.net
 Reported By:  rickdunn at chez dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: MacOSX 10.5.6
 PHP Version:  5.3.0RC2
 Assigned To:  scottmac
 New Comment:

Sorry to dirty up the bugs database as I'm not sure if #43189 differs 
from this, so I blindly copied the fix from yimingliu to there hoping 
it would help. My problem exists in 5.2 and 5.3, both of which require

manual changes.

Old snippet from Makefile:
-
libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS) 
$(PHP_SAPI_OBJS)
$(CC) $(MH_BUNDLE_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) 
$(LDFLAGS) $(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) 
$(PHP_SAPI_OBJS:.lo=.o) $(PHP_FRAMEWORKS) $(EXTRA_LIBS) 
$(ZEND_EXTRA_LIBS) -o $@  cp $@ libs/libphp$(PHP_MAJOR_VERSION).so

New snippet from Makefile (after manual fix):
-
libs/libphp$(PHP_MAJOR_VERSION).bundle: $(PHP_GLOBAL_OBJS) 
$(PHP_SAPI_OBJS)
$(CC) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS) 
$(EXTRA_LDFLAGS) $(PHP_GLOBAL_OBJS:.lo=.o) $(PHP_SAPI_OBJS:.lo=.o) 
$(PHP_FRAMEWORKS) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS) $(MH_BUNDLE_FLAGS) 
-o $@  cp $@ libs/libphp$(PHP_MAJOR_VERSION).so

Note:
-
The change is simply moving around $(MH_BUNDLE_FLAGS). The yimingliu 
link provides a decent explanation for why this problem may exist. The

apache2handler.patch.txt patch does not solve this problem.

Configure information:
-
The following build without problem:
./configure --disable-all --with-iconv=/opt/local
./configure --disable-all --with-xmlrpc --enable-libxml=/opt/local --
with-apxs2

While this requires the change to Makefile:
./configure --disable-all --with-iconv=/opt/local --with-apxs2

Jani, Mac is weird and semi-broken in several respects so messing 
around with and for example removing old versions of libraries it 
relies upon can mess things up. This includes libxml2 and libiconv.



Previous Comments:


[2009-06-10 13:06:32] j...@php.net

Can you give the feedback I asked for? See my previous comment.



[2009-06-06 16:42:10] rickdunn at chez dot com

I get the same error now when I try to compile 5.2.9.  The solution in

Bug #43189 did not work for me.



[2009-06-01 09:24:22] j...@php.net

Please provide the generated Makefile's for PHP 5.2.9 (that works) and

PHP 5.3 (that does not work) using same configure options for both. And

as few options as possible, thankyouverymuch. :)



[2009-06-01 09:16:02] j...@php.net

I think the reason is that people have several versions of iconv 
installed in their system. Just remove the extra / wrong / whatever and

it will work fine..



[2009-05-29 16:08:16] phi...@php.net

See Bug #43189 for a [temporary] workaround, which involves editing 
Makefile.



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

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



#48195 [Asn]: iconv link failure

2009-05-29 Thread philip
 ID:   48195
 Updated by:   phi...@php.net
 Reported By:  rickdunn at chez dot com
 Status:   Assigned
 Bug Type: Compile Failure
 Operating System: OS X 10.5.6
 PHP Version:  5.3.0RC2
 Assigned To:  scottmac
 New Comment:

See Bug #43189 for a [temporary] workaround, which involves editing 
Makefile.


Previous Comments:


[2009-05-12 17:38:00] rickdunn at chez dot com

Here's the last few lines and the error:

Zend/zend_object_handlers.o Zend/zend_objects_API.o 
Zend/zend_default_classes.o Zend/zend_execute.o 
sapi/apache2handler/mod_php5.o sapi/apache2handler/sapi_apache2.o 
sapi/apache2handler/apache_config.o 
sapi/apache2handler/php_functions.o main/internal_functions.o  -liconv

-liconv -lm  -o libs/libphp5.bundle  cp libs/libphp5.bundle 
libs/libphp5.so
Undefined symbols:
  _libiconv, referenced from:
  __php_iconv_appendl in iconv.o
  __php_iconv_appendl in iconv.o
  _php_iconv_string in iconv.o
  _php_iconv_string in iconv.o
  __php_iconv_strlen in iconv.o
  __php_iconv_strpos in iconv.o
  _zif_iconv_substr in iconv.o
  _zif_iconv_mime_encode in iconv.o
  _zif_iconv_mime_encode in iconv.o
  _zif_iconv_mime_encode in iconv.o
  _zif_iconv_mime_encode in iconv.o
  _zif_iconv_mime_encode in iconv.o
  _zif_iconv_mime_encode in iconv.o
  _php_iconv_stream_filter_append_bucket in iconv.o
  _php_iconv_stream_filter_append_bucket in iconv.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [libs/libphp5.bundle] Error 1



[2009-05-12 16:10:10] scott...@php.net

Can you show me the last command it tried to run from linking?

Usually you have -L/usr/lib and -L/opt/local/lib or similar.



[2009-05-12 15:55:11] rickdunn at chez dot com

Unfortunately, no luck.  I applied the patch, ran ./buildconf and then

ran the following:

CFLAGS=-arch x86_64 CXXFLAGS=-arch x86_64 LDFLAGS=-arch x86_64 
CCFLAGS=-arch x86_64 ./configure --disable-all --with-iconv --with-
apxs2

'Make' still fails with the same error.

For what it's worth, I compiled 5.2.9 successfully today, so nothing 
seems to have changed on my computer that would cause this.



[2009-05-12 02:19:30] scott...@php.net

Can you apply
http://whisky.macvicar.net/patches/apache2handler.patch.txt

Run ./buildconf and then configure again.

This should fix the issue you're having.



[2009-05-11 21:32:48] ajmiller at engr dot psu dot edu

I had the same problem with iconv on a Mac OS X Server 10.5.6 on an 
iMac G5. 

Using compiler and linker flags 
CFLAGS=-arch ppc64
CCFLAGS=-arch ppc64
CXXFLAGS=-arch ppc64
LDFLAGS=-arch ppc64
export CFLAGS CXXFLAGS LDFLAGS CCFLAGS
to force 64 bit

and then the following configure options did produce a functioning 
version of the php module. 

./configure '--prefix=/usr/local' '--mandir=/usr/share/man' '--
disable-all' '--with-xmlrpc' '--enable-libxml' '--
infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs' '--with-
ldap=/usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib-
dir=/usr' '--enable-trans-sid' '--with-xml' '--enable-exif' '--enable-
ftp' '--enable-mbstring' '--enable-mbregex' '--enable-dbx' '--enable-
sockets' '--with-iodbc=/usr' '--with-curl=/usr' '--with-config-file-
path=/etc' '--sysconfdir=/private/etc' '--with-mysql-sock=/var/mysql' 
'--with-mysqli=mysqlnd' '--with-mysql=mysqlnd' '--with-openssl' '--
with-xmlrpc' '--enable-dom' '--with-xsl=/usr' '--enable-xml' '--with-
pear'

I've never used --disable-all before. Does it disable everything that 
is not explicitly enabled? Does this exclude something that caused the

link problems with iconv?

Also, for mysqlnd to build, I had to edit the mysqlnd_portability.h 
file like I described in the bug #48198 report I submitted previously.



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

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



#43189 [Opn]: Fails to link iconv

2009-05-28 Thread philip
 ID:   43189
 Updated by:   phi...@php.net
 Reported By:  meh at mailinator dot com
 Status:   Open
 Bug Type: ICONV related
 Operating System: Mac OS X 10.5
 PHP Version:  5.3CVS-2007-11-04 (snap)
 New Comment:

For me, the following solution worked:

http://blog.yimingliu.com/2009/02/24/missing-library-symbols-while-
compiling-php-528/

Which involves moving around $(MH_BUNDLE_FLAGS). Looks like a different

yet related bug however, but 


Previous Comments:


[2009-05-24 15:54:54] meh at mailinator dot com

It still fails for me in php5.3-200905241430.

This workaround still necessary:
sudo mv /usr/include/iconv.h /usr/include/iconv.h.leo_orig
sudo ln -s /sw/include/iconv.h /usr/include/iconv.h
rm ext/iconv/*.*o
make



[2009-04-30 13:03:17] scott...@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2009-04-24 17:38:06] richard dot sentino at mindginative dot com

This configure option worked for me:

--with-iconv=/opt/local

(Mac OS 10.5.6, PHP 5.2.9, iconv installed in /opt/local using
macports)

but it doesn't work with this configure option :

--with-iconv=shared,/opt/local

the configure passed and make passed but iconv won't show up when I do
php -m



[2009-03-27 06:26:43] senz at senz dot su

Changing --with-iconv-dir to --with-iconv=shared,/opt/local
solve it on my system.

/opt/local = macports with iconv



[2009-03-27 06:10:22] senz at senz dot su

To scott...@php.net:
here's my config.log from compilation with error.
iconv compiled by macports. --with-iconv-dir=shared,/opt/local and
static both failed.
http://rapidshare.com/files/214033749/config.log.html
i also send a copy on your email.



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

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



#44294 [NoF-Opn]: Undefined symbols with libxml2

2009-05-25 Thread philip
 ID:   44294
 Updated by:   phi...@php.net
 Reported By:  danval at gmail dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Mac 10.5 Leopard Client
-PHP Version:  5.2-latest
+PHP Version:  5.3.0RC2
 New Comment:

The problem is described here:

http://blog.yimingliu.com/2009/02/24/missing-library-symbols-while-
compiling-php-528/

The provided solution (editing Makefile) worked for me.


Previous Comments:


[2009-05-08 18:43:33] rdohms at gmail dot com

Compiling libxml2 from source solved this for me



[2008-08-03 16:21:22] whisller at gmail dot com

I also have this same problem on Leopard.
But solution which you wrote, remove all instances of libxml from your
system can only crash Leopard ( http://jamesclarke.info/notes/libxml2/
- see comments ).

My sudo make also return this same error like in danval situation.



[2008-03-11 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2008-03-03 13:02:57] j...@php.net

Check that your installed libxml2 is clean, ie. you don't have messed
up the headers vs. libraries when installing it. It happens when if you
install it from sources and don't remove the existing installation
first. Most likely this is just a messed up installation of libxml2 so
the easiest way to solve it is first removing all instances of any
libxml2 related files from your system and reinstalling it from scratch,
then do the same for PHP. (use _fresh_ sources!)



[2008-03-01 08:28:51] danval at gmail dot com

Seems it was the way i configured libxml2? this was my setting

./configure --prefix=/Apache/local/libxml \
--enable-shared \
--with-zlib=/Apache/local/zlib

do you see how it would generate that error? is this zlib directory the
same as the one configured in php? 

I was able to use a binary version of libxml2 when i configured php to
successfully build.



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

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



#47323 [Csd-Asn]: strotime warnings in make install

2009-03-26 Thread philip
 ID:   47323
 Updated by:   phi...@php.net
 Reported By:  frozenfire at thefrozenfire dot com
-Status:   Closed
+Status:   Assigned
 Bug Type: PHAR related
 Operating System: Ubuntu 8.10 2.6.27-11-generic
-PHP Version:  5.3.0beta1
+PHP Version:  5.3.0RC1
 Assigned To:  dufuz
 New Comment:

This bug still exists with 5.3.0RC1 so should remain open until that 
changes.


Previous Comments:


[2009-02-16 00:48:39] du...@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

This will be fixed when the next release of the PEAR installer goes
live



[2009-02-06 03:46:33] frozenfire at thefrozenfire dot com

Description:

I've configured a vanilla install of PHP 5.3 Beta 1, using ./configure
--prefix=/usr/local/php-5.3 --program-suffix=53

After configuring (And resolving some missing dependencies), I did a
make, and then a make test (Results submitted).

Next, I did a make install, which produced:

Warning: strtotime(): It is not safe to rely on the system's timezone
settings. You are *required* to use the date.timezone setting or the
date_default_timezone_set() function. In case you used any of those
methods and you are still getting this warning, you most likely
misspelled the timezone identifier. We selected 'America/Los_Angeles'
for 'PST/-8.0/no DST' instead in
phar:///home/myuser/php-5.3.0beta1/pear/install-pear-nozlib.phar/PEAR/Validate.php
on line 489

About a dozen times during Installing PEAR environment:
/usr/local/php-5.3/lib/php/

I don't know if it's related, but the interactive mode in PHP doesn't
work (php53 -a). It prints out Interactive mode enabled and then
allows input, but doesn't process it in any way, including exit.

Reproduce code:
---
sudo ./configure --prefix=/usr/local/php-5.3 --program-suffix=53
sudo make
sudo make test
sudo make install

Expected result:

For the make install, I expected none of the warning messages.

Actual result:
--
Full make install output: http://pastebin.ca/1328662





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



#44197 [Csd-Tbd]: socket array keys lost on socket_select

2008-12-26 Thread philip
 ID:   44197
 Updated by:   phi...@php.net
 Reported By:  darrel dot opry at gmail dot com
-Status:   Closed
+Status:   To be documented
 Bug Type: Sockets related
 Operating System: Linux
 PHP Version:  5.2.5
 New Comment:

What exactly is the change in behaviour?


Previous Comments:


[2008-07-15 13:01:17] j...@php.net

Note: This fix is in PHP 5.3.0 and upwards as it changes the
behaviour.. 



[2008-02-21 02:35:21] fel...@php.net

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2008-02-21 00:18:37] darrel dot opry at gmail dot com

Description:

When you pass a keyed array of sockets into socket_select the keys are
lost.

Reproduce code:
---
$clients = array();
$listener = socket_create_listen();
$clients[uniqid()] = socket_accept($listener);

$read = $clients;
print_r($read);
socket_select($read, $w = NULL, $e = NULL, NULL);
print_r($read);
socket_shutdown($listener);
socket_close($listener);

Expected result:

to test: 
telnet localhost 
enter text, hit enter.


I expect the second print_r($read) to have the same key as the first
print_r($read).

Actual result:
--
Array
(
 [47bcc1d71874d] = Resource id #5
)
Array 
(
 [0] = Resource id #5
)





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



#46766 [Tbd]: Unable to load PHP with php_exif.dll and php_mbstring.dll

2008-12-05 Thread philip
 ID:   46766
 Updated by:   [EMAIL PROTECTED]
 Reported By:  alexander dot ashurkov at gmail dot com
 Status:   To be documented
 Bug Type: Unknown/Other Function
 Operating System: Windows XP SP3
 PHP Version:  5.2.7
 New Comment:

If you feel this should be reworded, please suggest it, but it is in
the documentation under installation not requirements

http://php.net/manual/en/exif.installation.php


Previous Comments:


[2008-12-05 15:29:33] alexander dot ashurkov at gmail dot com

On Installing/Configuring page
(http://ru2.php.net/manual/en/exif.setup.php) only info about mbstring
module must be enabled, no word about modules order.



[2008-12-05 15:20:14] [EMAIL PROTECTED]

not a bug, known requirements. exif relies on mbstring. Is it correctly
documented?



[2008-12-05 15:14:17] alexander dot ashurkov at gmail dot com

To fix this, just put extension=php_mbstring.dll line before
extension=php_exif.dll.



[2008-12-05 15:13:05] alexander dot ashurkov at gmail dot com

Description:

PHP engine is unable to load php_exif and php_mbstrings extensions.

Reproduce code:
---
part of php.ini (default modules order):

extension=php_bz2.dll
;extension=php_curl.dll
;extension=php_dba.dll
;extension=php_dbase.dll
extension=php_exif.dll
;extension=php_fdf.dll
extension=php_gd2.dll
;extension=php_gettext.dll
;extension=php_gmp.dll
;extension=php_ifx.dll
;extension=php_imap.dll
;extension=php_interbase.dll
;extension=php_ldap.dll
extension=php_mbstring.dll
;extension=php_mcrypt.dll
;extension=php_mhash.dll
;extension=php_mime_magic.dll
;extension=php_ming.dll
;extension=php_msql.dll
;extension=php_mssql.dll
extension=php_mysql.dll
extension=php_mysqli.dll
;extension=php_oci8.dll
;extension=php_openssl.dll
extension=php_pdo.dll
;extension=php_pdo_firebird.dll
;extension=php_pdo_mssql.dll
extension=php_pdo_mysql.dll
;extension=php_pdo_oci.dll
;extension=php_pdo_oci8.dll
;extension=php_pdo_odbc.dll
;extension=php_pdo_pgsql.dll
;extension=php_pdo_sqlite.dll
;extension=php_pgsql.dll
;extension=php_pspell.dll
;extension=php_shmop.dll
;extension=php_snmp.dll
;extension=php_soap.dll
;extension=php_sockets.dll
;extension=php_sqlite.dll
;extension=php_sybase_ct.dll
;extension=php_tidy.dll
;extension=php_xmlrpc.dll
;extension=php_xsl.dll
extension=php_zip.dll


Expected result:

php_exif and php_mbstrings extension to be loadable and usuable

Actual result:
--
Using PHP in CLI or as Apache module I got error messages about
libraries cannot be loaded or found.






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



#46766 [Tbd]: Unable to load PHP with php_exif.dll and php_mbstring.dll

2008-12-05 Thread philip
 ID:   46766
 Updated by:   [EMAIL PROTECTED]
 Reported By:  alexander dot ashurkov at gmail dot com
 Status:   To be documented
 Bug Type: Unknown/Other Function
 Operating System: Windows XP SP3
 PHP Version:  5.2.7
 New Comment:

Tricky issue, because that list is alphabetical for a reason and I
would think this issue affects a minority of people so this change to
php.ini would be a little weird. 

Do you have another suggestion? Maybe a small note above that DLL list
in php.ini?

Note: The PHP for Windows installer does take it into account. 


Previous Comments:


[2008-12-05 16:02:38] alexander dot ashurkov at gmail dot com

No, current documenation is OK :)
Can you just re-order these modules in default windows php.ini, so
questions like mine one never pops up.


---
I should always read the manual, I should ...



[2008-12-05 15:36:30] [EMAIL PROTECTED]

If you feel this should be reworded, please suggest it, but it is in
the documentation under installation not requirements

http://php.net/manual/en/exif.installation.php



[2008-12-05 15:29:33] alexander dot ashurkov at gmail dot com

On Installing/Configuring page
(http://ru2.php.net/manual/en/exif.setup.php) only info about mbstring
module must be enabled, no word about modules order.



[2008-12-05 15:20:14] [EMAIL PROTECTED]

not a bug, known requirements. exif relies on mbstring. Is it correctly
documented?



[2008-12-05 15:14:17] alexander dot ashurkov at gmail dot com

To fix this, just put extension=php_mbstring.dll line before
extension=php_exif.dll.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/46766

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



#46766 [Tbd]: Unable to load PHP with php_exif.dll and php_mbstring.dll

2008-12-05 Thread philip
 ID:   46766
 Updated by:   [EMAIL PROTECTED]
 Reported By:  alexander dot ashurkov at gmail dot com
 Status:   To be documented
 Bug Type: Unknown/Other Function
 Operating System: Windows XP SP3
 PHP Version:  5.2.7
 New Comment:

As demonstrated above, there already is.


Previous Comments:


[2008-12-05 16:49:46] [EMAIL PROTECTED]

is it not possible to simply put a note in the manual in the exif
install section? 



[2008-12-05 16:43:48] [EMAIL PROTECTED]

Tricky issue, because that list is alphabetical for a reason and I
would think this issue affects a minority of people so this change to
php.ini would be a little weird. 

Do you have another suggestion? Maybe a small note above that DLL list
in php.ini?

Note: The PHP for Windows installer does take it into account. 



[2008-12-05 16:02:38] alexander dot ashurkov at gmail dot com

No, current documenation is OK :)
Can you just re-order these modules in default windows php.ini, so
questions like mine one never pops up.


---
I should always read the manual, I should ...



[2008-12-05 15:36:30] [EMAIL PROTECTED]

If you feel this should be reworded, please suggest it, but it is in
the documentation under installation not requirements

http://php.net/manual/en/exif.installation.php



[2008-12-05 15:29:33] alexander dot ashurkov at gmail dot com

On Installing/Configuring page
(http://ru2.php.net/manual/en/exif.setup.php) only info about mbstring
module must be enabled, no word about modules order.



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

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



#45166 [Asn-Ana]: substr() overflow changes

2008-11-05 Thread philip
 ID:  45166
 Updated by:  [EMAIL PROTECTED]
-Summary: Note, that behaviour has been changed as from 5.2.3
 Reported By: marrtins at dqdp dot net
-Status:  Assigned
+Status:  Analyzed
 Bug Type:Strings related
-PHP Version: 5.2
+PHP Version: 5.3
 Assigned To: iliaa
 New Comment:

It appears to be. The change came from the following NEWS entry:

- Fixed bug #40754 (added substr()  substr_replace() overflow checks).
(Ilia)

Some concerns were expressed in #40754 about the change... I'm changing
this bug to String related until we know for sure.


Previous Comments:


[2008-11-05 17:06:22] [EMAIL PROTECTED]

See also bug#40754



[2008-11-05 16:54:58] marrtins at dqdp dot net

Seems to me it`s a bug, not documention problem.



[2008-11-05 16:50:50] [EMAIL PROTECTED]

Question: Did 5.3.0 intentionally revert to earlier behaviour? And if
not already, we need a test case in php-src for this.



[2008-11-05 16:49:07] [EMAIL PROTECTED]

4.3.1 - 5.2.1: cd
5.2.2 - 5.2.6: Boolean false
5.3.0a2: cd



[2008-11-05 16:45:38] marrtins at dqdp dot net

Don`t know *exact* version of change, I have tested on PHP versions
listed above and specified behaviours on each that version available to
me.



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

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



#45324 [NEW]: SWITCH function major bug

2008-06-20 Thread philip dot almeida at ippimail dot com
From: philip dot almeida at ippimail dot com
Operating system: Windows  Unix
PHP version:  5.2.6
PHP Bug Type: Unknown/Other Function
Bug description:  SWITCH function major bug

Description:

Bug in function SWITCH when processing a 0 digit.
Looks like Bug #37656: Incorrect switch example must be reopened.

Reproduce code:
---
$test = 0;
switch($test){
case 'ONE':
$result = 'one';
break;
case 0:
$result = 'two';
break;
default:
$result = 'default';
}

print $result;

Expected result:

two

Actual result:
--
one

-- 
Edit bug report at http://bugs.php.net/?id=45324edit=1
-- 
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=45324r=trysnapshot52
Try a CVS snapshot (PHP 5.3): 
http://bugs.php.net/fix.php?id=45324r=trysnapshot53
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=45324r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45324r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=45324r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=45324r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45324r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45324r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=45324r=support
Expected behavior:http://bugs.php.net/fix.php?id=45324r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=45324r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=45324r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45324r=globals
PHP 4 support discontinued:   http://bugs.php.net/fix.php?id=45324r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45324r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45324r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=45324r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=45324r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=45324r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45324r=mysqlcfg



#45044 [NoF-Ver]: PHP doesn't resolve relative path correctly

2008-05-30 Thread philip
 ID:   45044
 Updated by:   [EMAIL PROTECTED]
 Reported By:  felipensp at gmail dot com
-Status:   No Feedback
+Status:   Verified
 Bug Type: Scripting Engine problem
 Operating System: FreeBSD 6.3
 PHP Version:  5.3CVS-2008-05-20 (CVS)
 New Comment:

status-verified 


Previous Comments:


[2008-05-28 01:00:00] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2008-05-20 02:44:43] [EMAIL PROTECTED]

[EMAIL PROTECTED]:/home$ cd felipe
[EMAIL PROTECTED]:/home/felipe$ mkdir test
[EMAIL PROTECTED]:/home/felipe$ cd test
[EMAIL PROTECTED]:/home/felipe/test$ echo ?php include 'foo.php'; ? 
test.php
[EMAIL PROTECTED]:/home/felipe/test$ echo foobar  foo.php
[EMAIL PROTECTED]:/home/felipe/test$ cd ..
[EMAIL PROTECTED]:/home/felipe$ ../cellog/workspace/php5/sapi/cli/php
test/test.php
foobar

I am on linux.  I suspect zend_resolve_path is broken on FreeBSD and
this is part of the segfault you described in phar on IRC.

Can we find another FreeBSDer to confirm this?



[2008-05-20 01:27:00] felipensp at gmail dot com

Description:

I've created:

~/test
~/test/test.php: ?php include 'foo.php'; ?
~/test/foo.php: foobar

Due this issue all tests (.phpt) that uses include/require fails.

PS: This works fine on 5_2.

Reproduce code:
---
[EMAIL PROTECTED] ~]$ php5/sapi/cli/php test/test.php

Expected result:

foobar

Actual result:
--
Warning: include_once(/usr/home/felipe/foo.php): failed to open 
stream: No such file or directory in /usr/home/felipe/test/test.php 
on line 6

Warning: include_once(): Failed opening 'foo.php' for inclusion 
(include_path='.:/usr/local/lib/php') 
in /usr/home/felipe/test/test.php on line 6





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



#44997 [Bgs]: Someone other than Pierre-Alain Joye please answer this

2008-05-14 Thread philip
 ID:   44997
 Updated by:   [EMAIL PROTECTED]
 Reported By:  marcabconfederacy24 at yahoo dot com
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Linux
 PHP Version:  5.2.6
 Assigned To:  pajoye
 New Comment:

Btw, filter isn't really in pecl anymore... it's part of php core. And
perhaps you used a pre-compiled binary from somewhere... we can't help
it if people disable extensions in those.


Previous Comments:


[2008-05-14 18:39:30] [EMAIL PROTECTED]

You're full of non-sense. ext/filter is part of PHP since PHP 5.2 in
every source download online. Please don't reopen this report or file
new ones, we've better things to do.

[EMAIL PROTECTED]:~$ cd /tmp
[EMAIL PROTECTED]:/tmp$ mkdir proof
[EMAIL PROTECTED]:/tmp$ cd proof/
[EMAIL PROTECTED]:/tmp/proof$ wget
http://no2.php.net/distributions/php-5.2.6.tar.gz
--2008-05-14 20:36:18-- 
http://no2.php.net/distributions/php-5.2.6.tar.gz
Resolving no2.php.net... 128.39.198.38
Connecting to no2.php.net|128.39.198.38|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12046184 (11M) [application/x-tar]
Saving to: `php-5.2.6.tar.gz'

100%[==] 12,046,184   301K/s   in
39s 

2008-05-14 20:36:57 (300 KB/s) - `php-5.2.6.tar.gz' saved
[12046184/12046184]

[EMAIL PROTECTED]:/tmp/proof$ tar -xvzf php-5.2.6.tar.gz | grep filter
php-5.2.6/ext/gd/tests/imagefilter.phpt
php-5.2.6/ext/bz2/tests/bz2_filter_decompress.phpt
php-5.2.6/ext/bz2/tests/bz2_filter_compress.phpt
php-5.2.6/ext/bz2/bz2_filter.c
php-5.2.6/ext/spl/examples/callbackfilteriterator.inc
php-5.2.6/ext/spl/examples/directoryfilterdots.inc
php-5.2.6/ext/spl/examples/keyfilter.inc
php-5.2.6/ext/spl/internal/recursivefilteriterator.inc
php-5.2.6/ext/spl/internal/filteriterator.inc
php-5.2.6/ext/zlib/tests/zlib_filter_deflate.phpt
php-5.2.6/ext/zlib/tests/zlib_filter_inflate.phpt
php-5.2.6/ext/zlib/tests/zlib_filter_inflate2.phpt
php-5.2.6/ext/zlib/zlib_filter.c
php-5.2.6/ext/iconv/tests/iconv_stream_filter.txt
php-5.2.6/ext/iconv/tests/iconv_stream_filter.phpt
php-5.2.6/ext/filter/
php-5.2.6/ext/filter/docs/
php-5.2.6/ext/filter/docs/filter.txt
php-5.2.6/ext/filter/docs/input_get_args.php
php-5.2.6/ext/filter/callback_filter.c
php-5.2.6/ext/filter/tests/
php-5.2.6/ext/filter/tests/bug5.phpt
php-5.2.6/ext/filter/tests/024.phpt
php-5.2.6/ext/filter/tests/filter_data.phpt
php-5.2.6/ext/filter/tests/025.phpt
php-5.2.6/ext/filter/tests/026.phpt
php-5.2.6/ext/filter/tests/027.phpt
php-5.2.6/ext/filter/tests/028.phpt
php-5.2.6/ext/filter/tests/bug7733.phpt
php-5.2.6/ext/filter/tests/029.phpt
php-5.2.6/ext/filter/tests/030.phpt
php-5.2.6/ext/filter/tests/031.phpt
php-5.2.6/ext/filter/tests/032.phpt
php-5.2.6/ext/filter/tests/033.phpt
php-5.2.6/ext/filter/tests/034.phpt
php-5.2.6/ext/filter/tests/callback_non_modified_var.phpt
php-5.2.6/ext/filter/tests/035.phpt
php-5.2.6/ext/filter/tests/036.phpt
php-5.2.6/ext/filter/tests/037.phpt
php-5.2.6/ext/filter/tests/038.phpt
php-5.2.6/ext/filter/tests/039.phpt
php-5.2.6/ext/filter/tests/040.phpt
php-5.2.6/ext/filter/tests/041.phpt
php-5.2.6/ext/filter/tests/042.phpt
php-5.2.6/ext/filter/tests/043.phpt
php-5.2.6/ext/filter/tests/044.phpt
php-5.2.6/ext/filter/tests/045.phpt
php-5.2.6/ext/filter/tests/046.phpt
php-5.2.6/ext/filter/tests/047.phpt
php-5.2.6/ext/filter/tests/048.phpt
php-5.2.6/ext/filter/tests/049.phpt
php-5.2.6/ext/filter/tests/050.phpt
php-5.2.6/ext/filter/tests/051.phpt
php-5.2.6/ext/filter/tests/052.phpt
php-5.2.6/ext/filter/tests/053.phpt
php-5.2.6/ext/filter/tests/PMOPB45.phpt
php-5.2.6/ext/filter/tests/bug7586.phpt
php-5.2.6/ext/filter/tests/bug39763.phpt
php-5.2.6/ext/filter/tests/001.phpt
php-5.2.6/ext/filter/tests/002.phpt
php-5.2.6/ext/filter/tests/033_run.inc
php-5.2.6/ext/filter/tests/003.phpt
php-5.2.6/ext/filter/tests/004.phpt
php-5.2.6/ext/filter/tests/005.phpt
php-5.2.6/ext/filter/tests/006.phpt
php-5.2.6/ext/filter/tests/007.phpt
php-5.2.6/ext/filter/tests/008.phpt
php-5.2.6/ext/filter/tests/009.phpt
php-5.2.6/ext/filter/tests/bug7715.phpt
php-5.2.6/ext/filter/tests/010.phpt
php-5.2.6/ext/filter/tests/011.phpt
php-5.2.6/ext/filter/tests/012.phpt
php-5.2.6/ext/filter/tests/013.phpt
php-5.2.6/ext/filter/tests/014.phpt
php-5.2.6/ext/filter/tests/015.phpt
php-5.2.6/ext/filter/tests/016.phpt
php-5.2.6/ext/filter/tests/017.phpt
php-5.2.6/ext/filter/tests/018.phpt
php-5.2.6/ext/filter/tests/019.phpt
php-5.2.6/ext/filter/tests/020.phpt
php-5.2.6/ext/filter/tests/021.phpt
php-5.2.6/ext/filter/tests/022.phpt
php-5.2.6/ext/filter/tests/bug8315.phpt
php-5.2.6/ext/filter/tests/023.phpt
php-5.2.6/ext/filter/tests/bug39846.phpt
php-5.2.6/ext/filter/sanitizing_filters.c
php-5.2.6/ext/filter/config.m4
php-5.2.6/ext/filter/filter.c
php-5.2.6/ext/filter/config.w32
php-5.2.6/ext/filter/logical_filters.c
php-5.2.6/ext/filter/filter_private.h
php-5.2.6/ext/filter/CREDITS

#42262 [Bgs-Opn]: get_magic_quotes_gpc() should be there and return false

2008-03-01 Thread philip
 ID:   42262
 Updated by:   [EMAIL PROTECTED]
 Reported By:  spam2 at rhsoft dot net
-Status:   Bogus
+Status:   Open
 Bug Type: *Configuration Issues
 Operating System: All
 PHP Version:  6CVS-2007-08-09 (snap)
 New Comment:

Still being discussed... and the thread in question decided to keep
them AFAICT. Where else was a decision made on this?

http://marc.info/?l=php-internalsm=114177891420914w=2



Previous Comments:


[2008-02-05 11:34:54] [EMAIL PROTECTED]

Hi Philip, see the Remove magic_quotes and register global thread two
years ago.

The functions (there is more than the getter) can't exist anymore as
the underlying features do not exist anymore. Using them (in all bad
possible bad ways) can end in a rather unexpected result if they don't
check return values (setter).

A simple if (php_version = 6) does the job and makes it clear in your
code. Still no bug sorry (that means bogus here).



[2008-02-05 04:02:18] [EMAIL PROTECTED]

As the reporter mentioned outside this report, NEWS indicates this
function should exist whereas various bug reports say it shouldn't, and
I cannot find the decision on internals...

For now we must consider NEWS as the authority in which case this
function should exist so please update NEWS if this has changed and
regardless it will then be documented.

And since it (php5) returns 0 or 1, I reckon if it exists it should
return 0 and not false.



[2008-02-04 13:41:01] [EMAIL PROTECTED]

  still not bug, please see php.internals archive for the discussion
about this change.



[2008-02-04 13:17:35] [EMAIL PROTECTED]

Hello,

The behavior of get_magic_quotes_gpc has changed. Check the NEWS file:

 Changed get_magic_quotes_gpc(), get_magic_quotes_runtime to always
return
false and set_magic_quotes_runtime() to raise an E_CORE_ERROR.




[2007-08-09 22:39:12] spam2 at rhsoft dot net

Description:

[10-Aug-2007 00:30:56] PHP Fatal error:  Call to undefined function
get_magic_quotes_gpc() in
/mnt/data/www/sql.rhsoft.net/libraries/common.lib.php on line 2606


The function get_magic_quotes_gpc() should available in PHP6 and
return always false, so you dont break applications that check the
setting and make a stripslashes if it is on.



Reproduce code:
---
if(function_exists('get_magic_quotes_gpc')  get_magic_quotes_gpc())
{
 @$akt_temp_str_name = stripslashes(@$akt_temp_str_name);
}

Expected result:

if(get_magic_quotes_gpc())
{
 @$akt_temp_str_name = stripslashes(@$akt_temp_str_name);
}

should work also

Actual result:
--
A fatal error





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


#42262 [Bgs-Opn]: get_magic_quotes_gpc() should be there and return false

2008-02-04 Thread philip
 ID:   42262
 Updated by:   [EMAIL PROTECTED]
 Reported By:  spam2 at rhsoft dot net
-Status:   Bogus
+Status:   Open
-Bug Type: Feature/Change Request
+Bug Type: *Configuration Issues
 Operating System: All
 PHP Version:  6CVS-2007-08-09 (snap)
 New Comment:

As the reporter mentioned outside this report, NEWS indicates this
function should exist whereas various bug reports say it shouldn't, and
I cannot find the decision on internals...

For now we must consider NEWS as the authority in which case this
function should exist so please update NEWS if this has changed and
regardless it will then be documented.

And since it (php5) returns 0 or 1, I reckon if it exists it should
return 0 and not false.


Previous Comments:


[2008-02-04 13:41:01] [EMAIL PROTECTED]

  still not bug, please see php.internals archive for the discussion
about this change.



[2008-02-04 13:17:35] [EMAIL PROTECTED]

Hello,

The behavior of get_magic_quotes_gpc has changed. Check the NEWS file:

 Changed get_magic_quotes_gpc(), get_magic_quotes_runtime to always
return
false and set_magic_quotes_runtime() to raise an E_CORE_ERROR.




[2007-08-09 22:39:12] spam2 at rhsoft dot net

Description:

[10-Aug-2007 00:30:56] PHP Fatal error:  Call to undefined function
get_magic_quotes_gpc() in
/mnt/data/www/sql.rhsoft.net/libraries/common.lib.php on line 2606


The function get_magic_quotes_gpc() should available in PHP6 and
return always false, so you dont break applications that check the
setting and make a stripslashes if it is on.



Reproduce code:
---
if(function_exists('get_magic_quotes_gpc')  get_magic_quotes_gpc())
{
 @$akt_temp_str_name = stripslashes(@$akt_temp_str_name);
}

Expected result:

if(get_magic_quotes_gpc())
{
 @$akt_temp_str_name = stripslashes(@$akt_temp_str_name);
}

should work also

Actual result:
--
A fatal error





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


#42847 [NEW]: gcov support to allow lcov 1.6

2007-10-03 Thread philip at roshambo dot org
From: philip at roshambo dot org
Operating system: Mac
PHP version:  5.2.4
PHP Bug Type: Unknown/Other Function
Bug description:  gcov support to allow lcov 1.6

Description:

Compiling PHP with gcov support requires lcov from the LTP (Linux Test
Project) installed. Version 1.6 was released 2007-08-22 and PHP says it
won't work (requires 1.5 not 1.6) so this report requests PHP to allow
1.6.

http://sourceforge.net/project/showfiles.php?group_id=3382package_id=80148


Reproduce code:
---
./configure --enable-gcov

Expected result:

Success

Actual result:
--
...
checking whether to include gcov symbols... yes
checking for lcov... lcov
checking for genhtml... genhtml
checking for ltp version... invalid
configure: error: You must have one of the following versions of LTP: 1.5
(found: 1.6).

-- 
Edit bug report at http://bugs.php.net/?id=42847edit=1
-- 
Try a CVS snapshot (PHP 4.4): 
http://bugs.php.net/fix.php?id=42847r=trysnapshot44
Try a CVS snapshot (PHP 5.2): 
http://bugs.php.net/fix.php?id=42847r=trysnapshot52
Try a CVS snapshot (PHP 6.0): 
http://bugs.php.net/fix.php?id=42847r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=42847r=fixedcvs
Fixed in release: 
http://bugs.php.net/fix.php?id=42847r=alreadyfixed
Need backtrace:   http://bugs.php.net/fix.php?id=42847r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=42847r=needscript
Try newer version:http://bugs.php.net/fix.php?id=42847r=oldversion
Not developer issue:  http://bugs.php.net/fix.php?id=42847r=support
Expected behavior:http://bugs.php.net/fix.php?id=42847r=notwrong
Not enough info:  
http://bugs.php.net/fix.php?id=42847r=notenoughinfo
Submitted twice:  
http://bugs.php.net/fix.php?id=42847r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=42847r=globals
PHP 3 support discontinued:   http://bugs.php.net/fix.php?id=42847r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=42847r=dst
IIS Stability:http://bugs.php.net/fix.php?id=42847r=isapi
Install GNU Sed:  http://bugs.php.net/fix.php?id=42847r=gnused
Floating point limitations:   http://bugs.php.net/fix.php?id=42847r=float
No Zend Extensions:   http://bugs.php.net/fix.php?id=42847r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=42847r=mysqlcfg


#42847 [Opn-Asn]: gcov support to allow lcov 1.6

2007-10-03 Thread philip
 ID:   42847
 Updated by:   [EMAIL PROTECTED]
 Reported By:  philip at roshambo dot org
-Status:   Open
+Status:   Assigned
 Bug Type: Unknown/Other Function
 Operating System: Mac
 PHP Version:  5.2.4
-Assigned To:  
+Assigned To:  nlopess


Previous Comments:


[2007-10-03 23:22:44] philip at roshambo dot org

Description:

Compiling PHP with gcov support requires lcov from the LTP (Linux Test
Project) installed. Version 1.6 was released 2007-08-22 and PHP says it
won't work (requires 1.5 not 1.6) so this report requests PHP to allow
1.6.

http://sourceforge.net/project/showfiles.php?group_id=3382package_id=80148


Reproduce code:
---
./configure --enable-gcov

Expected result:

Success

Actual result:
--
...
checking whether to include gcov symbols... yes
checking for lcov... lcov
checking for genhtml... genhtml
checking for ltp version... invalid
configure: error: You must have one of the following versions of LTP:
1.5 (found: 1.6).





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


#41445 [Csd]: parse_ini_file function has a problem with certain types of integer as sections

2007-08-02 Thread philip
 ID:   41445
 Updated by:   [EMAIL PROTECTED]
 Reported By:  dcox at conxxus dot com
 Status:   Closed
 Bug Type: PHP options/info functions
 Operating System: linux 2.4.32
 PHP Version:  5.2.2
 Assigned To:  tony2001
 New Comment:

FWIW, this bug also exists (and was documented) via:

http://bugs.php.net/bug.php?id=29306

The documentation will be updated to reflect the new fixed behaviour.


Previous Comments:


[2007-06-26 12:10:11] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2007-05-19 22:42:46] dcox at conxxus dot com

Description:

I stumbled across this when storing MAC configuration in an INI file.
When the MAC address (length=12) had all numbers and started with 00
then the MAC would not be stored as a section correctly.

Reproduce code:
---
?php
$options = parse_ini_file(test.ini, TRUE);
print_r($options);
?

-- test.ini --
[001099030277]
option1 = yes

[011099030277]
option2 = yes



Expected result:

Array
(
[001099030277] = Array
(
[option1] = 1
)

[011099030277] = Array
(
[option2] = 1
)

)

Actual result:
--
Array
(
[8] = Array
(
[option1] = 1
)

[011099030277] = Array
(
[option2] = 1
)

)





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


#41343 [Com]: FastCGI Server (Internal Server Error)

2007-05-10 Thread philip dot iezzi at onlime dot ch
 ID:   41343
 Comment by:   philip dot iezzi at onlime dot ch
 Reported By:  trustpunk at gmail dot com
 Status:   Open
 Bug Type: CGI related
 Operating System: Windows XP
 PHP Version:  5.2.2
 New Comment:

Same problem here, PHP 5.2.2 as CGI crashes all the time.
I have encountered the problem under the following configurations:


Debian Linux (sarge)
PHP/CGI 5.2.2  4.4.7, compiled from sources
web application: SPIP 1.9 CMS

Debian Linux (etch)
PHP/FastCGI(fcgid) 5.2.2, compiled from sources
web application: Roundcube webmail (latest SVN checkout)


Downgrading back to PHP 5.2.1 solved all the issues.
I definitely need to get 5.2.2 running as a serious bug with FastCGI
was fixed (#40286). The current situation is pretty ugly, both versions
of PHP are buggy in their own way under CGI/FastCGI.

Thx!
Philip


Previous Comments:


[2007-05-10 01:33:11] trustpunk at gmail dot com

Description:

I run the FastCGI server
C:\PHP5\php-cgi.exe -b 127.0.0.1:2700

When it becomes under too much load, it displays an Internal Server
Error.



Reproduce code:
---
This code will cause the FastCGI Server to show an Internal Server
Error.

?php

if (class_exists(COM)) {
  $wmi = new COM(WinMgmts:.);
  $cpus = $wmi-InstancesOf(Win32_Processor);
 
  $i = 1;
 
  // Use the while loop on PHP 4 and foreach on PHP 5
  // while ($cpu = $cpus-Next()) {
  foreach ($cpus as $cpu) {
 
   echo pProcessor $i :  . $cpu-Name .  @ ;
   $clockSpeed = $cpu-CurrentClockSpeed;
   $cpuLoad = $cpu-LoadPercentage;
   echo $clockSpeed .  MHz (Load=  . $cpuLoad .%)/p;
   $i++;
   
  }
 
  $uptime = 0;
  $systems = $wmi-InstancesOf(Win32_PerfRawData_PerfOS_System);
 
  // Use the while loop on PHP 4 and foreach on PHP 5
  // while ($system = $systems-Next()) {
  foreach ($systems as $system) {
 
   $PerfTimeStamp = $system-Timestamp_Object ;
   $PerfTimeFreq = $system-Frequency_Object ;
   $Counter = $system-SystemUpTime ;
   $UptimeInSec = ($PerfTimeStamp - $Counter)/$PerfTimeFreq ;
   
   $uptime = max($uptime, $UptimeInSec);
  }
 }
 else {
  return pYour system does not support WMI!/p;
 }
?

Expected result:

I expect to see my Processors listed with some useful information.

Actual result:
--
Internal Server Error (500)





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


#38467 [Opn-Ver]: --enable-versioning causes make fail when building against apxs2

2006-08-15 Thread philip
 ID:   38467
 Updated by:   [EMAIL PROTECTED]
 Reported By:  contax at phrenetic dot org
-Status:   Open
+Status:   Verified
 Bug Type: Compile Failure
 Operating System: Darwin Kernel Version 8.7.1
-PHP Version:  5.1.4
+PHP Version:  5.2-200608151630
 New Comment:

I can confirm this problem on my machine too.


Previous Comments:


[2006-08-15 16:21:38] contax at phrenetic dot org

No dice. Still being returned:

/usr/bin/ld: unknown flag: -export-symbols
collect2: ld returned 1 exit status
make: *** [libs/libphp5.bundle] Error 1



[2006-08-15 15:39:06] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip





[2006-08-15 15:28:38] contax at phrenetic dot org

Description:

When building php against apxs2 (Apache 2.2.3) on Mac OS X (10.4.7) the
make failes. It works fine when --enable-versioning is left out.

Reproduce code:
---
./configure --with-apxs2=/usr/local/apache2/bin/apxs
--prefix=/usr/local --enable-versioning

Expected result:

All compiled

Actual result:
--
/bin/sh /Users/contax/src/php-5.1.4/libtool --silent
--preserve-dup-deps --mode=compile gcc  -Iext/standard/
-I/Users/contax/src/php-5.1.4/ext/standard/ -DPHP_ATOM_INC
-I/Users/contax/src/php-5.1.4/include
-I/Users/contax/src/php-5.1.4/main -I/Users/contax/src/php-5.1.4
-I/usr/include/libxml2 -I/Users/contax/src/php-5.1.4/ext/date/lib
-I/Users/contax/src/php-5.1.4/TSRM -I/Users/contax/src/php-5.1.4/Zend 
-no-cpp-precomp  -I/usr/include -g -O2  -c
/Users/contax/src/php-5.1.4/ext/standard/info.c -o ext/standard/info.lo

/Users/contax/src/php-5.1.4/ext/standard/info.c: In function
'php_info_write_wrapper':
/Users/contax/src/php-5.1.4/ext/standard/info.c:69: warning: pointer
targets in passing argument 1 of 'php_escape_html_entities' differ in
signedness
/Users/contax/src/php-5.1.4/ext/standard/info.c: In function
'php_info_html_esc':
/Users/contax/src/php-5.1.4/ext/standard/info.c:218: warning: pointer
targets in passing argument 1 of 'php_escape_html_entities' differ in
signedness
/Users/contax/src/php-5.1.4/ext/standard/info.c: In function
'php_print_info':
/Users/contax/src/php-5.1.4/ext/standard/info.c:508: warning: pointer
targets in passing argument 3 of 'zend_hash_get_current_key_ex' differ
in signedness
/Users/contax/src/php-5.1.4/ext/standard/info.c:539: warning: pointer
targets in passing argument 3 of 'zend_hash_get_current_key_ex' differ
in signedness
/Users/contax/src/php-5.1.4/ext/standard/info.c:580: warning: pointer
targets in passing argument 3 of 'zend_hash_get_current_key_ex' differ
in signedness
/bin/sh /Users/contax/src/php-5.1.4/libtool --silent
--preserve-dup-deps --mode=compile gcc  -I/usr/local/apache2/include 
-DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp
-I/usr/local/apache2/include   -I/usr/local/apache2/include 
-Isapi/apache2handler/
-I/Users/contax/src/php-5.1.4/sapi/apache2handler/ -DPHP_ATOM_INC
-I/Users/contax/src/php-5.1.4/include
-I/Users/contax/src/php-5.1.4/main -I/Users/contax/src/php-5.1.4
-I/usr/include/libxml2 -I/Users/contax/src/php-5.1.4/ext/date/lib
-I/Users/contax/src/php-5.1.4/TSRM -I/Users/contax/src/php-5.1.4/Zend 
-no-cpp-precomp  -I/usr/include -g -O2  -c
/Users/contax/src/php-5.1.4/sapi/apache2handler/mod_php5.c -o
sapi/apache2handler/mod_php5.lo 
/bin/sh /Users/contax/src/php-5.1.4/libtool --silent
--preserve-dup-deps --mode=compile gcc  -I/usr/local/apache2/include 
-DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp
-I/usr/local/apache2/include   -I/usr/local/apache2/include 
-Isapi/apache2handler/
-I/Users/contax/src/php-5.1.4/sapi/apache2handler/ -DPHP_ATOM_INC
-I/Users/contax/src/php-5.1.4/include
-I/Users/contax/src/php-5.1.4/main -I/Users/contax/src/php-5.1.4
-I/usr/include/libxml2 -I/Users/contax/src/php-5.1.4/ext/date/lib
-I/Users/contax/src/php-5.1.4/TSRM -I/Users/contax/src/php-5.1.4/Zend 
-no-cpp-precomp  -I/usr/include -g -O2  -c
/Users/contax/src/php-5.1.4/sapi/apache2handler/sapi_apache2.c -o
sapi/apache2handler/sapi_apache2.lo 
/bin/sh /Users/contax/src/php-5.1.4/libtool --silent
--preserve-dup-deps --mode=compile gcc  -I/usr/local/apache2/include 
-DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp
-I/usr/local/apache2/include   -I/usr/local/apache2/include 
-Isapi/apache2handler/
-I/Users/contax/src/php-5.1.4/sapi/apache2handler/ -DPHP_ATOM_INC
-I/Users/contax/src/php-5.1.4/include
-I/Users/contax/src/php-5.1.4/main -I/Users/contax/src/php-5.1.4
-I/usr/include/libxml2 -I/Users/contax/src/php-5.1.4/ext/date/lib
-I/Users/contax/src/php-5.1.4/TSRM -I/Users/contax/src/php-5.1.4/Zend 
-no-cpp-precomp  -I/usr/include -g -O2  -c

#33291 [NEW]: An addition of consistent function name aliases

2005-06-09 Thread philip at cornado dot com
From: philip at cornado dot com
Operating system: 
PHP version:  5CVS-2005-06-10 (dev)
PHP Bug Type: Feature/Change Request
Bug description:  An addition of consistent function name aliases

Description:

Request: For PHP to add a ton of function aliases that make the naming
schemes consistent. Some examples: is_set(), str_pos(), array_key()...


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


#32594 [Opn]: missing php4activescript.dll in download

2005-04-12 Thread philip
 ID:   32594
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mazdaf at yahoo dot com
 Status:   Open
 Bug Type: Other web server
 Operating System: win 2003
-PHP Version:  Irrelevant
+PHP Version:  4.3.11
 New Comment:

Typo: Of course it's php4activescript.dll in PHP = 4.3.9 ZIP's


Previous Comments:


[2005-04-05 19:51:47] [EMAIL PROTECTED]

I believe as of PHP 4.3.10 this is a real problem:

Places it's not:
- PHP 4 PECL snaps
- PHP 4.3.1x ZIP's

Places it's (php5activescript.dll) in:
- PHP 5 PECL download package
- PHP 5 PECL snaps
- PHP = 4.3.9 ZIP's



[2005-04-05 19:24:16] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.



[2005-04-05 19:13:59] [EMAIL PROTECTED]

Not a docproblem.



[2005-04-05 19:11:46] mazdaf at yahoo dot com

Description:

In the install file, it says
The directory structure extracted from the zip is different for PHP
   versions 4 and 5 and look like as follows:

   Example 2-1. PHP 4 package structure



   +--sapi-- SAPI (server module support) DLLs
   |  |
   |  |-php4activescript.dll
   |  |
   |  |-php4apache.dll
   |  |
   |  |-php4apache2.dll
   |  |
   |  |-..



 ---
but there is no php4activescript.dll file in the 4.3.11 download in the
Windows Binaries/PHP 4.3.11 zip package [7,289Kb] - 31 Mar 2005
download.






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


#32594 [Csd-Opn]: missing php4activescript.dll in download

2005-04-12 Thread philip
 ID:   32594
 Updated by:   [EMAIL PROTECTED]
-Summary:  missing dll in download
 Reported By:  mazdaf at yahoo dot com
-Status:   Closed
+Status:   Open
 Bug Type: Other web server
 Operating System: win 2003
 PHP Version:  Irrelevant
 New Comment:

I believe as of PHP 4.3.10 this is a real problem:

Places it's not:
- PHP 4 PECL snaps
- PHP 4.3.1x ZIP's

Places it's (php5activescript.dll) in:
- PHP 5 PECL download package
- PHP 5 PECL snaps
- PHP = 4.3.9 ZIP's


Previous Comments:


[2005-04-05 19:24:16] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.



[2005-04-05 19:13:59] [EMAIL PROTECTED]

Not a docproblem.



[2005-04-05 19:11:46] mazdaf at yahoo dot com

Description:

In the install file, it says
The directory structure extracted from the zip is different for PHP
   versions 4 and 5 and look like as follows:

   Example 2-1. PHP 4 package structure



   +--sapi-- SAPI (server module support) DLLs
   |  |
   |  |-php4activescript.dll
   |  |
   |  |-php4apache.dll
   |  |
   |  |-php4apache2.dll
   |  |
   |  |-..



 ---
but there is no php4activescript.dll file in the 4.3.11 download in the
Windows Binaries/PHP 4.3.11 zip package [7,289Kb] - 31 Mar 2005
download.






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


#27406 [Asn]: php_check_syntax executes code

2005-01-25 Thread philip
 ID:   27406
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thomas at stauntons dot org
 Status:   Assigned
 Bug Type: Unknown/Other Function
-Operating System: OS X
+Operating System: All
 PHP Version:  php5.0-200412100930
-Assigned To:  iliaa
+Assigned To:  ilia
 New Comment:

It's like include() except it won't output the checked file  (like if
the checked file has an echo, it won't echo it). Aside from the
obvious that's the only difference I notice but haven't tested it
thoroughly.

Sounds like this bug will never be fixed so I guess we should just
document the current behavior.


Previous Comments:


[2004-12-14 00:30:08] [EMAIL PROTECTED]

I see it's assigned to Ilia so I'm not changing the status. Personally
I would put this on very low priority for resolving. Whoever added the
lint functionality probably did it for the command-line PHP in order to
be able to quickly check a large amount of source code. I don't see this
as a mainstream feature of PHP and would avoid hacking on getting it
right as to not intefere with the normal execution of PHP (although
it's quite possible).



[2004-12-10 17:39:51] [EMAIL PROTECTED]

See also: http://bugs.php.net/27728



[2004-11-11 23:34:56] jimmy dot lantz at gmail dot com

Couldnt there be an optional bool for including the function? Like 
bool php_check_syntax ( string file_name [, string error_message][,
bool just_lint])
That is if 3rd var is true it behaves like php -l from CLI?
That way we that just wants to validate PHP code without
including/running it?
Preferrably in a totally secured way...



[2004-10-22 23:37:44] dan dot ostrowski at gmail dot com

The person above posted this: 
-- 
?php 
 
$error_message = ; 
$filename = ./tests.php; 
 
//Check out $filename 
if(!php_check_syntax($filename, $error_message)) { 
   //Display an error message, the code is bad 
   printf(Errors were found in the file %s:\n\n%s\n, 
$filename, 
$error_message); 
} else { 
   //Execute the valid code 
   include_once ($filename); 
} 
- 
 
To use in the docs. The problem is this code is INCORRECT. 
The function php_check_syntax( ) INCLUDES THE FILE in php 
5.0.2 
 
This means you get redeclare errors if you try to check the 
syntax and then include the file. 
 
The example code SHOULD be: 
- 
?php 
 
$filename = '/path/to/somefile.php'; 
$err = (string) null; 
 
if( !php_check_syntax( $filename, $err ) ) { 
print Syntax Error! 
die( ); 
} 
 
// proceed, because at this point the file is included 
// or script is dead. 
 
-



[2004-10-07 16:07:50] junk at thinkof dot net

My vote is for this function, and for updating the docs.  Also the
comments in the php.net manual should be updated, as this isn't really
a bug.

Simply saying that the function is being misused, or saying this is bug
is not a good thing.  People just need to understand its usage.

The simplest way I can see of updating the doc, is including a more
useful example.  Perhaps mentioning possible usages (checking the
syntax of a file for it's first load into a caching engine for
example).

?php

$error_message = ;
$filename = ./tests.php;

//Check out $filename
if(!php_check_syntax($filename, $error_message)) {
   //Display an error message, the code is bad
   printf(Errors were found in the file %s:\n\n%s\n, $filename,
$error_message);
} else {
   //Execute the valid code
   include_once ($filename);
}

?



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

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


#27406 [Asn]: php_check_syntax executes code

2004-12-10 Thread philip
 ID:   27406
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thomas at stauntons dot org
 Status:   Assigned
 Bug Type: Unknown/Other Function
 Operating System: OS X
-PHP Version:  5.0.2-dev
+PHP Version:  php5.0-200412100930
 Assigned To:  iliaa
 New Comment:

See also: http://bugs.php.net/27728


Previous Comments:


[2004-11-11 23:34:56] jimmy dot lantz at gmail dot com

Couldnt there be an optional bool for including the function? Like 
bool php_check_syntax ( string file_name [, string error_message][,
bool just_lint])
That is if 3rd var is true it behaves like php -l from CLI?
That way we that just wants to validate PHP code without
including/running it?
Preferrably in a totally secured way...



[2004-10-22 23:37:44] dan dot ostrowski at gmail dot com

The person above posted this: 
-- 
?php 
 
$error_message = ; 
$filename = ./tests.php; 
 
//Check out $filename 
if(!php_check_syntax($filename, $error_message)) { 
   //Display an error message, the code is bad 
   printf(Errors were found in the file %s:\n\n%s\n, 
$filename, 
$error_message); 
} else { 
   //Execute the valid code 
   include_once ($filename); 
} 
- 
 
To use in the docs. The problem is this code is INCORRECT. 
The function php_check_syntax( ) INCLUDES THE FILE in php 
5.0.2 
 
This means you get redeclare errors if you try to check the 
syntax and then include the file. 
 
The example code SHOULD be: 
- 
?php 
 
$filename = '/path/to/somefile.php'; 
$err = (string) null; 
 
if( !php_check_syntax( $filename, $err ) ) { 
print Syntax Error! 
die( ); 
} 
 
// proceed, because at this point the file is included 
// or script is dead. 
 
-



[2004-10-07 16:07:50] junk at thinkof dot net

My vote is for this function, and for updating the docs.  Also the
comments in the php.net manual should be updated, as this isn't really
a bug.

Simply saying that the function is being misused, or saying this is bug
is not a good thing.  People just need to understand its usage.

The simplest way I can see of updating the doc, is including a more
useful example.  Perhaps mentioning possible usages (checking the
syntax of a file for it's first load into a caching engine for
example).

?php

$error_message = ;
$filename = ./tests.php;

//Check out $filename
if(!php_check_syntax($filename, $error_message)) {
   //Display an error message, the code is bad
   printf(Errors were found in the file %s:\n\n%s\n, $filename,
$error_message);
} else {
   //Execute the valid code
   include_once ($filename);
}

?



[2004-09-21 16:03:24] de_bruut at hotmail dot com

How should the docs be changed? This misfeature hasn't been dealt with
yet...maybe we should just remove the docs :)

What misfeature? IMO a function that can check the syntax of a PHP file
before it's included has real benefits for development and testing (as
it can be used to avoid parse and fatal errors etc). And the
documentation of php_check_syntax perfectly describes such a function.
The only problem here is the fact that php_check_syntax not only checks
the code, but executes it as well. I'd say that this is unexpected,
undesirable behavior (a bug). The documentation is just fine the way it
is now...



[2004-09-20 21:36:57] [EMAIL PROTECTED]

How should the docs be changed? This misfeature hasn't been dealt with
yet...maybe we should just remove the docs :)



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

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


#30710 [NEW]: Client Version is too old

2004-11-06 Thread philip at r66 dot ru
From: philip at r66 dot ru
Operating system: Windows XP Pro
PHP version:  4.3.9
PHP Bug Type: MySQL related
Bug description:  Client Version is too old

Description:

MySQL Returns error #1251 - Client does not support authentication
protocol requested by server; consider upgrading MySQL client;


MySQL Version 4.1.7-nt

Apache Version: Apache/2.0.52 (Win32)

Current Client API version:  3.23.49 (what phpinfo() tells)


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


#27406 [Asn]: php_check_syntax executes code

2004-09-20 Thread philip
 ID:   27406
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thomas at stauntons dot org
 Status:   Assigned
 Bug Type: Unknown/Other Function
 Operating System: OS X
 PHP Version:  5.0.2-dev
 Assigned To:  iliaa
 New Comment:

How should the docs be changed? This misfeature hasn't been dealt with
yet...maybe we should just remove the docs :)


Previous Comments:


[2004-09-16 18:19:12] didou at keliglia dot com

So should this function actually execute the code (like an include())
or
should it be a simple lint check (identical to php -l)

It should do only a lint check, otherway we don't need this function as
we already have include..

Anyway, we should really change the docs philip.



[2004-08-26 18:20:05] [EMAIL PROTECTED]

Tested latest CVS on a Win32 machine, same problem.  Here's a very
simple test:

randominclude.php
?php
function foobar() {
echo HI;
}
?

checksyntax.php
?php 
if (php_check_syntax('randominclude.php')) {
echo passed; 
foobar(); 
}
?

Calling checksyntax.php via Module/CLI/CGI results in:

passedHI

As opposed to:

passed
Fatal error: Call to undefined function foobar() in ...




[2004-08-09 05:10:33] [EMAIL PROTECTED]

So should this function actually execute the code (like an include())
or should it be a simple lint check (identical to php -l).  The doc
team assumed the later.  Please advise with specific information on how
this should be documented or if this is indeed a bug, say so.

http://cvs.php.net/co.php/phpdoc/en/reference/misc/functions/php-check-syntax.xml




[2004-08-08 18:59:20] phpbug at bigredspark dot com

Bogus? Could someone document this function so we know what the
proper usage is? Is this funtion meant to load the file into the
current scope as it's syntax is checked? If so, please say so in the
documentation. Otherwise, I have another bug report to file.

original.php
?php
$bool = php_check_syntax('checkme.php');
foo();
$bar = new Bar;
$bar-foo();
?

checkme.php
?php
function foo()
{ echo checkme::foo\n; }
class Bar {
function foo()
{ echo checkme::bar::foo\n; }
}
?

results in

checkme::foo
checkme::bar::foo

for example, when my assumption of how the function works should have
the code results in undefined function and class errors.



[2004-04-13 13:12:03] [EMAIL PROTECTED]

Don't misuse the function.




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

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


#30123 [NEW]: sqlite_error_string() to default to last errno

2004-09-16 Thread philip at cornado dot com
From: philip at cornado dot com
Operating system: Irrelevant
PHP version:  Irrelevant
PHP Bug Type: Feature/Change Request
Bug description:  sqlite_error_string() to default to last errno

Description:

This is a feature request for sqlite_error_string() to default to the last
sqlite error rather than require passing in sqlite_last_error(). In
otherwords, make the error_code parameter optional.

Reproduce code:
---
echo sqlite_error_string();
vs
echo sqlite_error_string(sqlite_last_error());



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


#25863 [Csd]: IIS: The specified CGI application misbehaved

2004-09-08 Thread philip
 ID:   25863
 Updated by:   [EMAIL PROTECTED]
 Reported By:  salmanarshad2000 at yahoo dot com
 Status:   Closed
 Bug Type: CGI related
 Operating System: win32 only
 PHP Version:  4CVS, 5CVS, 6CVS..
 New Comment:

People, please do not add comments to this bug report.  If you have a
problem with the IIS documentation, see php bug #25863


Previous Comments:


[2004-09-08 10:06:25] roger dot gusthage at home dot se

I've solved me problem by adding a redirect file between my login page
and start page. This way it seems that my use of header(Location: yada
yada); got some breathing room and could catch up and smoothly go to
my start page instead of throwing a CGI error ...

I use IIS 5, W2000 server with frames on start page and got the error
only when i used header-function above or when i refresh my page
quickly. 

This is not the best solution, but could be usefull in login-situation
where i now put some text to tell the user that the login is
processing.

Redirect i used meta tag and only 1 sec delay.

Hope this might solve the problem for some of you.



[2004-06-29 12:03:00] closedbolt at gmx dot de

Seems like php.exe in php 5 rc3 does not prepend any headers.
-- cgi error in IIS 
php-cgi.exe does... -- works fine for me now.

Example:

test.php 
 ? echo hi; ?

C:\phpphp.exe test.php
hi
C:\phpphp-cgi.exe test.php
Content-type: text/html
X-Powered-By: PHP/5.0.0RC3

hi
C:\php



[2004-06-23 18:38:14] tincanmann at hotmail dot com

Hi, thanks for all the other posts and hopefully this can help someone
else!

I also struggled with this problem of getting PHP to run on IIS.  I
solved it slightly differently on my development server to the live
production server, both running Win2003 Server (production being more
patched, secure, etc).

1) Ensure anonymous access not allowed by editing the website details
in IIS.
This solved my one server but not the other.  However, it all seems to
stem from the security and permissions.

2) Try access the website using https:// instead of http:// ...
strange, I know, but it worked for the production server (and saved me
having to rewrite in ASP).

Gareth



[2004-05-26 15:36:11] onderoz at zmail dot sk

PHP5 Release candidate 2 + IIS5 on W2K Advanced Server.

Still having the same problem.. The damned CGI misbehaved bla bla bla..


I need a complete SOLUTION for this, not WORKAROUND, if we're talking
about a complete language.
What i did :
1.. Downloaded *latest* version of the PHP (5 RC2)
2.. Expanded zip file to the directory C:\PHP5\
3.. added paths to PATH as C:\PHP5;C:\PHP5\EXT as in folder tree.
4.. added extension .php and .php5 with c:\php5\php.exe %s %S
5.. added extension to HKEY_CLASSES_ROOT
6.. added pathinfo to HKEY_LOCAL_MACHINE
7.. gave permissions -full control- to IUSR_*, IWAM_*, EVERYONE on
C:\PHP5 and c:\inetpub\wwwroot\PHP5SCRIPTS
8.. edited php.ini file 
a. cgi.force_redirect=0
b. ;doc_root=

so.. what's next?!?
1.. how should I get this system working with PHP?
2.. do I have to mess with these with every new
installation/upgrade/system change?

thanks folks, for *not* helping us newbies by not providing an
automated system for the installation process.

Onder



[2004-05-08 20:20:53] dmeeking at shaw dot ca

I found that excluding c:\php\ from my (Norton) virus scanner fixed the
problem.  Some comments led me to believe that windows was getting
grumpy when multiple requests were being handled by php.exe.  This made
me wonder if the antivirus was locking the file, since it was set to
scan every exe upon execution.  Turning off scanning on the PHP folder
has fixed this problem for me (iis5 / PHP 4.3.6).



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

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


#29926 [Opn-Bgs]: display_errors setting ignored

2004-09-01 Thread philip
 ID:   29926
 Updated by:   [EMAIL PROTECTED]
 Reported By:  scott at slerman dot net
-Status:   Open
+Status:   Bogus
 Bug Type: *Configuration Issues
 Operating System: Fedora Core 2
 PHP Version:  5.0.1
 New Comment:

Which errors are shown (error level) has to do with error_reporting,
not display_errors.


Previous Comments:


[2004-09-01 05:51:42] scott at slerman dot net

Description:

The php.ini setting display_errors seems to be ignored; no errors are
displayed, even if display_errors is turned on.

Reproduce code:
---
?php
echo ini_get(display_errors) . br/;
echo $foo . bar;
$foo[bar] = phpinfo();
?

Expected result:

There should be warning messages about $foo being undefined and the
constant bar being undefined.

Actual result:
--
Output is:
1
bar

As far as I know, the first line being 1 means that display_errors is
on.





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


#29665 [NoF-Opn]: PHP Fails to compile when soap is enabled

2004-08-30 Thread philip
 ID:   29665
 Updated by:   [EMAIL PROTECTED]
 Reported By:  moontumbo at hotmail dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: Compile Failure
 Operating System: Red Hat Enterprise Linux WS 3.0
 PHP Version:  5.0.1


Previous Comments:


[2004-08-31 01:30:36] clewis at myfonts dot com

I too saw this problem on RedHat Enterprise 3 using 
libxml2 2.5.10.  Upgrading to 2.6.12 solved the problem.



[2004-08-28 16:52:52] michiel at dotgeek dot org

same problem, slack 9.0 
 
$ xml2-config --version 
2.6.12



[2004-08-25 01:00:11] php-bugs at lists dot php dot net

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.



[2004-08-17 23:17:13] ibrash at gaernin dot aswwc dot net

Issue reproduced on Slackware 9.1 with libxml2 2.5.11.



[2004-08-17 08:06:37] [EMAIL PROTECTED]

Which libxml2 did you have installed before?



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

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


#27406 [Opn-Ver]: php_check_syntax executes code

2004-08-26 Thread philip
 ID:   27406
 Updated by:   [EMAIL PROTECTED]
-Summary:  php_check_syntax behavior
 Reported By:  thomas at stauntons dot org
-Status:   Open
+Status:   Verified
 Bug Type: Unknown/Other Function
 Operating System: OS X
-PHP Version:  5.0.0
+PHP Version:  5.0.2-dev
 Assigned To:  iliaa
 New Comment:

Tested latest CVS on a Win32 machine, same problem.  Here's a very
simple test:

randominclude.php
?php
function foobar() {
echo HI;
}
?

checksyntax.php
?php 
if (php_check_syntax('randominclude.php')) {
echo passed; 
foobar(); 
}
?

Calling checksyntax.php via Module/CLI/CGI results in:

passedHI

As opposed to:

passed
Fatal error: Call to undefined function foobar() in ...



Previous Comments:


[2004-08-09 05:10:33] [EMAIL PROTECTED]

So should this function actually execute the code (like an include())
or should it be a simple lint check (identical to php -l).  The doc
team assumed the later.  Please advise with specific information on how
this should be documented or if this is indeed a bug, say so.

http://cvs.php.net/co.php/phpdoc/en/reference/misc/functions/php-check-syntax.xml




[2004-08-08 18:59:20] phpbug at bigredspark dot com

Bogus? Could someone document this function so we know what the
proper usage is? Is this funtion meant to load the file into the
current scope as it's syntax is checked? If so, please say so in the
documentation. Otherwise, I have another bug report to file.

original.php
?php
$bool = php_check_syntax('checkme.php');
foo();
$bar = new Bar;
$bar-foo();
?

checkme.php
?php
function foo()
{ echo checkme::foo\n; }
class Bar {
function foo()
{ echo checkme::bar::foo\n; }
}
?

results in

checkme::foo
checkme::bar::foo

for example, when my assumption of how the function works should have
the code results in undefined function and class errors.



[2004-04-13 13:12:03] [EMAIL PROTECTED]

Don't misuse the function.




[2004-02-26 15:18:57] [EMAIL PROTECTED]

Ilia, maybe this function wasn't such a good idea after all?
Here's the first misuse of it already..




[2004-02-26 11:00:17] thomas at stauntons dot org

Description:

I am writing a class that will include another file 
containing a class that needs to implement a specific 
interface. When calling php_check_syntax on the file its 
behavious differs depending on whether or not the class 
implements my interface. If the file implements my 
interface the class will not show up in 
get_declared_classes() and an include() of the file will 
work, but if the class doesn't implement my interface the 
class will be in get_declared_classes() and the include 
will fail with 'cannot redeclareclass'

Reproduce code:
---
in Main.php
?php
interface MustImplement {}
if (!php_check_syntax('includeme.php'))
die('Bad Syntax\n');
else include('includeme.php');
?
in includeme.php (Case 1)
?php
class AClass implements MustImplement
{}
?
in includeme.php (Case 2)
?php
class AClass
{}
?

Expected result:

Case 1 of includeme.php will work OK, php_syntax_check will 
succeed and include will load the file OK, AClass will be 
available. 

Case 2 will fail, php_syntax_check will work but include 
will fail with 'cannot redeclare class'  Illegal 
Instruction

Actual result:
--
Just as Above. 





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


#27406 [Bgs-Opn]: php_check_syntax behavior

2004-08-08 Thread philip
 ID:   27406
 Updated by:   [EMAIL PROTECTED]
 Reported By:  thomas at stauntons dot org
-Status:   Bogus
+Status:   Open
-Bug Type: Zend Engine 2 problem
+Bug Type: Unknown/Other Function
 Operating System: OS X
-PHP Version:  5.0.0b4 (beta4)
+PHP Version:  5.0.0
 Assigned To:  iliaa
 New Comment:

So should this function actually execute the code (like an include())
or should it be a simple lint check (identical to php -l).  The doc
team assumed the later.  Please advise with specific information on how
this should be documented or if this is indeed a bug, say so.

http://cvs.php.net/co.php/phpdoc/en/reference/misc/functions/php-check-syntax.xml



Previous Comments:


[2004-08-08 18:59:20] phpbug at bigredspark dot com

Bogus? Could someone document this function so we know what the
proper usage is? Is this funtion meant to load the file into the
current scope as it's syntax is checked? If so, please say so in the
documentation. Otherwise, I have another bug report to file.

original.php
?php
$bool = php_check_syntax('checkme.php');
foo();
$bar = new Bar;
$bar-foo();
?

checkme.php
?php
function foo()
{ echo checkme::foo\n; }
class Bar {
function foo()
{ echo checkme::bar::foo\n; }
}
?

results in

checkme::foo
checkme::bar::foo

for example, when my assumption of how the function works should have
the code results in undefined function and class errors.



[2004-04-13 13:12:03] [EMAIL PROTECTED]

Don't misuse the function.




[2004-02-26 15:18:57] [EMAIL PROTECTED]

Ilia, maybe this function wasn't such a good idea after all?
Here's the first misuse of it already..




[2004-02-26 11:00:17] thomas at stauntons dot org

Description:

I am writing a class that will include another file 
containing a class that needs to implement a specific 
interface. When calling php_check_syntax on the file its 
behavious differs depending on whether or not the class 
implements my interface. If the file implements my 
interface the class will not show up in 
get_declared_classes() and an include() of the file will 
work, but if the class doesn't implement my interface the 
class will be in get_declared_classes() and the include 
will fail with 'cannot redeclareclass'

Reproduce code:
---
in Main.php
?php
interface MustImplement {}
if (!php_check_syntax('includeme.php'))
die('Bad Syntax\n');
else include('includeme.php');
?
in includeme.php (Case 1)
?php
class AClass implements MustImplement
{}
?
in includeme.php (Case 2)
?php
class AClass
{}
?

Expected result:

Case 1 of includeme.php will work OK, php_syntax_check will 
succeed and include will load the file OK, AClass will be 
available. 

Case 2 will fail, php_syntax_check will work but include 
will fail with 'cannot redeclare class'  Illegal 
Instruction

Actual result:
--
Just as Above. 





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


#29552 [NEW]: callback function for levenshtein

2004-08-06 Thread philip at cornado dot com
From: philip at cornado dot com
Operating system: Irrelevant
PHP version:  Irrelevant
PHP Bug Type: Feature/Change Request
Bug description:  callback function for levenshtein

Description:

The levenshtein() documentation goes into great detail on a third yet to
be implemented parameter for a levenshtein callback function.  Below are
those docs which will soon be removed from the php manual until this
feature is actually implemented:



The third variant (which is not implemented yet) will be the most general
and adaptive, but also the slowest alternative. It will call a
user-supplied function that will determine the cost for every possible
operation.

The user-supplied function will be called with the following arguments:

* operation to apply: 'I', 'R' or 'D'
* actual character in string 1
* actual character in string 2
* position in string 1
* position in string 2
* remaining characters in string 1
* remaining characters in string 2 

The user-supplied function has to return a positive integer describing the
cost for this particular operation, but it may decide to use only some of
the supplied arguments.

The user-supplied function approach offers the possibility to take into
account the relevance of and/or difference between certain symbols
(characters) or even the context those symbols appear in to determine the
cost of insert, replace and delete operations, but at the cost of losing
all optimizations done regarding cpu register utilization and cache misses
that have been worked into the other two variants.


Attempting to use it gives us:

php_error_docref(NULL TSRMLS_CC, E_WARNING, The general Levenshtein
support is not there yet);

And a return value of -1.


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


#29407 [Csd]: Fatal error: Call to undefined function: bind_textdomain_codeset()

2004-07-27 Thread philip
 ID:   29407
 Updated by:   [EMAIL PROTECTED]
 Reported By:  tv at solnet dot ch
 Status:   Closed
 Bug Type: Gettext related
 Operating System: Freebsd 4.10
 PHP Version:  4.3.8
 New Comment:

And FWIW, from gettext.c source:

#if HAVE_BIND_TEXTDOMAIN_CODESET
PHP_NAMED_FE(bind_textdomain_codeset, zif_bind_textdomain_codeset, 
  NULL)
#endif


Previous Comments:


[2004-07-27 21:37:56] tv at solnet dot ch

It looks like a freebsd port issue only. It doesn't find 
the /usr/local/lib/libintl.so  during the configure of 
php4-gettext. setenv LDFLAGS -L/usr/local/lib and 
recompiling of the php4-gettext port can fix this 
problem (tested on a 5.2.1 machine) 

Many thanks to Torsten Schneider.



[2004-07-27 21:17:48] tv at solnet dot ch

I use gettext 0.13 with the system. The same 
configuration with php 
4.3.7 works fine. But with 4.3.8 this specified 
bind_textdomain_codeset() function 
does not work anymore.



[2004-07-27 15:47:47] tv at solnet dot ch

Description:

Fatal error: Call to undefined function: bind_textdomain_codeset() even
if you have gettext enabled in php4. phpinfo() shows gettext enabled.
Gettext is also isntalled in the code

Reproduce code:
---
?php
// Localisation
$lclang = $LANG;
if( $LANG == de ) $lclang = C;
setlocale( LC_ALL,  );
putenv( LANG=$lclang );
putenv( LANGUAGE=$lclang );
bind_textdomain_codeset( solnetweb, ISO8859-1 );
bindtextdomain( solnetweb, $_SERVER[DOCUMENT_ROOT] .
/translations );
textdomain( solnetweb );

// Remove used variables.
unset( $lclang, $setlang );

?


Actual result:
--
Fatal error: Call to undefined function: bind_textdomain_codeset()





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


#29341 [Opn-Bgs]: $bar = empty(trim($foo)) ? 1 : 0 will generate error

2004-07-22 Thread philip
 ID:   29341
 Updated by:   [EMAIL PROTECTED]
 Reported By:  victor-php at boivie dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: FreeBSD, Windows XP
 PHP Version:  5.0.0
 New Comment:

empty() takes on a variable, and trim($foo) is not a variable.


Previous Comments:


[2004-07-22 21:23:05] victor-php at boivie dot com

Description:

Look at the reproducable code below. 

Reproduce code:
---
$foo = ; // Doesn't matter
$bar = empty(trim($foo)) ? 1 : 0;
echo $bar;

Expected result:

1

Actual result:
--
Fatal error:  Can't use function return value in write context in
bug.php on line 2






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


#29277 [Bgs]: Can't get MySQL extension

2004-07-20 Thread philip
 ID:   29277
 Updated by:   [EMAIL PROTECTED]
 Reported By:  nag at wanadoo dot fr
 Status:   Bogus
 Bug Type: MySQL related
 Operating System: Win2K3
 PHP Version:  5CVS-2004-07-20 (dev)
 New Comment:

If MySQL support was built into your PHP than that would be a bug. 
Read the docs, there is more to do than simply enabling that one DLL:
php.net/mysql


Previous Comments:


[2004-07-20 13:04:40] nag at wanadoo dot fr

Hi !

i have this problem since i try to get working php 5.XX version :

when i want ton load php_mysql.dll, apache return me this error :
can't
load c:\php\ext\php_mysql.dll . Module not found !

the module is in c:\php\ext, i have read the reported bugs about this
subject, but for me in the latest CVS version, the problem still not
fixed, and the mysql support was not build in the latest CVS...

What's about this ?

thanks in advance.

Nag.



[2004-07-20 12:57:19] [EMAIL PROTECTED]

Fix filename first:
c:\php\ext\php_mysql.php -- c:\php\ext\php_mysql.dll



[2004-07-20 12:51:51] nag at wanadoo dot fr

Description:

Hi !

i have this problem since i try to get working php 5.XX version :

when i want ton load php_mysql.dll, apache return me this error :
can't load c:\php\ext\php_mysql.php . Module not found !

the module is in c:\php\ext, i have read the reported bugs about this
subject, but for me in the latest CVS version, the problem still not
fixed, and the mysql support was not build in the latest CVS...

What's about this ?

thanks in advance.

Nag.






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


#26871 [Bgs-Csd]: no build-in mysql support

2004-07-19 Thread philip
 ID:   26871
 Updated by:   [EMAIL PROTECTED]
 Reported By:  marc at campino dot kicks-ass dot org
-Status:   Bogus
+Status:   Closed
 Bug Type: MySQL related
 Operating System: Windows
 PHP Version:  5.0.0b3 (beta3)
 New Comment:

Just a FYI, this was fixed in CVS after this report was created. 
Here's the diff:
http://cvs.php.net/diff.php/php-src/php.ini-recommended?r1=1.148r2=1.149
So I guess this is closed and not bogus, may as well mark it as such
since I'm already here :)


Previous Comments:


[2004-07-19 00:59:18] srwestma at uncc dot edu

I appreciate the link - it did help me.  However, if you could pass a
message on to the people who write the php.ini.dist-recommended, it
might be helpful.  In that file, I found the following line that at
least caused me some confusion: Note that MySQL and ODBC support is
now built in, so no dll is needed for it.  Clearly not the case.

Thanks again [EMAIL PROTECTED] for helping me to find the answer!



[2004-01-11 05:49:19] [EMAIL PROTECTED]

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

See
http://de.php.net/manual/en/faq.databases.php#faq.databases.mysql.php5



[2004-01-11 05:13:38] marc at campino dot kicks-ass dot org

Description:

I installed the Windows version of PHP5 (Beta3) yesterday
Unfortunatly it seems not to have a build in support for MySQL.

But I figuered out that the Linux version of PHP5 _DOES_ have a MySQL
support...

Reproduce code:
---
?php
   phpinfo();
?

Expected result:

Information about the MySQL support 

Actual result:
--
not one evidence about a built-in mysql support.






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


#28007 [Csd-Opn]: FreeTDS support will not compile

2004-07-14 Thread philip
 ID:   28007
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
-Status:   Closed
+Status:   Open
 Bug Type: MSSQL related
 Operating System: Linux
 PHP Version:  4.3.6RC3
 Assigned To:  fmk


Previous Comments:


[2004-07-15 01:18:41] matt at atopia dot net

This still seems to be an issue with php-4.3.8.  Is the patch shown in
this report reliable?

In file included from
/usr/archive/source/php-4.3.8/ext/mssql/php_mssql.c:33:
/usr/archive/source/php-4.3.8/ext/mssql/php_mssql.h:41: redefinition of
`SHORT'
/usr/local/include/sybdb.h:117: `SHORT' previously declared here
*** Error code 1

Stop in /usr/archive/source/php-4.3.8.



[2004-04-21 01:36:12] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Older versions of FreeTDS does not define the SHORT type.



[2004-04-15 19:18:12] [EMAIL PROTECTED]

Assigned to Frank who added the line in question in rev 1.84
of php_mssql.c



[2004-04-15 10:27:22] [EMAIL PROTECTED]

Description:

See bug #21544 -- I was asked to open a new report.

./configure --with-mssql ...   works, but a make of the same fails
with: (see actual result).

FreeTDS version: (debian unstable) 0.53-7

Sniper mentioned that he thinks it's my FreeTDS install. Could be. The
attached patch seems to completely fix the problem, though.

As mentioned in the other bug: I'm not a C guy, so I could be way wrong
on this. All I know is that after patching, --with-mssql compiles and
the library seems to work (as) well (as mssql on linux has ever
worked).

S
---

Index: ext/mssql/php_mssql.c
===
RCS file: /repository/php-src/ext/mssql/php_mssql.c,v
retrieving revision 1.86.2.31
diff -u -r1.86.2.31 php_mssql.c
--- ext/mssql/php_mssql.c   30 Mar 2004 17:54:38 - 
1.86.2.31
+++ ext/mssql/php_mssql.c   14 Apr 2004 15:18:18 -
@@ -336,7 +336,7 @@
dbsetlogintime(MS_SQL_G(connect_timeout));
if (MS_SQL_G(timeout)  0) MS_SQL_G(timeout) = 60;
dbsettime(MS_SQL_G(timeout));
-   dbsetmaxprocs((SHORT)MS_SQL_G(max_procs));
+   dbsetmaxprocs((int)MS_SQL_G(max_procs));

return SUCCESS;
 }


Reproduce code:
---
n/a

Expected result:

compile

Actual result:
--
ext/mssql/php_mssql.c: In function `zm_activate_mssql':
ext/mssql/php_mssql.c:339: `SHORT' undeclared (first use in this
function)
ext/mssql/php_mssql.c:339: (Each undeclared identifier is reported only
once
ext/mssql/php_mssql.c:339: for each function it appears in.)
make: *** [ext/mssql/php_mssql.lo] Error 1





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


#28911 [Bgs]: $_Get and $_Post not avaible

2004-07-06 Thread philip
 ID:   28911
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kae at aals dot ch
 Status:   Bogus
 Bug Type: IIS related
 Operating System: windows XP Workstation
 PHP Version:  4.3.7
 New Comment:

Here's a better test, give us the output after the submit:

html
body
form action=script.php method=POST
 input type=hidden name=atest value=avalue
 input type=submit name=submit
/form
pre
?php
print phpversion() . \n;
print ini_get('variables_order') . \n\n;

print POST:\n;
print_r($HTTP_POST_VARS);
print_r($_POST);

print GET:\n;
print_r($HTTP_GET_VARS);
print_r($_GET);
?
/body
/html


Previous Comments:


[2004-07-06 21:24:45] kae at aals dot ch

Sorry, but read all this script. It's not a case matter.

?php
if ($_POST) {
  echo pMit der Methode POST erhaltene Daten:/p;
  while (list($post_var, $post_value) = each($_POST))
  {
echo $post_var. = .$post_value.br;
  }
}
if ($_GET) {
  echo pMit der Methode GET erhaltene Daten:/p;
  while (list($get_var, $get_value) = each($_GET))
  {
echo $get_var . = .$get_value .br;
  }
}
?



[2004-07-06 15:37:38] [EMAIL PROTECTED]

The variables are called $_GET and $_POST (yes, the case matters!)




[2004-06-30 20:41:08] kae at aals dot ch

I have this php.ini value:
variables_order = EGPCS
register_long_arrays = Off
register_globals = on
register_argc_argv = Off
post_max_size = 8M
gpc_order = GPC



[2004-06-29 17:55:29] [EMAIL PROTECTED]

You should use $_GET and $_POST and check the value of your 
variables_order and gpc_order inside PHP.ini. 



[2004-06-24 14:52:20] kae at aals dot ch

Description:

Hello,
I've installed the IIS 5.1, Windows xp, PHP 4.3.7 exsatly how the
instruction in infos24.de and installmanual (PHP).
Now when i load a form and make an input, then with a button on this
form call the next form (form2), in this form i want display $_post or
$_get and no value is on the variable.

PHP.ini global_registers = off

When i start this form on winows Apache configuration then it's works
correct.

 

Reproduce code:
---
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
HTML
HEAD
TITLEBeispielformular/TITLE
meta http-equiv=Content-Type content=text/html;
charset=iso-8859-1
/HEAD
form action=script.php method=POST
  input type=hidden name=secret_var value=1
Vorname und Familienname:br
  input type=text name=name value=Otto Normalverbraucherbr
Passwort:br
  input type=password name=passwdbr
Geschlecht:br
  input type=radio name=sex value=m mauml;nnlichbr
  input type=radio name=sex value=w weiblichbr
Hobbys:br
  input type=checkbox name=hobbys[] value=computers
Computerbr
  input type=checkbox name=hobbys[] value=sport Sportbr
  input type=checkbox name=hobbys[] value=books
Buuml;cherbr
Kommentar:br
  textarea name=comment rows=4 cols=20/textareabr
input type=submit name=sent value=Abschicken
/form
/html

?php
if ($_POST) {
  echo pMit der Methode POST erhaltene Daten:/p;
  while (list($post_var, $post_value) = each($_POST))
  {
echo $post_var. = .$post_value.br;
  }
}
if ($_GET) {
  echo pMit der Methode GET erhaltene Daten:/p;
  while (list($get_var, $get_value) = each($_GET))
  {
echo $get_var . = .$get_value .br;
  }
}
?

Expected result:

null


Actual result:
--
all Fields and values





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


#28664 [Opn-Ana]: bug database: three letter strings are being ignored

2004-06-24 Thread philip
 ID:   28664
 Updated by:   [EMAIL PROTECTED]
-Summary:  Searching a Bug into Database
 Reported By:  jsgoupil at lookstrike dot com
-Status:   Open
+Status:   Analyzed
 Bug Type: Unknown/Other Function
 Operating System: WinXP
 PHP Version:  Irrelevant
 New Comment:

It works fine but apparently three letter words (in your case the word
'end') are being ignored, could someone with server access check the
mysql ft_min_word_len setting?  It should be set to 3 and not 4
otherwise the PHP code will need updating (see format_search_string()
in functions.inc)

Test words: end, wez, len, str


Previous Comments:


[2004-06-07 06:17:57] jsgoupil at lookstrike dot com

Description:

When I'm searching a bug into the PHP Database, (because i don't want
to post a bug twice), some functions doesn't work correctly !

It could be cool if you can add Version Number and option like  4.1,
4.3, 5

Reproduce code:
---
When you arrive on the Advanced Search Page
Change Return only bugs with status for All
Change Display All Bugs
Search with 2 words (ie. end line)...

With the radio button, if you select, any, all or raw, you got exactly
the same result... the same number of bugs...


Expected result:

any : (default) One or more (any) of the search terms may be present. 
all : All search terms are required. 
raw : Allows full use of MySQL's FULLTEXT boolean search operators. 

Actual result:
--
any, all, raw = same result (i think its an any result)





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


#28544 [Com]: PHP Startup: Unable to load dynamic library ...

2004-06-05 Thread Philip dot Heath at charter dot net
 ID:   28544
 Comment by:   Philip dot Heath at charter dot net
 Reported By:  kalas at atlas dot cz
 Status:   Open
 Bug Type: Dynamic loading
 Operating System: WinXP Pro
 PHP Version:  5.0.0RC2
 New Comment:

I found this on another forum:

the php_mysql.dll extension supports mysql_create_db() and
mysql_drop_db() functions as do the mySQL 3.x client libraries. Fine.
But these 2 functions are dropped in versions 4.x and 5.x of
libmySQL.dll.

Perhaps verifying what version of MySQL libs php_mysql.dll are build
against could shed some light.


Previous Comments:


[2004-05-31 13:32:14] jdiezm at gmx dot de

Hi,

i had the same problem. PHP needs to find *all* DLL's, not only those
in the ext dir. The libmhash.dll, libmysql.dll, etc... are on the
main PHP directory. I copied them to the the extensions directory
(c:\Windows in my case) and everything works now.

Is it a bug that PHP doesnt find those DLL's automatically? 

J.



[2004-05-27 17:47:44] kalas at atlas dot cz

Description:

PHP fails to load any extension, that I enable in php.ini, with error
message (for ex. for php_exif.dll) PHP Startup: Unable to load dynamic
library C:\Program Files\php-5.0.rc2\ext\php_exif.dll'. Any change to
extension_dir doesn't seem to work, I still get the error message
whatever the path is (the modules are really stored there).

I'm running Apache 2.0.49 and PHP as module.

With PHP 4.3.4 it works fine with the same Apache.

Regards,
Radim Kalas






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


#27238 [NEW]: iptcparse() function misses some fields

2004-02-13 Thread philip at nancarrow dot net
From: philip at nancarrow dot net
Operating system: Windows and Linux
PHP version:  4.3.4
PHP Bug Type: GD related
Bug description:  iptcparse() function misses some fields

Description:

The iptcparse() function (GD extension) only returns IPTC/NAA records 2
and upward, skipping past record 1. This appears to be by design, but
means that the returned data is incomplete, for example the destination
dataset 1:05 is missing. Worse that this is the fact that coded character
set (1:90) is missing, and without this value the encoding of the data is
unknown (for example if 1:90 specifies ESC,%,G the data is UTF8 encoded).
I assume that the current implementation is defaulting to ASCII or Latin1
encoding.

I can provide you with JPEG files containing IIM record 1 if required;
they're quite common in the news industry.

Thank you




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


#27238 [Opn]: iptcparse() function misses some fields

2004-02-13 Thread philip at nancarrow dot net
 ID:   27238
 User updated by:  philip at nancarrow dot net
 Reported By:  philip at nancarrow dot net
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Windows and Linux
 PHP Version:  4.3.4
 New Comment:

Pierre,

OK sure, I've put two JPEGs that include IIM record 1 at:

http://www.nancarrow.net/download/testpic1_latin1.jpg

[Latin1 encoded English]

and

http://www.nancarrow.net/download/testpic2_utf8.jpg

[UTF8 encoded Chinese]



The IPTC/NAA (aka IIM) spec is freely downloadable from
http://www.iptc.org/download/download.php?fn=IIMV4.1.pdf and this
details all records include record 1.



Appendix C lists the currently defined character sets, which is
specified in dataset 1:90. Note the strange IPTC terminology - an
octet is a byte, so octet 2/5 means 0x25. The character set
sequence starts with ESC, so where it says ISO-8859-1 is intermediate
character 2/12 to 2/15 followed by octet 4/1 this would be something
like:

ESC,0x2F,0x41

or ESC/A. Similarly UTF8 is ESC,2/5,4/7 or ESC%G.

Where the spec says intermediate character 2/12 to 2/15 most creators
writing the file use the end character, ie. 2/15 in this case.



I'm not sure that PHP really needs to know about the encoding, does it
? Since strings are just byte sequences in PHP I guess it's down to the
application to do the appropriate encoding/decoding... as long as they
have access to the character set of course !



Thanks

Philip


Previous Comments:


[2004-02-13 09:29:23] [EMAIL PROTECTED]

 I can provide you with JPEG files containing IIM record 1

 if required; they're quite common in the news industry.



Please do :)

If you can provide an URL with some images with the required fields and
a txt file for the expected result.



Note that I never read the charset part in any docs about IPTC
standart. Have you a link that describes it?



pierre



[2004-02-13 06:27:10] philip at nancarrow dot net

Description:

The iptcparse() function (GD extension) only returns IPTC/NAA records 2
and upward, skipping past record 1. This appears to be by design, but
means that the returned data is incomplete, for example the
destination dataset 1:05 is missing. Worse that this is the fact that
coded character set (1:90) is missing, and without this value the
encoding of the data is unknown (for example if 1:90 specifies ESC,%,G
the data is UTF8 encoded). I assume that the current implementation is
defaulting to ASCII or Latin1 encoding.

I can provide you with JPEG files containing IIM record 1 if required;
they're quite common in the news industry.

Thank you








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


#20558 [Bgs]: Notice: Undefined variable:

2003-08-04 Thread philip
 ID:   20558
 Updated by:   [EMAIL PROTECTED]
 Reported By:  chat_cha at hotmail dot com
 Status:   Bogus
 Bug Type: Variables related
 Operating System: window 2000
 PHP Version:  4.2.3
 New Comment:

It has to do with your setup, specifically the register_globals
directive.

 * http://www.php.net/support.php


Previous Comments:


[2003-08-04 15:22:32] niklas_u_f at bredband dot net

hello i got a problemI´m about to start my own webserver and domain
name...but i´m just foling around now with windows 2000 server.
so i can learn the software.

but the problem is i get a error message :

Notice: Undefined variable: REMOTE_ADDR in
c:\inetpub\wwwroot\test\online\online.php on line 19

the code is in the online.php :

?

##
# Variablar

$server = x;   // mySQL servern. Oftast localhost, testa
annars 127.0.0.1
$databas = xxx;   // Databasnamn
$anvandare = omc_swe;   // Användarnamn
$losen = xxx;   // Lösenord

$tiden = time()-300;   // Antal sekunder som varje IP skall behållas i
databasen

##
# Script

$conn_online = mysql_connect ($server, $anvandare, $losen);
mysql_select_db ($databas);
$klockan = time();
mysql_query(INSERT INTO online (klockan, ip) VALUES ('$klockan',
'$REMOTE_ADDR'));
mysql_query(DELETE FROM online WHERE klockan  '$tiden');
$antal = mysql_num_rows (mysql_query (SELECT DISTINCT ip FROM
online));
mysql_close($conn_online);

if ($antal == 1)
{
echo $antal aktiv besökare.;
}
else
{
echo $antal aktiva besökare.;
}
?

Please response to my e-mail please



[2002-11-21 21:36:07] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

If you do not want to see notice warnings, set your error reporting
level to E_ALL ^ E_NOTICE



[2002-11-21 21:21:49] chat_cha at hotmail dot com

Where test php code, show error that
Notice: Undefined variable: [var_name] in [file_name.php] on line
[name_line]

How I can do for don't show this error message?

Note : I use IIS for web server.
Thanks




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



#24694 [Fbk]: File upload support does not populate $_FILES, $_POST

2003-07-24 Thread philip
 ID:   24694
 Updated by:   [EMAIL PROTECTED]
 Reported By:  namejko at topiksolutions dot com
 Status:   Feedback
 Bug Type: HTTP related
 Operating System: Windows NT 5.1 build 2000 (XP)
 PHP Version:  4.3.3RC2-dev
 New Comment:

s/gpc_order/variables_order


Previous Comments:


[2003-07-24 21:11:17] [EMAIL PROTECTED]

What is your gpc_order setting set to?



[2003-07-22 12:24:37] namejko at topiksolutions dot com

Apache/1.3.26 (Win32) mod_perl/1.25 mod_ssl/2.8.10 OpenSSL/0.9.6c
DAV/1.0.3 Auth NuSphere/1.0.0 running...

It's from PHPEd, by NuSphere.



[2003-07-22 10:36:54] [EMAIL PROTECTED]

Which webserver are you using? Apache? IIS?




[2003-07-21 17:14:47] namejko at topiksolutions dot com

I did supply a valid upload_temp_dir, and even changed the slashes
around to backslashes to see if that was the problem, but it wasn't.



[2003-07-21 16:51:42] [EMAIL PROTECTED]

If you specify a valid (existing) upload directory via the
upload_temp_dir ini setting does the problem disappear?



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

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



#24784 [NEW]: str_replace count paramater only counts replacements when strlen 1

2003-07-23 Thread philip at cornado dot com
From: philip at cornado dot com
Operating system: linux
PHP version:  5CVS-2003-07-23 (dev)
PHP Bug Type: Strings related
Bug description:  str_replace count paramater only counts replacements when strlen  1

Description:

str_[i]replace() has a count parameter that returns a variable (by
reference) with a count of replacements.  This is not counting when the
search string is one character in length.

Reproduce code:
---
?php
$count = 0;
$str = str_replace('a', '', 'apples are good', $count);

echo $count;
?

Expected result:

2


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



#24784 [Opn]: str_replace count paramater only counts replacements when strlen 1

2003-07-23 Thread philip
 ID:   24784
 Updated by:   [EMAIL PROTECTED]
 Reported By:  philip at cornado dot com
 Status:   Open
 Bug Type: Strings related
 Operating System: linux
 PHP Version:  5CVS-2003-07-23 (dev)
 New Comment:

Actual result is 0.  The bug database didn't allow 0 as an actual or
expected result value, but does now :)


Previous Comments:


[2003-07-23 21:14:27] philip at cornado dot com

Description:

str_[i]replace() has a count parameter that returns a variable (by
reference) with a count of replacements.  This is not counting when the
search string is one character in length.

Reproduce code:
---
?php
$count = 0;
$str = str_replace('a', '', 'apples are good', $count);

echo $count;
?

Expected result:

2






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



#20857 [Csd]: snmpset does not work

2003-07-21 Thread philip
 ID:   20857
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rs at epost dot de
 Status:   Closed
 Bug Type: SNMP related
 Operating System: Linux RH 7.3
 PHP Version:  4.3.0RC2
 New Comment:

PHP 4.3.0 == 4.3.1 with one slight change to the CGI.  So, this patch
exists in PHP as of 4.3.2


Previous Comments:


[2003-07-21 10:26:48] di98mha at student dot bth dot se

This bug still exist under 4.3.1!!
It seems like the patch is not added to this version.

The patch works perfectly fine if you add it in 4.3.1



[2003-01-24 03:54:51] [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.


Patch applied, thanks!




[2003-01-24 02:36:15] jirapat at nstda dot or dot th

on WinNT4, W2K
snmpset function said Couldn't add variable when I try to use it with
version 4.3.0.
But if I use same script with php version 4.2.3 it's work fine in same
environment.
I've found this error on CVS version both 4.3.x and 5.x too.
I tried to copy php_snmp.dll from version 4.2.3 to replace version
4.3.0 script is work again.
So I think this must come from snmp extension from 4.3.0 up.

PS there is no problem with snmpget and snmpwalk



[2003-01-09 08:18:32] steve at deinon dot com

This problem still exists for the php 4.3.0 release.  I am also using
net-snmp 5.0.6

The patch posted by [EMAIL PROTECTED] fixed the problem.  I updated the
offsets in his patch for the 4.3.0 sources.

The updated patch can be found at:
http://www.deinon.com/php/php-4.3.0-snmpset.patch



[2002-12-07 04:35:59] rs at epost dot de

I tried this patch in diff -u format. Note that there is also a change
in the php_error_docref-string, becaue the output was not very
informative. Of course, I would prefer, that a php-snmp maintainer
would have a look at it.

--- snmp.c.orig Mon Nov 11 22:37:18 2002
+++ snmp.c  Sat Dec  7 11:23:24 2002
@@ -197,7 +197,7 @@
 static void php_snmp_internal(INTERNAL_FUNCTION_PARAMETERS,
int st,
struct snmp_session *session,
-   char *objid) 
+   char *objid, char type, char* value) 
 {
struct snmp_session *ss;
struct snmp_pdu *pdu=NULL, *response;
@@ -211,8 +211,6 @@
char buf[2048];
char buf2[2048];
int keepwalking=1;
-   char type = (char) 0;
-   char *value = (char *) 0;
char *err;
 
if (st = 2) { /* walk */
@@ -267,7 +265,12 @@
} else if (st == 11) {
pdu = snmp_pdu_create(SNMP_MSG_SET);
if (snmp_add_var(pdu, name, name_length, type, value)) {
-   php_error_docref(NULL TSRMLS_CC, E_WARNING, Could not 
add
variable: %s, name);
+#ifdef HAVE_NET_SNMP
+   snprint_objid(buf, sizeof(buf), name, name_length);
+#else
+   sprint_objid(buf, name, name_length);
+#endif
+   php_error_docref(NULL TSRMLS_CC, E_WARNING, Could not 
add
variable: %s %c %s, buf, type, value);
snmp_close(ss);
RETURN_FALSE;
}
@@ -466,7 +469,7 @@

session.authenticator = NULL;
 
-   php_snmp_internal(INTERNAL_FUNCTION_PARAM_PASSTHRU, st, session,
Z_STRVAL_PP(a3));
+   php_snmp_internal(INTERNAL_FUNCTION_PARAM_PASSTHRU, st, session,
Z_STRVAL_PP(a3), type, value);
 }
 /* }}} */
 
@@ -849,7 +852,7 @@
session.retries = retries;
session.timeout = timeout;
 
-   php_snmp_internal(INTERNAL_FUNCTION_PARAM_PASSTHRU, st, session,
Z_STRVAL_PP(a8));
+   php_snmp_internal(INTERNAL_FUNCTION_PARAM_PASSTHRU, st, session,
Z_STRVAL_PP(a8), type, value);
 }
 /* }}} */



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

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



#24702 [NEW]: disable_functions + httpd.conf should not set value

2003-07-18 Thread philip at cornado dot com
From: philip at cornado dot com
Operating system: linux
PHP version:  4.3.3RC1
PHP Bug Type: PHP options/info functions
Bug description:  disable_functions + httpd.conf should not set value

Description:

As we all know, setting disable_functions and disable_classes is not
possible in httpd.conf as they are special case PHP_INI_SYSTEM directives,
but doing so still emits a local value even knowing it has no meaning.  In
otherwords, setting disable_* in httpd.conf should not affect the local
ini value as it does currently.

Note: As expected, setting via ini_set() or .htaccess does not affect the
value.

Reproduce code:
---
In httpd.conf:
php_admin_value disable_functions mail

PHP:
echo ini_get('disable_functions');


Expected result:

no value

Actual result:
--
mail

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



#24655 [Opn-Bgs]: unable to set register_global on I am using apache 1.3.x as my web server

2003-07-14 Thread philip
 ID:   24655
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kingquattro at comcast dot net
-Status:   Open
+Status:   Bogus
 Bug Type: PHP options/info functions
 Operating System: Windows xp
 PHP Version:  4.3.2
 New Comment:

You aren't editing the proper php.ini and/or restarting Apache after
changes.  Status-bogus.

http://us2.php.net/manual/en/faq.installation.php#faq.installation.findphpini



Previous Comments:


[2003-07-14 19:12:34] kingquattro at comcast dot net

Description:

I am testing out this ecommerce solution called oscommerce, and it
requires register_global on, I made the changed in php.ini file which
is stored in c:\windows dir. I can't figure out why my brower mozilla
and IE give me the same error, which is 'FATAL ERROR: register_globals
is disabled in php.ini, please enable it!' can any one help me please.
I am usign php 4.3.x and I also downloaded the latest snapshot, but it
still doesn't work. Any help will be great






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



#24656 [Opn-Bgs]: Arrays not accepted transmitted by HTTP GET/POST

2003-07-14 Thread philip
 ID:   24656
 Updated by:   [EMAIL PROTECTED]
 Reported By:  kapp at bigping dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: UNIX/Linux but probabely all
 PHP Version:  5.0.0b1 (beta1)
 New Comment:

PHP expects an array for that, status-bogus.

http://us2.php.net/manual/en/faq.html.php#faq.html.select-multiple



Previous Comments:


[2003-07-14 21:25:47] kapp at bigping dot de

Description:

Normally when you have a 'select-array' in a HTML-form 
using the 'multiple=multiple-Option' you should get 
back an array in PHP.

Unfortunately PHP5 gives back only the last selected 
value instead of an array containing all the selected 
values.

With the supplied HTML/PHP Code you can reproduce this.

Reproduce code:
---
?xml version=1.0 encoding=iso-8859-1?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
   
http://www.w3.org/TR/2000/REC-xhtml1-2126/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=de lang=de
head
meta http-equiv=content-type content=text/html;
charset=iso-8859-1 /
titleUntitled/title
/head
body
form action=form.html method=post
select name=myvar multiple=multiple
option label=first value=num1/option
option label=second value=num2/option
option label=third value=num3/option
option label=fourth value=num4/option
option label=fifth value=num5/option
/select
input type=submit /
/form
p
?php print_r ($_POST); ?
/p
/body
/html

Expected result:

I expect to get back an array containing all the 
selected values.

Actual result:
--
Actually, only the last selected value is given back.





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



#24613 [Opn-Bgs]: MySQL is unavailable as an extension

2003-07-11 Thread philip
 ID:   24613
 Updated by:   [EMAIL PROTECTED]
 Reported By:  rcherry at raysoft dot net
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: XP
 PHP Version:  5.0.0b1 (beta1)
 New Comment:

Duplicate - http://bugs.php.net/bug.php?id=24389


Previous Comments:


[2003-07-11 16:48:14] rcherry at raysoft dot net

Description:

Congratulations on version 5.0 - I really like the OO improvements.

Unfortunately, the test code that I would like to port to 5.0 requires
MySQL.  Unbundling MySQL is OK, but I don't see an extention that I can
enable to bring it back.

Thanks.

Reproduce code:
---
Any call to MySQL will fail.






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



#24615 [Opn-Bgs]: mysql_fetch_array error The result type should be either MYSQL_NUM, MYSQL_ASSO

2003-07-11 Thread philip
 ID:   24615
 Updated by:   [EMAIL PROTECTED]
 Reported By:  prohm at cypos dot de
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: Linux 2.4.21
 PHP Version:  4.3.3RC1
 New Comment:

Read The Fine Manual:
array mysql_fetch_array ( resource result [, int result_type])


Previous Comments:


[2003-07-11 20:49:11] prohm at cypos dot de

Description:

The following function in a class:

function nextrec () {
  if ($this-row = mysql_fetch_array ($this-result,$this-link))
return true;
  return false;
}

give the following error: 
Warning: mysql_fetch_array(): The result type should be either
MYSQL_NUM, MYSQL_ASSOC or MYSQL_BOTH

I have used the newsest CVS-version, there is this error, too.

In the version 4.2.1 is it okay.






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



#22014 [Csd]: html_entity_decode with unset variable results in segfault

2003-07-09 Thread philip
 ID:   22014
 Updated by:   [EMAIL PROTECTED]
 Reported By:  [EMAIL PROTECTED]
 Status:   Closed
 Bug Type: Reproducible crash
 Operating System: Debian LinuxFreeBSD 4.7-STABLE
 PHP Version:  4.3.0
 New Comment:

Just a FYI: 4.3.0 == 4.3.1 (except one tiny security change to the
CGI).  Dericks comment was written before the 4.3.1 security release
issue came up, so he actually refers to this being fixed in 4.3.2


Previous Comments:


[2003-07-09 10:18:18] msw at altexa dot com

reproducible in 4.3.1 on mandrake 9.1 with empty string



[2003-02-02 14:06:44] [EMAIL PROTECTED]

seems already fixed in CVS, can't reproduce with 4.3.1dev but it was
reproducable with 4.3.0.

Derick



[2003-02-02 14:00:12] [EMAIL PROTECTED]

?php html_entity_decode($notset); ?

this results in a segfault, tested on Debian, FreeBSD 4.7-STABLE  and
Gentoo with Apache/1.3.27  PHP 4.3.0





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



#23220 [NoF-Opn]: fgets() causes warning while reading data via SSL channel (HTTPS)

2003-07-07 Thread philip
 ID:   23220
 Updated by:   [EMAIL PROTECTED]
 Reported By:  storozhilov at mail dot ru
-Status:   No Feedback
+Status:   Open
 Bug Type: Filesystem function related
 Operating System: FreeBSD 4.8
-PHP Version:  4.3.1
+PHP Version:  4-STABLE-200307070330
 New Comment:

Status-Open


Previous Comments:


[2003-07-07 00:48:32] severitt at ihug dot co dot nz

After experiencing this same bug with php 4.3.2 on FreeBSD 4.4, I came
searched here and found this bug report.
After reading the comment to try the latest stable version, I compiled
and installed php4-STABLE-200307070330.
 However the problem still remains. It appears that maybe feof() is not
detecting the eof properly, because if I read in less bytes than the
the size of the response, I don't get this warning.



[2003-04-21 09:23:00] [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-04-15 03:27:48] [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

The stable snapshot has better SSL protocol handling and most likely
solves this problem.



[2003-04-15 01:52:09] storozhilov at mail dot ru

?php
  $fd = fsockopen(
'ssl://www.somehost.com',
443,
$errno,
$errstr,
30
  );
  fputs($fd, GET / HTTP/1.0\r\n\r\n);
  while (!feof($fd)) {
echo fgets($fd, 1024);
  );
?
After executing of this script following message appears:
Warning: fgets() [function.fgets]: SSL: fatal protocol error in
/blah/blah/blah/blah.php on line NN

PHP was configured with following arguments:
#!/bin/sh
./configure --with-apache=../apache_1.3.27rusPL30.17 --with-mod_charset
--with-pgsql=/usr/local/pgsql --with-mhash --with-sybase=/usr/local
--with-openssl




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



#24397 [Opn]: Apache 1.3.27 inconsistencies with PHP5

2003-07-05 Thread philip
 ID:   24397
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jlim at natsoft dot com
 Status:   Open
 Bug Type: Apache related
 Operating System: Windows XP
 PHP Version:  5.0.0b1 (beta1)
 New Comment:

This is not a support forum, and this bug of name inconsistencies is
being worked on (note that it's an open bug report).  

Please use http://www.php.net/support for support questions.


Previous Comments:


[2003-07-05 18:00:32] phpbugs at localpin dot com

To me it's a no brainer that all the dlls for v5 should be called
php5apache.dll etc.

Even if the code INSIDE is IDENTICAL to v4.  Who cares what the code is
doing INSIDE?  Outside, if it says it's v5 everyone is happy (I
think?!) - OK, some poor disks everywhere gotta store a php5.dll and a
php4.dll which are identical, but the usability gain everywhere is
huge.

I see 2 choices:
a) you call the dlls php4xyz.dll (v4), php5xyz.dll (v5) etc.
b) you call the dlls phpxyz.dll and distribute different version with
each version.  Nobody expects php.exe in v4 to be the same as php.exe
in v5 for example.

regards,


Hugh,

someone desperately and unsuccessfully struggling to get PHP5 working
with Windows XP and Apache 1.3.something (I could tell you what the
something was if I could get it running) but I get the message I've
seen a lot in these bug reports:

Cannot load c:/php/sapi/php4apache.dll into server: (126) The
specified module could not be found

I've got a v5 copy of php4ts.dll almost everywhere (c:\php,
c:\windows\system32, in with the Apache .exe).  Did I miss one? ;)

I've named the php4_module line to php5_module (sure can't miss that
one reading these bug reports!):

LoadModule php5_module c:/php/sapi/php4apache.dll
AddType application/x-httpd-php .php

If anyone can point me to the source of knowledge on getting this
working I would sure appreciate it.



[2003-07-02 09:50:03] mike at digitalstruct dot com

I believe that the file should also be called php5apache.  The
php4apache breaks consistancy and also makes it harder to run both 4
and 5 side by side.



[2003-06-30 07:25:26] jlim at natsoft dot com

Sorry The extension directory problem is bogus. I confused the php4
php.ini with the php5 php.ini settings. The other bugs mentioned are
still relevant.



[2003-06-29 23:56:56] jlim at natsoft dot com

Description:

Note the funky inconsistency below in the httpd.conf script that i had
to use: php4apache.dll but php5_module

Also the search path for php.ini and other files is WINDOWS/WINNT
directory first. Shouldn't the current directory be first, eg:
.;C:\WINDOWS like in PHP 4.3.2?

Lastly, although the extension directory is correctly set (checked in
phpinfo()), extensions do not appear to load.

Reproduce code:
---
# from httpd.conf script:

LoadModule php5_module c:\php5\php5b1\php4apache.dll
AddModule mod_php5.c
AddType application/x-httpd-php .php






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



#24452 [Bgs]: Installation not possible

2003-07-02 Thread philip
 ID:   24452
 Updated by:   [EMAIL PROTECTED]
 Reported By:  T dot Jansen at ArachNet dot de
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: Windows XP professional
 PHP Version:  5.0.0b1 (beta1)
 New Comment:

What's so unintuitive about this? ;-)

LoadModule php5_module d:/programme/apache2/php/sapi/php4apache2.dll

BTW, this is seen as bogus because it's already come up, the
documentation has been changed in CVS and will show up in the next beta
(or any snap), and there is already an open bug report on the abiguity
of php5 loading a php4.


Previous Comments:


[2003-07-02 03:19:34] titou at ht dot st

And where I can find php5_module ?



[2003-07-02 03:09:42] [EMAIL PROTECTED]

We're using PHP 5 here: php5_module



[2003-07-02 03:01:58] T dot Jansen at ArachNet dot de

On my Computer runs Windows XP professional with Servicepack1, Apache2
and (til yesterday) PHP4, mySQL without of any Problems.
Yesterday i loaded the Beta1 and replaced the PHP-Directory by the new
one. Also the php4apache2.dll and the php4ts.dll have been replaced.
Apache2 is not able to start again.
Following errors have been added to the Event-Logs:
--
The Apache service named  reported the following error:
 Syntax error on line 174 of D:/Programme/Apache2/conf/httpd.conf:  
  
--
The Apache service named  reported the following error:
 Cannot load D:/Programme/Apache2/php/sapi/php4apache2.dll into
server: Das angegebene Modul wurde nicht gefunden.
--

The mentioned Line 174 is the following:

LoadModule php4_module d:/programme/apache2/php/sapi/php4apache2.dll

it worked until i changed the versions, of course the files are on the
selected Path.



[2003-07-02 01:55:10] [EMAIL PROTECTED]

Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to Open.

Thank you for your interest in PHP.




[2003-07-02 01:05:43] T dot Jansen at ArachNet dot de

Description:

It's not possible to install php5. It seems to be a wrong dll-File in
the Package.
I replaced only the old Directory and DLLs, PHP.ini is the same.
Apache2 doesn't start again and tells me my Path is incorrect and
there's a syntax error in the httpd.conf.








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



#24389 [Csd-Fbk]: PHP 5 : Windows build needs a MySQL DLL

2003-07-02 Thread philip
 ID:   24389
 Updated by:   [EMAIL PROTECTED]
 Reported By:  philip at cornado dot com
-Status:   Closed
+Status:   Feedback
 Bug Type: Feature/Change Request
 Operating System: Windows
 PHP Version:  5CVS-2003-06-29 (dev)
 Assigned To:  edink
 New Comment:

ipa, did you copy libmySQL.dll to your SYSTEMROOT?  And/or has this
been fixed in the newest snap?


Previous Comments:


[2003-07-02 13:08:36] enc at omni dot lt

Well, i guess Postgre now will get more attention from PHP Windows
users.



[2003-06-30 16:16:42] ipa at assis dot lt

php_mysql.dll from snap says
PHP Warning:  Unknown(): Invalid library (maybe not a PHP library)
'php_mysql.dll'  in Unknown on line 0



[2003-06-29 20:21:31] [EMAIL PROTECTED]

OK. PHP 5 snaps and distro's include php_mysql.dll (php extension) and
dlls\libmySQL.dll (remember to copy this to the system folder).



[2003-06-29 18:04:40] [EMAIL PROTECTED]

Hm, anyone know where to find non-GPLed libmysql 3.x for windows?



[2003-06-29 14:36:13] philip at cornado dot com

Description:

The Windows distribution of PHP 5 doesn't include a DLL for either
ext/mysql or ext/mysqli support.  Users must compile their own PHP on
Windows to gain this support.

This is a request to make these DLL's available.






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



#24427 [Opn-Bgs]: Can't Find Mysql function

2003-06-30 Thread philip
 ID:   24427
 Updated by:   [EMAIL PROTECTED]
 Reported By:  flyruns at hotmail dot com
-Status:   Open
+Status:   Bogus
 Bug Type: MySQL related
 Operating System: windows 2000 Server sp2(chinese)
 PHP Version:  5.0.0b1 (beta1)
 New Comment:

MySQL is not compiled into the distributed Windows binaries in PHP 5,
like they are in PHP 4, so undefined MySQL functions are expected
here.

And btw, there is no php_mysql.dll in beta1, so wait for beta2 or use a
snap: http://snaps.php.net/


Previous Comments:


[2003-06-30 21:22:52] flyruns at hotmail dot com

Description:

when i install php5

---
copy php5beat1/dlls/* - %SYSTEMROOT%/system32/
copy php5beat1/php4ts.dll - %SYSTEMROOM%/system32/
copy php5beat1/php.ini_dist - %SYSTEMROOT%/php.ini

edit httpd.conf 
  LoadModule php5_module pathto/php5beat1/sapi/php4apache2.dll
  Addmodule module_php5.c

edit php.ini


   http://localhost/phpinfo.php

   i  can't find any mysql info!!



Reproduce code:
---
?php
[EMAIL PROTECTED](localhost,root,) or die(mysql_error());
@mysql_close($conn) or die(mysql_error());
?
OUTPUT---
Fatal error: Call to undefined function: mysql_connect() in C:\Program
Files\Apache Group\Apache2\htdocs\mysql.php on line 2

Expected result:

i think.
what's wrong happend in my install.






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



#24389 [NEW]: PHP 5 : Windows build needs a MySQL DLL

2003-06-29 Thread philip at cornado dot com
From: philip at cornado dot com
Operating system: Windows
PHP version:  5CVS-2003-06-29 (dev)
PHP Bug Type: MySQL related
Bug description:  PHP 5 : Windows build needs a MySQL DLL

Description:

The Windows distribution of PHP 5 doesn't include a DLL for either
ext/mysql or ext/mysqli support.  Users must compile their own PHP on
Windows to gain this support.

This is a request to make these DLL's available.


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



#24366 [Opn-Bgs]: Declaring a function without () produces no output

2003-06-27 Thread philip
 ID:   24366
 Updated by:   [EMAIL PROTECTED]
 Reported By:  fmaillet at vizfx dot ca
-Status:   Open
+Status:   Bogus
 Bug Type: Scripting Engine problem
 Operating System: Windows 2000
 PHP Version:  4.3.1
 New Comment:

I get:
Parse error: parse error, expecting `'('' in /tmp/24366.php on line 6

Be sure to check your error settings, like display_errors and
error_reporting.


Previous Comments:


[2003-06-27 13:46:59] fmaillet at vizfx dot ca

Description:

I'm not sure if this is a bug but I think there should be an error
message. When you declare a function and don't add () before the {, you
get no output at all, not even an error message.

I posted an exemple of code. I know I'm not calling the function but
something should happen. Either This is a test being printed or an
error concerning the function declaration.

Reproduce code:
---
?

echo This is a testbr;

function MyFunction {
 echo This is an other test;
}

?






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



#24337 [NEW]: additional configure --with-avail, and fix --enable-all

2003-06-25 Thread philip at cornado dot com
From: philip at cornado dot com
Operating system: all
PHP version:  4.3.3RC1
PHP Bug Type: Feature/Change Request
Bug description:  additional configure --with-avail, and fix --enable-all

Description:

The following configure options would be nice:

New features:
---
--with-avail   : Compiles in all --with-* extensions that 
 are available on a system.  If not
 available/found, they are skipped.
--enable-avail : Alias to --enable-all as I assume all
 enables are available.  Maybe not?
--with-all : Attempts to compile with all --with-*
 extensions, available or not.

Changed behavior:
---
--enable-all   : Attempts to compile in all --enable-*
 extensions.  Currently this attempts to
 compile in --with and --enable, so can
 be considered broken.

There can also be --without-all and --disable-all although   --disable-all
currently exists, it disables everything, --with or --enable.

So, this is also a request to fix --enable-all or perhaps rename it as
--with-all (but even then it wouldn't be fully accurate).


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



#24326 [Bgs]: Bug of Upload files via PHP

2003-06-25 Thread philip
 ID:   24326
 Updated by:   [EMAIL PROTECTED]
 Reported By:  pixxar at yandex dot ru
 Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: Windows 2000 Professional
 PHP Version:  4.3.3RC1
 New Comment:

Because register_globals = off, so those variables will not exist. 
Post your new form to this:

?php print_r($_FILES) ?


Previous Comments:


[2003-06-25 22:44:03] pixxar at yandex dot ru

After add 'enctype=multipart/form-data' into form tag and 'input
type=hidden name=MAX_FILE_SIZE value=3' betweeen form and
/form tags i'm try upload JPG-file via PHP. Result:
$userfile_tmp_name is empty
$userfile_name is empty
$userfile_size is empty
$userfile_type is empty

I'm copy example code of Upload files via PHP from PHP manual and paste
into my php-file. Result:
$userfile_tmp_name is empty
$userfile_name is empty
$userfile_size is empty
$userfile_type is empty



[2003-06-24 23:16:14] [EMAIL PROTECTED]

Please refer to: 
http://www.php.net/manual/en/features.file-upload.php

You forgot a form attribute.



[2003-06-24 23:13:29] pixxar at yandex dot ru

Description:

Bug of Upload files via PHP

Reproduce code:
---
form action = upload.php method=POST
input type=file name=userfile
/form


Actual result:
--
$userfile_tmp_name is empty
$userfile_name is empty
$userfile_size is empty
$userfile_type is empty
$usefile = filename with path of choosed file 





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



#17739 [Bgs-Fbk]: form select multiple returns double values

2003-06-20 Thread philip
 ID:   17739
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php at remove dot gustl dot net
-Status:   Bogus
+Status:   Feedback
-Bug Type: Unknown/Other Function
+Bug Type: Apache2 related
 Operating System: all
 PHP Version:  4.2.1
 New Comment:

Can you test 4.3.3RC1?  Many Apache2+PHP issues have been fixed since
PHP 4.2.2.  Reporting bugs with PHP 4.2.2 is pretty much useless,
despite what RH ships with.

Download 4.3.3 here:
http://qa.php.net/


Previous Comments:


[2003-06-20 04:31:14] pranav at vigorsoft dot com

This is not bogus. We have also same problems with RH 9.0, apache
2.0.40 and php 4.2.2.



[2003-06-02 20:14:57] sbeam at syxyz dot net

confirmed on RH 9.0 default setup w/ Apache 2.0.40 and PHP 4.2.2 - this
is NOT bogus. Browser used is irrelevant. Please provide fix.



[2003-04-28 18:27:47] mark_andrea at labs dot agilent dot com

I have the same duplicating array value problem when posting values
from a multiple select box [] array using php 4.2.2. Apache 2.0.40. 
GET method does not duplicate the values.  Happens in Netscape 4.08 and
IE 5.5 

Even the $HTTP_RAW_POST_DATA has duplicate values:

multiselect%5B%5D=onemultiselect%5B%5D=twomultiselect%5B%5D=threesubmit=Sendmultiselect%5B%5D=onemultiselect%5B%5D=twomultiselect%5B%5D=threesubmit=Send


Any clues would be appreciated,

Thanks



[2003-03-14 11:54:39] pe_nospam at clearthis dot knoblach dot remove
dot de

by the way this problem seems to appear only in conjunction with Apache
2.0.x! Everything seems to work normally on 1.3

Another thing: In this combination (php2.3.x and apache 2.0.x) the
infamous phpmyadmin sometimes produces strange bugs doing data
inserts/updates. I think this might be related, because the phpmyadmin
insert statements sometimes seem to have duplicate keys and sometimes
look scrambled.

Bye
Peter



[2003-03-14 10:11:57] pe_nospam at clearthis dot knoblach dot remove
dot de

This is a serious problem and it is not bogus!

It has nothing to do with IE but is a php 4.2.x 4.3.x bug!

imorgan (post above) is exactly right. We also watch this behaviour. By
the way we also get some strange string fields, looks like some
scrambled C string field which was not cleared correctly. Definitley
php bug. It was introduced when we updated php 4.0.x to current 4.3.1!
(It did not happen in php 4.0.x)

Pleeease fix it!

Bye
Peter



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

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



#24087 [Fbk-Opn]: Make temporary_directory available in userland

2003-06-19 Thread philip
 ID:   24087
 Updated by:   [EMAIL PROTECTED]
 Reported By:  philip at cornado dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Feature/Change Request
 Operating System: all
 PHP Version:  5CVS-2003-06-08 (dev)
 New Comment:

My initial reason is upload_tmp_dir does not provide a value unless
it's explicitly set, I need this information before sending a file (for
a nice debugging tool that will help the masses).  On the contrary,
session.tmp_path does provide its value regardless of it being
explicitly set or not so that's a weird inconsistency among directive
behavior.  Anyway, knowing TEMPORARY_DIRECTORY will solve my problem
although 'fixing' upload_tmp_dir will also solve it. 

Either way, get_temporary_directory() will need to be called before a
file is uploaded, I don't think it is currently.


Previous Comments:


[2003-06-09 02:49:54] [EMAIL PROTECTED]

I don't really see the use of this. Why would this be useful?



[2003-06-08 22:33:05] philip at cornado dot com

How about making the result from get_temporary_directory() available in
user land, most likely as a constant named TEMPORARY_DIRECTORY  This
would be useful in that we'd know where this is, in both Windows and
*nix.  The code that defines the internal variable temporary_directory
is here:

http://lxr.php.net/source/php4/main/php_open_temporary_file.c#164

I'm not a devel guy, but the following hack seems mildly appropriate:

REGISTER_STRING_CONSTANT(TEMPORARY_DIRECTORY,
get_temporary_directory(), strlen(get_temporary_directory()), 0);

Not sure where to put it though, or if it's fully correct (doubtful),
but please consider this idea as it would be nice.

One *possible* concern is security but I think it's worth it, *maybe*
disable this option in safe_mode.  It's not like the TEMP directory is
a big secret, nor is viewing various related directives like
session.save_path and upload_tmp_dir.




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



#23195 [Opn]: copying an array resets its pointer

2003-06-09 Thread philip
 ID:   23195
 Updated by:   [EMAIL PROTECTED]
-Summary:  Use of $_POST/$_SESSION causes a endless loop
 Reported By:  jc at mega-bucks dot co dot jp
 Status:   Open
-Bug Type: Documentation problem
+Bug Type: Arrays related
 Operating System: Red Hat Linux 8.0
 PHP Version:  4.3.2RC1
 New Comment:

This makes no sense to me, why would assigning an array to another
variable affect the original arrays pointer?  Even the array it's
assigned to keeps the original pointer:

?php
$array = array('a','b','c');

print 1:  . current($array) . \n; // a
print 2:  . next($array). \n; // b

$array2 = $array;

print 3:  . current($array) . \n; // a
print 4:  . current($array2). \n; // b
?

Either $array should also keep its pointer or $array2 should also have
a reset pointer.  I'd assume both would keep the current pointer, or
maybe just $array2 would have a reset pointer :). Current behavior is
certainly not documented, and are you guys sure this isn't a bug?


Previous Comments:


[2003-04-25 00:10:48] jc at mega-bucks dot co dot jp

Thanks for looking into this, but I cannot find anywhere in the
documenation that states that assigning an array to a variable resets
the array's pointer to the first element. Can you point me to such
documentation?

Furthermore if you are right, and I'm sure you are, then some of the
documentation is wrong or confusing at best. Consider the following
from the docs:

http://www.php.net/manual/en/control-structures.foreach.php

 The following are also functionally identical:

 reset ($arr);
 while (list($key, $value) = each ($arr)) {
echo Key: $key; Value: $valuebr\n;
 }

 foreach ($arr as $key = $value) {
echo Key: $key; Value: $valuebr\n;
 }

But has you said, those are *not* functionally identical.


Or from http://www.php.net/manual/en/function.each.php


 each() is typically used in conjunction with list() to traverse an
array; for instance, $_POST:

Example 2. Traversing $_POST with each()

echo Values submitted via POST method:br /\n;
reset ($_POST);
while (list ($key, $val) = each ($_POST)) {
echo $key = $valbr /\n;
}

Reading the documentation on each() and on arrays the above two
examples teach that using a while(list() = each()) is a correct way of
traversing an array. Which it obviously is *not* if you plan on
assigning the array you are traversing to a variable ...

Either the each() function should be removed to force the use of the
assignment-safe 'foreach()' or the documentation should mention that
when assigning an array to a variable the current element-pointer is
reset.



[2003-04-24 19:49:05] [EMAIL PROTECTED]

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

When you assign the array to another variable the internal array
position pointer gets reset. Which causes you loop which depends on the
array position to loop indefinately. 
Use foreach() or a for() loop.



[2003-04-18 21:19:43] [EMAIL PROTECTED]

Here is a  shorter example that demonstrates the problem:
?php
$arr = array('a', 'b'); 
while (each($arr)) $arr2 = $arr;
?



[2003-04-14 01:15:09] jc at mega-bucks dot co dot jp

The following piece of code never terminates:

?php

while (list($k, $v) = each( $_POST )) {
  if(strstr($k, CHANGE_DEL_DATES)) {
session_set_post_vars( $_POST );
  }
}

function session_set_post_vars($post) {
  $_SESSION[S_POST_VALUES] = $post;
}
?

The contents of the $_POST superglobal were:

Array
(
[CURRENT_DEL_METHOD] = YAMATO
[DEL_YEAR1] = 2003
[DEL_MONTH1] = 04
[DEL_DAY1] = 12
[ptime1] = 1
[DEL_YEAR2] = 2003
[DEL_MONTH2] = 04
[DEL_DAY2] = 12
[DEL_YEAR3] = 2003
[DEL_MONTH3] = 04
[DEL_DAY3] = 12
[DELIVER_ANYDAY] = on
[CHANGE_DEL_DATES_x] = 14
[CHANGE_DEL_DATES_y] = 7
)





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



#24087 [NEW]: Make temporary_directory available in userland

2003-06-08 Thread philip at cornado dot com
From: philip at cornado dot com
Operating system: all
PHP version:  5CVS-2003-06-08 (dev)
PHP Bug Type: Feature/Change Request
Bug description:  Make temporary_directory available in userland

How about making the result from get_temporary_directory() available in
user land, most likely as a constant named TEMPORARY_DIRECTORY  This would
be useful in that we'd know where this is, in both Windows and *nix.  The
code that defines the internal variable temporary_directory is here:

http://lxr.php.net/source/php4/main/php_open_temporary_file.c#164

I'm not a devel guy, but the following hack seems mildly appropriate:

REGISTER_STRING_CONSTANT(TEMPORARY_DIRECTORY, get_temporary_directory(),
strlen(get_temporary_directory()), 0);

Not sure where to put it though, or if it's fully correct (doubtful), but
please consider this idea as it would be nice.

One *possible* concern is security but I think it's worth it, *maybe*
disable this option in safe_mode.  It's not like the TEMP directory is a
big secret, nor is viewing various related directives like
session.save_path and upload_tmp_dir.
-- 
Edit bug report at http://bugs.php.net/?id=24087edit=1
-- 
Try a CVS snapshot: http://bugs.php.net/fix.php?id=24087r=trysnapshot
Fixed in CVS:   http://bugs.php.net/fix.php?id=24087r=fixedcvs
Fixed in release:   http://bugs.php.net/fix.php?id=24087r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=24087r=needtrace
Try newer version:  http://bugs.php.net/fix.php?id=24087r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=24087r=support
Expected behavior:  http://bugs.php.net/fix.php?id=24087r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=24087r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=24087r=submittedtwice
register_globals:   http://bugs.php.net/fix.php?id=24087r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24087r=php3
Daylight Savings:   http://bugs.php.net/fix.php?id=24087r=dst
IIS Stability:  http://bugs.php.net/fix.php?id=24087r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=24087r=gnused



#23760 [Opn-Fbk]: using virtual() causes segmentation faults

2003-06-07 Thread philip
 ID:   23760
 Updated by:   [EMAIL PROTECTED]
 Reported By:  php-general at pennysaverusa dot net
-Status:   Open
+Status:   Feedback
-Bug Type: Documentation problem
+Bug Type: Apache related
 Operating System: RedHat 7.3
 PHP Version:  4.3.2RC4
 New Comment:

virtual() works fine on PHP files, as documented (although I can't test
old versions), so I believe sniper was just mistaken and don't see
anything here to document.

Barry, are you sure you set the ulimit before the backtrace?  That's
extremely important.  I'm unable to reproduce and changing back to
Apache related.


Previous Comments:


[2003-06-07 05:04:30] [EMAIL PROTECTED]

What sniper says is not in line with the current manual. The current
manual says that as of PHP 4.0.6 virtual() can be used on PHP files. So
the manual is not correct I assume. Changing this to be a doc problem.



[2003-05-27 13:43:18] php-general at pennysaverusa dot net

I am aware of that.

However, this was not a PHP file. It is merely an html file with a .php
extension.

There is no good reason for it to segfault.

If the policy is that .php files will not be loaded with virtual, then
DON'T LOAD IT. GIVE AN ERROR. DON'T RANDOMLY CRASH.

Random crashes are inexcusable. At least try to make the software
idiot-proof. Give the idiot an error or warning message.

At least, the documentation for virtual should mention this problem if
it's not going to be fixed.

Thank you,
Barry Gould



[2003-05-23 20:53:22] [EMAIL PROTECTED]

FYI: Using virtual() for this is absolutely useless, you really should
be using include(). And as manual says:

virtual() cannot be used to include a document which is itself a PHP
file.

As otherwise the results are unpredictable..
(I didn't get any crash anyway)




[2003-05-23 20:38:23] php-general at pennysaverusa dot net

OK.

To reproduce this,
please download:
http://www2.pennysaverusa.com/barry/virtual_php_crash.tgz

Tested on RC3 and RC4 and php4-STABLE-200305222330
all segfault.

Notes:
1 unset session variable is _not_ enough to trigger the crash. 2
variables seems to be sufficient on my server.

The head and footer files are plain html. I named them with .php out of
habit. With .txt, it does not crash.
I know php won't (or at least shouldn't) parse them as php when using
virtual, so I see no reasonable excuse for it to crash.

As I mentioned before, with DBG enabled or disabled, it still
segfaults.

Thanks,
Barry Gould



[2003-05-22 16:18:24] [EMAIL PROTECTED]

Please provide a complete, self-contained script(s) so we can try and
reproduce this ourselves.




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

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



#24048 [Csd-Bgs]: opendir() drop the previous directory pointer

2003-06-06 Thread philip
 ID:   24048
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mrgibson at golum dot net
-Status:   Closed
+Status:   Bogus
 Bug Type: Reproducible crash
 Operating System: windows 2000
 PHP Version:  4.3.2
 New Comment:

status-bogus


Previous Comments:


[2003-06-05 13:59:23] mrgibson at golum dot net

forget, its my fault not php.



[2003-06-05 13:54:01] mrgibson at golum dot net

A little error:
replace $bof by $temp 

and if ($file[0]==#) continue;
is unnessesary



[2003-06-05 13:51:36] mrgibson at golum dot net

Im running the code as a CLI application, i don't know if the bug
persist with the PHP module or CGI.

This is a little script that show the problem:

?php

 function recurse_search($dir,$pattern)
  { 
  stdout_write(Recurse_search $dir,$pattern);
  $temp = ;
  $len = strlen($pattern);
  $d = @opendir($dir);
  if (!$d) die(Directory $dir not mounted or unavailable);
  clearstatcache();
  while($file = readdir($d))
{

if ($temp != ) break;

if ($file[0]==.) continue;
if ($file[0]==#) continue;

stdout_write($file);
if (is_dir($dir.$file./))
{
stdout_write(DIR : $file);
$bof = 
recurse_search($dir.$file./,$pattern);
}
else
if (substr($file,0,$len)==$pattern)

{
close($d);
die($dir.$file);
return $dir.$file;
}

  
}
  closedir($d);
  return $temp;
  }
}

  function stdout_write($content)
  {
  $fp = fopen(php://stdout,w);
  fwrite($content.\r\n);
  fclose($fp);
  }

print recurse_search(c:\\,system.ini);
?

When i get back from a prior directory recursion, the
$file = readdir($d) stop working and the function exit.









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



#12312 [Opn]: array_mt_rand() ?

2003-06-06 Thread philip
 ID:   12312
 Updated by:   [EMAIL PROTECTED]
 Reported By:  lramsey at crystalorb dot net
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Linux 2.4.3
 PHP Version:  4.0.6
 New Comment:

Why not just rewrite array_rand() and shuffle() to instead use
mt_srand()?  It is superior after all...  And seeding takes place
automatically as of PHP 4.2.0


Previous Comments:


[2003-06-06 14:54:06] [EMAIL PROTECTED]

There is no 'array_shuffle()' and shuffle() uses rand too.
Having array_mt_rand() is quite good idea. 





[2003-05-31 10:37:15] [EMAIL PROTECTED]

Does array_shuffle() solve this?



[2001-07-22 21:23:20] lramsey at crystalorb dot net

As the mt_rand() algorithim creates better random numbers than rand(),
would it be possible to include in future releases of the language to
include a version of array_rand() that uses mt_rand()?




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



#23964 [WFx]: Multi-dimensional array sum

2003-06-05 Thread philip
 ID:   23964
 Updated by:   [EMAIL PROTECTED]
 Reported By:  prof_moriarty at veryfast dot biz
 Status:   Wont fix
 Bug Type: Feature/Change Request
 Operating System: Win98 se
 PHP Version:  4.3.2
 New Comment:

Think of it this way.  This is bug #23964, that's a lot of bugs.  I
can't speak for anyone else but know that Derick closes many bugs and
is constantly working to improve PHP.  Maybe he saw this report and
feels there are many more pressing needs than adding another array
function, especially one that can be done fairly easy in userspace. 
I'm not proposing anything here, but here's a version with some
checks:

function array_sum_multi($arr, $key) {
if (!is_array($arr)) {
return false;
}
$sum = 0;
foreach ($arr as $info) {
if (isset($info[$key])  is_numeric($info[$key])) {
$sum += $info[$key];
}
}
return $sum;
}

Basically, if I were you, I wouldn't lose too much sleep over it, or
take it personally.  Also, you will notice that your request is a
duplicate of a preexisting feature request for this same feature, see
also:

http://bugs.php.net/bug.php?id=12028

It's the same idea but a different implementation (which one is
correct? ;), and it remains open...


Previous Comments:


[2003-06-04 19:44:03] prof_moriarty at veryfast dot biz

you are a Humbug...
:(

I can't code in C, and i'm not planning on adding it to my repertouir
any time soon.

Maybe i should say that next time someone else makes a suggestion for
my online game. Tell them to write it themselves, and still turn it
away...

There goes me ever trying to be helpful with PHP's dev in the
future

There should be more 'pollita's / MGF's and less Dereks in the
world...

Ungratefully. :(
Me



[2003-06-04 11:35:50] [EMAIL PROTECTED]

blah blah, write a patch yourself if you want this sooo badly. But then
still, the chance of being it included in PHP is sli,.



[2003-06-04 10:15:14] prof_moriarty at veryfast dot biz

Unless you hadn't noticed, there isn't really much 'multi-level'
functionality in PHP anyway!?!?! (as in the ability to manipulate them
easily).
Let's see what we can find:

array_multisort : great function.

that's really about it. Sure numerous other functions can mess with
them, but mostly you'd have to put them into a loop to actually get
through all the dimensions.
Even the noted 'array_sum' doesn't work with multi-dimensionals (or at
least i spotted a post somewhere in this bug collection that stated as
much).


When you say would be much slower, Do you mean from a processing
front (several micro seconds), or from a coding front (in which case
any proposed function would be quicker than writing it yourself)?
If you mean by time, then i'd only have to guess (noting my lack of
knowledge of benchmarking and C/++) that the proposed function would
actually gain a speed boost from being written into PHP's core,
primarily because it requires a loop (and on each iteration, a little
more time would be gained over a PHP implementation).


As you can probably tell, i don't plan on abandoning this little
function without a fight, simply because it can be 'user implemented'
(which i recognise and appreciate is a criteria for inclusion).



[2003-06-04 09:58:00] [EMAIL PROTECTED]

I also think we shouldn't add the multilevel functionality here, as
it's pretty easy to do in userspace (yes, array_sum() should have been
something for userspace too). All other functions you mentioned *can*
be done in userspace, but would be much slower.



[2003-06-04 09:54:56] prof_moriarty at veryfast dot biz

Yes, but that's not the point.
array_sum can be done in user_space.
as can:
array_fill,
array_pad,
array_pop
array_push
array_rand
array_count_values

Indeed, most of the array_ function can be done with a couple of lines
of code.

i.e. array_push:
From the manual:
Has the same effect as: 

$array[] = $var;


That's just ONE line of code, and an apricot could get in it's sleep.
:)


Noting that it was only the third attempt that got it even relatively
correct, it goes to show that it's not so simple... (i've been playing
with PHP for 2+ years, and the other wrong one was a @php.net type!!!)

So could someone _please_ unset this as 'won't fix' (seeing as i
can't), and reset to 'open?

Thanx



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

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



  1   2   3   >