#49874 [Com]: ftell()/fseek() inconsistency when using stream filters

2009-10-14 Thread jketterl at chipxonio dot de
 ID:   49874
 Comment by:   jketterl at chipxonio dot de
 Reported By:  jketterl at chipxonio dot de
 Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: linux (ubuntu)
 PHP Version:  5.2.11
 New Comment:

thanks for having a look

i tried with and without. the challenge is to get it working without,
because that's the worst case my app has to deal with, but the BOM
doesn't seem to solve this.

$ hexdump test-with-bom.csv
000 feff 004c 0069 006e 0065 0020 0030 0031
010 000a 004c 0069 006e 0065 0020 0030 0032
020 000a 004c 0069 006e 0065 0020 0030 0033
030 000a 004c 0069 006e 0065 0020 0030 0034
040 000a
042

$ php test.php
string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(5) "e 01
"

i also tried opening the file including the BOM without a stream
filter, but that just resulted in php reading in two extra chars (the
BOM converted in some way i guess) on the beginning of the first line.

i thought i'd attach the sample files to this bug, but it seems like i
can't. i've uploaded them here instead:
http://www.djmacgyver.net/tmp/php-ftell/


Previous Comments:


[2009-10-14 16:40:00] sjo...@php.net

Thank you for your bug report. Does your test.csv file start with a
BOM? You can determine this by viewing the file in a hex editor. If it
starts with fffe or feff, it has a BOM (byte order mark).



[2009-10-14 11:39:39] jketterl at chipxonio dot de

Description:

exact php version: PHP 5.2.11-0.dotdeb.1 with Suhosin-Patch 0.9.7 (cli)
(built: Sep 20 2009 09:41:43)
this bug is also be filter-/stream-related. i just believe it might be
easier to fix on the filesystem side, that's why i chose that category.

when using a php stream filter to convert input from utf-16 into
iso8859 (or most probably from any 2byte-encoded charset into any
single-byte-encode charset) the ftell() and fseek() functions start to
behave inconsistently.

more precisely: fseek() jumps to exact offsets ignoring the
2byte-encoding, whereas ftell() seems to return the number of bytes read
*after* the filter has been applied. thus it is not possible to fseek()
back to a certain offset that has been stored with ftell() before.

the content of the testfile used in the code examples is as follows:
Line 01
Line 02
Line 03
Line 04

Reproduce code:
---
$file = 'test.csv';

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
$line = fgets($fp);
var_dump($line);
fclose($fp);

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
fseek($fp, ftell($fp)); // this shouldn't move anything - but it
does...
$line = fgets($fp);
var_dump($line);
fclose($fp);

Expected result:

string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(8) "Line 02
"

Actual result:
--
string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(4) " 01
"





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



#49883 [Opn->Bgs]: The parser doesn't distinguish periods after integers as concatenations

2009-10-14 Thread scottmac
 ID:   49883
 Updated by:   scott...@php.net
 Reported By:  svavar at kjarrval dot is
-Status:   Open
+Status:   Bogus
 Bug Type: Compile Failure
 Operating System: FreeBSD 7.2
 PHP Version:  5.2.11
 New Comment:

Surround your expression with parentheses to get your expected
behavior.

The lexer treats this as a float, not the parser.


Previous Comments:


[2009-10-15 01:27:04] svavar at kjarrval dot is

Description:

The parser thinks that a period after an integer must mean the number
is a float, even though the period represents a concatenation of a
string.

Reproduce code:
---


Expected result:

To see the following output:

2 seconds

Actual result:
--
The parser outputs a syntax error:

unexpected T_CONSTANT_ENCAPSED_STRING, expecting ',' or ';'





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



#39078 [Com]: Plus sign in URL arg received as space

2009-10-14 Thread yolcoyama at gmail dot com
 ID:   39078
 Comment by:   yolcoyama at gmail dot com
 Reported By:  main at springtimesoftware dot com
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Windows XP
 PHP Version:  5.1.6
 New Comment:

Since I encountered the same problem in php,
I wondered the cause of bug is really the php.
Chosing another script language (python) to attest,
in python (cgi), following code with query "q=c++" yields output of:
{'q': ['c  ']}.
This shows that plus-sign is replaced with blank space independently on
language (at least not only in php).

I found a solution (not fundamental) to receive query arithmetic
characters
as raw string: rawurldecode(urlencode($whatever_qs))

It behaved as if blank space is restored to plus-sign (or other
arithmetics sign).

* index.py
#!/usr/bin/python
import cgi,os
print "Content-Type: text/plain; charset=utf-8"
print
print cgi.parse_qs(os.environ['QUERY_STRING'])

Shinobu Y.


Previous Comments:


[2009-10-06 17:05:38] toby dot walsh at fxhome dot com

I believe derick probably meant to link to rfc 2396

http://www.ietf.org/rfc/rfc2396.txt

It says...


Many URI include components consisting of or delimited by, certain
   special characters.  These characters are called "reserved", since
   their usage within the URI component is limited to their reserved
   purpose.  If the data for a URI component would conflict with the
   reserved purpose, then the conflicting data must be escaped before
   forming the URI.

  reserved= ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","


notice the "+" symbol is now in the reserved list.

This issue is confusing because the old rfc did indeed say that the "+"
symbol did not need to be encoded. The new rfc 2396 actually draws
attention to this change.


G.2. Modifications from both RFC 1738 and RFC 1808

Changed to URI syntax instead of just URL.

Confusion regarding the terms "character encoding", the URI
"character set", and the escaping of characters with %
equivalents has (hopefully) been reduced.  Many of the BNF rule names
regarding the character sets have been changed to more accurately
describe their purpose and to encompass all "characters" rather than
just US-ASCII octets.  Unless otherwise noted here, these
modifications do not affect the URI syntax.

Both RFC 1738 and RFC 1808 refer to the "reserved" set of characters
as if URI-interpreting software were limited to a single set of
characters with a reserved purpose (i.e., as meaning something other
than the data to which the characters correspond), and that this set
was fixed by the URI scheme.  However, this has not been true in
practice; any character that is interpreted differently when it is
escaped is, in effect, reserved.  Furthermore, the interpreting
engine on a HTTP server is often dependent on the resource, not just
the URI scheme.  The description of reserved characters has been
changed accordingly.

The plus "+", dollar "$", and comma "," characters have been added to
those in the "reserved" set, since they are treated as reserved
within the query component.


So I believe PHP is correct to decode the "+" as a " ".

You should be using the javascript function encodeURIComponent() to 
escape your strings. encodeURIComponent will encode "+" chars properly.
Here's a good page which shows the difference between javascripts
encoding functions.

http://xkr.us/articles/javascript/encode-compare/



[2009-08-10 15:02:31] boriss at web dot de

I'd like to see an option to change runtime behavior of PHP, too. Even
if the Javascript function escape() would work a user could still enter
an URL with a query string himself. Imagine you have a search engine and
someone enters an URL with ?query=C++. If you use $_GET['query'] you
just don't know if someone searches for "C++" or "C  ".



[2008-07-16 20:18:49] edA-qa at disemia dot com

I would also like to add that decoding '+' to a space is just plain
wrong. I got burnt again by this when using base64_encode, which should
produce URL safe strings, but for PHP it doesn't, since it may include
the '+'.

A global option to use the proper rawurldecode would be great. 
Otherwise I'm stuck, like many developers, in reparsing the query
string/url manually and unable to use _POST and _GET.



[2008-06-12 00:25:52] jerm at live dot com

I'm with David on this.

On the client-side, I'm using the JavaScript escape() function to
encode data for sending to the server using a POST ajax request.
(Original bug report refers to $_GET, but this is also affecting
$_POST)

The server sees both plus signs "+" and "%20" as spaces. And yes, PHP
is seeing the plus, untou

#49883 [NEW]: The parser doesn't distinguish periods after integers as concatenations

2009-10-14 Thread svavar at kjarrval dot is
From: svavar at kjarrval dot is
Operating system: FreeBSD 7.2
PHP version:  5.2.11
PHP Bug Type: Compile Failure
Bug description:  The parser doesn't distinguish periods after integers as 
concatenations

Description:

The parser thinks that a period after an integer must mean the number is a
float, even though the period represents a concatenation of a string.

Reproduce code:
---


Expected result:

To see the following output:

2 seconds

Actual result:
--
The parser outputs a syntax error:

unexpected T_CONSTANT_ENCAPSED_STRING, expecting ',' or ';'

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



#49882 [Opn->Asn]: imagelayereffect() not available with shared GD

2009-10-14 Thread pajoye
 ID:   49882
 Updated by:   paj...@php.net
 Reported By:  woody dot gilk at kohanaphp dot com
-Status:   Open
+Status:   Assigned
 Bug Type: GD related
 Operating System: Mac OSX 10.5
 PHP Version:  5.3.0
-Assigned To:  
+Assigned To:  pajoye
 New Comment:

Quick note: It is not due to the bundled GD usages but the new feature
in the configure script on php 5.3. This feature enables the bundled new
functions even when the extension is built against the system library.
imagelayereffect was forgotten.


Previous Comments:


[2009-10-15 00:12:55] woody dot gilk at kohanaphp dot com

Description:

Using shared GD with PHP 5.3.0 should work the same as using --with-
gd=php. However, this is not true.

Reproduce code:
---
~> php -r 'var_dump(PHP_VERSION);'
string(5) "5.3.0"
~> php -r 'var_dump(function_exists("imagerotate"));'
bool(true)
~> php -r 'var_dump(function_exists("imagelayereffect"));'
bool(false)

Expected result:

I expected the last command to show "bool(true)".

Actual result:
--
It shows "bool(false)".





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



#49882 [NEW]: imagelayereffect() not available with shared GD

2009-10-14 Thread woody dot gilk at kohanaphp dot com
From: woody dot gilk at kohanaphp dot com
Operating system: Mac OSX 10.5
PHP version:  5.3.0
PHP Bug Type: GD related
Bug description:  imagelayereffect() not available with shared GD

Description:

Using shared GD with PHP 5.3.0 should work the same as using --with-
gd=php. However, this is not true.

Reproduce code:
---
~> php -r 'var_dump(PHP_VERSION);'
string(5) "5.3.0"
~> php -r 'var_dump(function_exists("imagerotate"));'
bool(true)
~> php -r 'var_dump(function_exists("imagelayereffect"));'
bool(false)

Expected result:

I expected the last command to show "bool(true)".

Actual result:
--
It shows "bool(false)".

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



#49853 [Com]: Soap Client stream context header option ignored

2009-10-14 Thread rumana024 at yahoo dot com
 ID:   49853
 Comment by:   rumana024 at yahoo dot com
 Reported By:  rumana024 at yahoo dot com
 Status:   Open
 Bug Type: SOAP related
 Operating System: Windows XP
 PHP Version:  5.2SVN-2009-10-12 (SVN)
 New Comment:

I see a conversation at
http://aspn.activestate.com/ASPN/Mail/Message/php-dev/3710449 about
Transfer-Encoding: chunked and its affect on stream_context parameters.
Is this the problem?


Previous Comments:


[2009-10-14 19:37:32] rumana024 at yahoo dot com

Is this a PHP bug? If not,can you please post some sample !working!
code on creating a SOAP Client with the stream_context option and http
header(in this case https). Those headers can be seen as the part of the
http request headers. I have pretty much tried different suggestions
that I read on diffrent threads on www and php.net to make a successful
soap call.

Regards
RI



[2009-10-13 18:03:07] rumana024 at yahoo dot com

$headers = array('X-USERID: user_1253314668.com\r\n', 
'Content-type: application/x-www-form-urlencoded\r\n',
'X-PASSWORD: 1253314679\r\n',
'X-SIGNATURE:
AtQaNHC.hbpghF5uGCRO99PVYV7ki3.SAb3vQzBlBAxEyi0b\r\n',
'X-VERSION: 1.2.0\r\n',
'X-PROTOCOL: SOAP11\r\n',
'X-SOURCE: PHP_SOAP_SAMPLE_V1\r\n');

$context = stream_context_create(array('http' => array('header' =>
$headers)));

$soapClient = new SoapClient(null,array('location' =>
"https://svcs.sandbox.com/Method1/";, 
'uri' =>
"http://x.x.com/types/test";, 
'soap_version' =>
SOAP_1_1,'trace' => 1, 'stream_context' => $context)); 



//Constructing the Payload
$param = "the payload"
$result = $soapClient->Method1($params);


I have changed the wrapper from https to http. Also made the header an
array. Still the same error. I do not see the http header with other
http headers when print the $soapClient->_getLastRequestHeaders().
Please advice how to resolve the issue.



[2009-10-13 10:48:05] sjo...@php.net

Thank you for your bug report.

Please try 'http' as wrapper name instead of 'https'.



[2009-10-12 23:18:28] rumana024 at yahoo dot com

Description:

Hi:


I am using PHP Soap PHP-SOAP/5.2.9-2 to connect to a web service. Part
of the reqiurment is that , few http headers need to be as part of the
request, but not part of the soap envelope. I am using the stream
context option and add the http headers with that option. Unfortunately,
the stream context is not being read at all. 




Reproduce code:
---
Here is my code 


$opts = array(
  'https'=>array(
'method'=>"GET",
'header'=>'X-SECURITY-USERID: seller_1253314668_biz_api1.x.com\r\n'
. 
  'X-SECURITY-PASSWORD: 1253314679\r\n' .
  'X-SECURITY-SIGNATURE:
AtQaNHC.hbpghF5uGCRO99PVY6a2ASO58V7ki3.SAb3vQzBlBAxEyi0b\r\n' .
  'X-SERVICE-VERSION: 1.2.0\r\n' .
  'X-MESSAGE-PROTOCOL: SOAP11\r\n' .
  'X-REQUEST-SOURCE: PLATFORM_JAVA_SOAP_SAMPLE_V1\r\n' .
  'X-APPLICATION-ID: APP-80W284485P519543T\r\n'));


$context = stream_context_create($opts);


$soapClient = new SoapClient(null,array('location' =>
"https://svcs.sandbox.x.com/AP/Method1/";,
'uri' =>
"http://svcs.x.com/types/ap";, 
'soap_version' => SOAP_1_1,
'trace' => 1, 'stream_context' => $context));



 

Expected result:

Security Credential are going as HTTP Headers and the Http headers are
contained in the context parameter. I get the result Invalid User name
and Password. So the context is not going through at all.
I know for sure the credentials are valid.

I know other option parameter like 'location', 'uri' are working.Please
advice how to fix this problem.






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



#40479 [Com]: zend_mm_heap corrupted

2009-10-14 Thread tulio dot silva at mpt dot gov dot br
 ID:   40479
 Comment by:   tulio dot silva at mpt dot gov dot br
 Reported By:  rrossi at maggioli dot it
 Status:   No Feedback
 Bug Type: Reproducible crash
 Operating System: Suse Linux 9.0
 PHP Version:  5.2.1
 New Comment:

Hi all,
in answer to sriram above, here we go:

-bash-3.00$ /usr/local/apache2/bin/httpd -V
Server version: Apache/2.2.13 (Unix)
Server built:   Oct  5 2009 10:20:45
Server's Module Magic Number: 20051115:23
Server loaded:  APR 1.3.8, APR-Util 1.3.9
Compiled using: APR 1.3.8, APR-Util 1.3.9
Architecture:   64-bit
Server MPM: Prefork
  threaded: no
forked: yes (variable process count)
Server compiled with
 -D APACHE_MPM_DIR="server/mpm/prefork"
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
 -D APR_USE_SYSVSEM_SERIALIZE
 -D APR_USE_PTHREAD_SERIALIZE
 -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=128
 -D HTTPD_ROOT="/usr/local/apache2"
 -D SUEXEC_BIN="/usr/local/apache2/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_LOCKFILE="logs/accept.lock"
 -D DEFAULT_ERRORLOG="logs/error_log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

So it is prefork. If ZTS is enabled with --enable-maintainer-zts, then
it´s off. Also, from phpinfo(),
Debug Build no 
Thread Safety   disabled 
Zend Memory Manager enabled

and it seems USE_ZEND_ALLOC=0 does nothing for me. I´m on CentOS 4.6 on
multi-core AMD64, with nearly 1GB RAM and a very busy server. There are
plenty of custom systems in this machine, so I can´t tell what is
causing it, but it started after we began using Elxis 2009.0 in
production state (about 15 hits/second).

My configure lines includes a lot of other parameters, like oci and
MySQLi, but if of any use, I´ll compare the relevant items with rrossi´s
(bug opener) config.nice:
'./configure' \
'--with-apxs' \ # idem
'--with-mysql=/usr/local/mysql' \ #'--with-mysql=/usr' (CentOS rpm)
'--with-bz2' \ # no
'--with-mcrypt' \ #no
'--with-pgsql' \ #no
'--without-pear' \ # --with-pear

Apache also includes a lot of modules. The most relevant, I guess, are
rewrite, proxy (http & ajp), ssl, and cache. If any other info needed,
feel free (and please) contact me. It´s been a serious problem down
here.


Previous Comments:


[2009-09-18 08:24:48] tdikarim at hotmail dot com

Hi ,

I have tested with the version 5.3 of PHP with no success.
I have this error:
Fatal error: Out of memory (allocated 564920320) (tried to allocate
39063398 bytes) in I:\srvDevPHP\PHP_PEAR\File\PDF.php on line 3191
zend_mm_heap corrupted
The line 3191 is << $this->_buffer .= $s . "\n"; >> of the _out
function.

How can i use the USE_ZEND_ALLOC parameter. I don't find any file for
do that.
Somme info:
EasyPhp 2.0.0.0
 php 5.3.0
 Apache 2.2.13

Thanks
Karim



[2009-09-18 07:39:11] tdikarim at hotmail dot com

I bring some additional information.
The error occurred with the version of PHP 5.2.1 and version 2.2.13 of
Apache.

This is done by creating a large PDF to do more than 35,000 pages using
File_pdf (last release) PEAR.

I just installed version 5.3 and I'm going with this test without using
USE_ZEND_ALLOC.

For your information, I find pale apachectl.bat file in my apache
directory.

I install apache and php via EasyPhp v2.0.0.0
I advise you to install something else?

I will keep you informed of my test with version 5.3. It will take a
few hours

Again thank you
Karim



[2009-09-17 18:13:48] sriram dot natarajan at gmail dot com

to answer tdikarim at hotmail dot com's question, you can probably add

set USE_ZEND_ALLOC=0 within your apachectl.bat under your apache 
installation directory /bin. not, for this to work, you should start 
apache from command line and not as a 'service'. also, may I suggest 
that you probably try to run with php 5.2.10 or php 5.3 (from 
windows.php.net) and see if you are able to reproduce this issue 
before you consider using the work around (using USE_ZEND_ALLOC). 
please note that using USE_ZEND_ALLOC=0 will have some performance 
penalty. 

now, looking closely into this bug, as Rasmus mentioned earler, this 
bug has become a catch-all for memory corruption.

looking at the some of the stack traces and with so many people have 
reported this , this is probably a valid bug and we would love to fix 
this issue provided some one can provide us a script (even if it is 
complicated) that any one of us can reproduce. this would quickly help

us to get to a solution. 

some of the folks have mentioned that they use redhat / fedora but 
have failed to mention whether they are using php with apache's 

#49829 [Csd]: ./configure --with-mysql=mysqlnd gave configure error

2009-10-14 Thread uw
 ID:   49829
 Updated by:   u...@php.net
 Reported By:  eddychu at yahoo dot com
 Status:   Closed
 Bug Type: Compile Failure
 Operating System: CentOS 5.3
 PHP Version:  5.3.0
 New Comment:

Thanks for getting back and closing. It is correct that with mysqlnd
there should be no need to have any MySQL components installed on the
PHP build host. 


Previous Comments:


[2009-10-14 19:47:00] eddychu at yahoo dot com

On my CentOS 5.3, after uninstalling MySQL-server-community 5.1.34 and
MySQL-client-community 5.1.34 and install mysql-server 5.0.77 and mysql
5.0.77, it started to work.  Note that I don't need mysql-devel for this
to work.



[2009-10-12 19:56:39] srina...@php.net

also, for these kind of configure errors, it is better if you provide
with the corresponding error you noticed inside config.log file (created
under the same location where you are trying to build).

as sjoerd suggested, you probably don't have mysql develop rpm
installed on your system.



[2009-10-12 13:01:18] u...@php.net

Works fine for me. Please make sure that configure is sane: 

rm configure ; ./buildconf --force ; ./configure  --with-mysql=mysqlnd
--with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd




[2009-10-10 12:11:31] sjo...@php.net

Thank you for your bug report.

Have you installed the MySQL development files, from the mysql-devel
package?



[2009-10-10 02:12:33] eddychu at yahoo dot com

Description:

Followed http://us.php.net/manual/en/mysqlnd.install.php instructions
to attempt to configure PHP to build with mysqlnd support, but it gave
error:

configure: error: Cannot find MySQL header files under mysqlnd,.
Note that the MySQL client library is not bundled anymore!

although ext/mysqlnd folder is right there under php-5.3.0.  And no
Makefile was generated so I can't build PHP.  Either the instructions
are wrong or the configure scripts are wrong.

Reproduce code:
---
---
>From manual page: mysqlnd.install
---
Simply try to configure with mysqlnd:

./configure --with-mysql=mysqlnd, --with-mysqli=mysqlnd and
--with-pdo-mysql=mysqlnd

Expected result:

Expected ./configure --with-mysql=mysqlnd, --with-mysqli=mysqlnd and
--with-pdo-mysql=mysqlnd to successfully generate the Makefile.  If
other configure option(s) are required for these to work, they should be
mentioned in the above manual page.

Actual result:
--
configure: error: Cannot find MySQL header files under mysqlnd,.
Note that the MySQL client library is not bundled anymore!

Can't proceed further.





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



#49829 [Fbk->Csd]: ./configure --with-mysql=mysqlnd gave configure error

2009-10-14 Thread eddychu at yahoo dot com
 ID:   49829
 User updated by:  eddychu at yahoo dot com
 Reported By:  eddychu at yahoo dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: CentOS 5.3
 PHP Version:  5.3.0
 New Comment:

On my CentOS 5.3, after uninstalling MySQL-server-community 5.1.34 and
MySQL-client-community 5.1.34 and install mysql-server 5.0.77 and mysql
5.0.77, it started to work.  Note that I don't need mysql-devel for this
to work.


Previous Comments:


[2009-10-12 19:56:39] srina...@php.net

also, for these kind of configure errors, it is better if you provide
with the corresponding error you noticed inside config.log file (created
under the same location where you are trying to build).

as sjoerd suggested, you probably don't have mysql develop rpm
installed on your system.



[2009-10-12 13:01:18] u...@php.net

Works fine for me. Please make sure that configure is sane: 

rm configure ; ./buildconf --force ; ./configure  --with-mysql=mysqlnd
--with-mysqli=mysqlnd --with-pdo-mysql=mysqlnd




[2009-10-10 12:11:31] sjo...@php.net

Thank you for your bug report.

Have you installed the MySQL development files, from the mysql-devel
package?



[2009-10-10 02:12:33] eddychu at yahoo dot com

Description:

Followed http://us.php.net/manual/en/mysqlnd.install.php instructions
to attempt to configure PHP to build with mysqlnd support, but it gave
error:

configure: error: Cannot find MySQL header files under mysqlnd,.
Note that the MySQL client library is not bundled anymore!

although ext/mysqlnd folder is right there under php-5.3.0.  And no
Makefile was generated so I can't build PHP.  Either the instructions
are wrong or the configure scripts are wrong.

Reproduce code:
---
---
>From manual page: mysqlnd.install
---
Simply try to configure with mysqlnd:

./configure --with-mysql=mysqlnd, --with-mysqli=mysqlnd and
--with-pdo-mysql=mysqlnd

Expected result:

Expected ./configure --with-mysql=mysqlnd, --with-mysqli=mysqlnd and
--with-pdo-mysql=mysqlnd to successfully generate the Makefile.  If
other configure option(s) are required for these to work, they should be
mentioned in the above manual page.

Actual result:
--
configure: error: Cannot find MySQL header files under mysqlnd,.
Note that the MySQL client library is not bundled anymore!

Can't proceed further.





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



#49880 [Opn->Bgs]: mysqli::prepare doesnt accept special chars in field names

2009-10-14 Thread uw
 ID:  49880
 Updated by:  u...@php.net
 Reported By: thi...@php.net
-Status:  Open
+Status:  Bogus
 Bug Type:MySQLi related
 PHP Version: 5.2.11
 New Comment:

If MySQL does not support the syntax, PHP can't. 


Previous Comments:


[2009-10-14 19:38:43] thi...@php.net

Description:

This bug's PHP Version is set to 5.2.11 but that's not true. I cannot
upgrade my version from 5.2.6 at the moment. Sorry about this.

I was trying to prepare a statement where a field name had a "-" and it
was returning (boolean)FALSE. As soon as I updated my database field
"e-mail" to "email", and changed my statement to match the field again,
it worked like a charm.

Reproduce code:
---
select_db('test');

$query = "INSERT INTO
dummy
( name, e-mail, title, text)
VALUES (
  ?,?,?,?)";

var_dump($mysqli->prepare($query));
?>

Expected result:

object(mysqli_stmt)

Actual result:
--
false(boolean)





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



#49880 [NEW]: mysqli::prepare doesnt accept special chars in field names

2009-10-14 Thread thi...@php.net
From: thi...@php.net
Operating system: 
PHP version:  5.2.11
PHP Bug Type: MySQLi related
Bug description:  mysqli::prepare doesnt accept special chars in field names

Description:

This bug's PHP Version is set to 5.2.11 but that's not true. I cannot
upgrade my version from 5.2.6 at the moment. Sorry about this.

I was trying to prepare a statement where a field name had a "-" and it
was returning (boolean)FALSE. As soon as I updated my database field
"e-mail" to "email", and changed my statement to match the field again, it
worked like a charm.

Reproduce code:
---
select_db('test');

$query = "INSERT INTO
dummy
( name, e-mail, title, text)
VALUES (
  ?,?,?,?)";

var_dump($mysqli->prepare($query));
?>

Expected result:

object(mysqli_stmt)

Actual result:
--
false(boolean)

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



#49853 [Opn]: Soap Client stream context header option ignored

2009-10-14 Thread rumana024 at yahoo dot com
 ID:   49853
 User updated by:  rumana024 at yahoo dot com
-Summary:  Soap Client stream context option is ignored
 Reported By:  rumana024 at yahoo dot com
 Status:   Open
 Bug Type: SOAP related
 Operating System: Windows XP
 PHP Version:  5.2SVN-2009-10-12 (SVN)
 New Comment:

Is this a PHP bug? If not,can you please post some sample !working!
code on creating a SOAP Client with the stream_context option and http
header(in this case https). Those headers can be seen as the part of the
http request headers. I have pretty much tried different suggestions
that I read on diffrent threads on www and php.net to make a successful
soap call.

Regards
RI


Previous Comments:


[2009-10-13 18:03:07] rumana024 at yahoo dot com

$headers = array('X-USERID: user_1253314668.com\r\n', 
'Content-type: application/x-www-form-urlencoded\r\n',
'X-PASSWORD: 1253314679\r\n',
'X-SIGNATURE:
AtQaNHC.hbpghF5uGCRO99PVYV7ki3.SAb3vQzBlBAxEyi0b\r\n',
'X-VERSION: 1.2.0\r\n',
'X-PROTOCOL: SOAP11\r\n',
'X-SOURCE: PHP_SOAP_SAMPLE_V1\r\n');

$context = stream_context_create(array('http' => array('header' =>
$headers)));

$soapClient = new SoapClient(null,array('location' =>
"https://svcs.sandbox.com/Method1/";, 
'uri' =>
"http://x.x.com/types/test";, 
'soap_version' =>
SOAP_1_1,'trace' => 1, 'stream_context' => $context)); 



//Constructing the Payload
$param = "the payload"
$result = $soapClient->Method1($params);


I have changed the wrapper from https to http. Also made the header an
array. Still the same error. I do not see the http header with other
http headers when print the $soapClient->_getLastRequestHeaders().
Please advice how to resolve the issue.



[2009-10-13 10:48:05] sjo...@php.net

Thank you for your bug report.

Please try 'http' as wrapper name instead of 'https'.



[2009-10-12 23:18:28] rumana024 at yahoo dot com

Description:

Hi:


I am using PHP Soap PHP-SOAP/5.2.9-2 to connect to a web service. Part
of the reqiurment is that , few http headers need to be as part of the
request, but not part of the soap envelope. I am using the stream
context option and add the http headers with that option. Unfortunately,
the stream context is not being read at all. 




Reproduce code:
---
Here is my code 


$opts = array(
  'https'=>array(
'method'=>"GET",
'header'=>'X-SECURITY-USERID: seller_1253314668_biz_api1.x.com\r\n'
. 
  'X-SECURITY-PASSWORD: 1253314679\r\n' .
  'X-SECURITY-SIGNATURE:
AtQaNHC.hbpghF5uGCRO99PVY6a2ASO58V7ki3.SAb3vQzBlBAxEyi0b\r\n' .
  'X-SERVICE-VERSION: 1.2.0\r\n' .
  'X-MESSAGE-PROTOCOL: SOAP11\r\n' .
  'X-REQUEST-SOURCE: PLATFORM_JAVA_SOAP_SAMPLE_V1\r\n' .
  'X-APPLICATION-ID: APP-80W284485P519543T\r\n'));


$context = stream_context_create($opts);


$soapClient = new SoapClient(null,array('location' =>
"https://svcs.sandbox.x.com/AP/Method1/";,
'uri' =>
"http://svcs.x.com/types/ap";, 
'soap_version' => SOAP_1_1,
'trace' => 1, 'stream_context' => $context));



 

Expected result:

Security Credential are going as HTTP Headers and the Http headers are
contained in the context parameter. I get the result Invalid User name
and Password. So the context is not going through at all.
I know for sure the credentials are valid.

I know other option parameter like 'location', 'uri' are working.Please
advice how to fix this problem.






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



#49879 [NEW]: ERROR READING A LONG XML

2009-10-14 Thread bbarnett at gt dot co dot cr
From: bbarnett at gt dot co dot cr
Operating system: WServer 2K3
PHP version:  5.2.11
PHP Bug Type: SimpleXML related
Bug description:  ERROR READING A LONG XML 

Description:

I have a long XML that I recieve from another system, but this XML has
more than 3 records (tag), and when I try to read it PHP can't do it.

If you need the XML data, I can send it to the e-mail that you send me.

Reproduce code:
---
$xml= simplexml_load_string(utf8_decode(trim($xmlrecieved)));
if (!$xml ){
print 'MSG-20: Se detecto una respuesta invalida del INS '; die();
}

Expected result:

I need to process the data in the XML to update a database table.

Actual result:
--
PHP can't read it.

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



#49878 [Opn->Fbk]: Fileinfo functions not found

2009-10-14 Thread pajoye
 ID:   49878
 Updated by:   paj...@php.net
 Reported By:  rob at apgood dot com
-Status:   Open
+Status:   Feedback
 Bug Type: PHP options/info functions
 Operating System: Windows Serer 2003
 PHP Version:  5.3SVN-2009-10-14 (snap)
 New Comment:

Did you activate the extension via php.ini (see phpinfo();)?


Previous Comments:


[2009-10-14 17:08:37] rob at apgood dot com

Description:

Installed Windows binaries (php-5.3.0-Win32-VC6-x86.msi) with Fileinfo
functions selected to be installed.  However, the very simple attached
script results in error:
[Wed Oct 14 09:43:58 2009] [error] [client 173.10.71.237] PHP Fatal
error:  Call to undefined function finfo_open() in
D:\\Apache\\casetracker\\finfo1.php on line 2


Reproduce code:
---



Expected result:

a mime-type description of:

"image/vnd.microsoft.icon"

or (less correctly):

"image/x-icon"


Actual result:
--
in error.log,

[Wed Oct 14 09:43:58 2009] [error] [client 173.10.71.237] PHP Fatal
error:  Call to undefined function finfo_open() in
D:\\Apache\\casetracker\\finfo1.php on line 2






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



#49878 [NEW]: Fileinfo functions not found

2009-10-14 Thread rob at apgood dot com
From: rob at apgood dot com
Operating system: Windows Serer 2003
PHP version:  5.3SVN-2009-10-14 (snap)
PHP Bug Type: PHP options/info functions
Bug description:  Fileinfo functions not found

Description:

Installed Windows binaries (php-5.3.0-Win32-VC6-x86.msi) with Fileinfo
functions selected to be installed.  However, the very simple attached
script results in error:
[Wed Oct 14 09:43:58 2009] [error] [client 173.10.71.237] PHP Fatal error:
 Call to undefined function finfo_open() in
D:\\Apache\\casetracker\\finfo1.php on line 2


Reproduce code:
---



Expected result:

a mime-type description of:

"image/vnd.microsoft.icon"

or (less correctly):

"image/x-icon"


Actual result:
--
in error.log,

[Wed Oct 14 09:43:58 2009] [error] [client 173.10.71.237] PHP Fatal error:
 Call to undefined function finfo_open() in
D:\\Apache\\casetracker\\finfo1.php on line 2


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



#49827 [Opn->Bgs]: shell_exec using ls /home fails with Permission denied

2009-10-14 Thread Sjoerd
 ID:   49827
 Updated by:   sjo...@php.net
 Reported By:  bill dot mcclendon at digiconllc dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Linux RH
 PHP Version:  5.2.11
 New Comment:

Thank you for your feedback.

The behavior you report is not a bug in PHP. The 'ls' program is
executed succesfully and it gives the 'Permission denied' error, not
PHP.

The home directory may be mounted over NFS or there may be some other
reason why there are additional access restrictions. 


Previous Comments:


[2009-10-13 18:37:09] bill dot mcclendon at digiconllc dot com

PHP bug reporting/support.

1) No ACL's (you think I didn't check this already?)
2) You mean grave accent? Yes - same error (I checked that already
too).

It's not running in a VM either.

Bill



[2009-10-10 12:02:17] sjo...@php.net

Thank you for your bug report.

Does your installation have other access control than UNIX permissions,
such as ACL? Can you succesfully execute 'ls /home' from the command
line, or using backticks in PHP?



[2009-10-09 22:49:50] bill dot mcclendon at digiconllc dot com

Corrected email address (your form seems to have a problem)



[2009-10-09 22:48:30] bill dot mcclendon at digiconllc dot com

Description:

Running Apache 2.x and PHP 5.2

safe_mode = off

test case - using ""
produces the error "ls: /home Permission denied"
using "" succeeds

(check the Apache error_log for errors)

However, both "/home" and "/usr" have the EXACT same permission and
ownership.

and Apache is running with "User owner" where "owner" is the owner of
the contents of "/home".  

Listing of both paths:

  8 drwxr-xr-x   15 root   root4096 Jun 24  2005 usr
  8 drwxr-xr-x5 root   root4096 Jan  8  2007 home

Shell is "/bin/bash" and it looks like:

764 -rwxr-xr-x  1 root root 772760 Dec  6  2004 /bin/bash


Any ideas?

Reproduce code:
---
Test cases:
FAIL:

".shell_exec($cmd)."";
?>

SUCCESS:
".shell_exec($cmd)."";
?>

Expected result:

Listing of files:

SUCCESS result:

bin
etc
games
include
kerberos
lib
lib64
libexec
local
sbin
share
src
tmp
X11R6


Actual result:
--
For FAIL above (no results).





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



#49874 [Bgs->Fbk]: ftell()/fseek() inconsistency when using stream filters

2009-10-14 Thread Sjoerd
 ID:   49874
 Updated by:   sjo...@php.net
 Reported By:  jketterl at chipxonio dot de
-Status:   Bogus
+Status:   Feedback
 Bug Type: Filesystem function related
 Operating System: linux (ubuntu)
 PHP Version:  5.2.11


Previous Comments:


[2009-10-14 16:40:00] sjo...@php.net

Thank you for your bug report. Does your test.csv file start with a
BOM? You can determine this by viewing the file in a hex editor. If it
starts with fffe or feff, it has a BOM (byte order mark).



[2009-10-14 11:39:39] jketterl at chipxonio dot de

Description:

exact php version: PHP 5.2.11-0.dotdeb.1 with Suhosin-Patch 0.9.7 (cli)
(built: Sep 20 2009 09:41:43)
this bug is also be filter-/stream-related. i just believe it might be
easier to fix on the filesystem side, that's why i chose that category.

when using a php stream filter to convert input from utf-16 into
iso8859 (or most probably from any 2byte-encoded charset into any
single-byte-encode charset) the ftell() and fseek() functions start to
behave inconsistently.

more precisely: fseek() jumps to exact offsets ignoring the
2byte-encoding, whereas ftell() seems to return the number of bytes read
*after* the filter has been applied. thus it is not possible to fseek()
back to a certain offset that has been stored with ftell() before.

the content of the testfile used in the code examples is as follows:
Line 01
Line 02
Line 03
Line 04

Reproduce code:
---
$file = 'test.csv';

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
$line = fgets($fp);
var_dump($line);
fclose($fp);

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
fseek($fp, ftell($fp)); // this shouldn't move anything - but it
does...
$line = fgets($fp);
var_dump($line);
fclose($fp);

Expected result:

string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(8) "Line 02
"

Actual result:
--
string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(4) " 01
"





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



#49874 [Opn->Bgs]: ftell()/fseek() inconsistency when using stream filters

2009-10-14 Thread Sjoerd
 ID:   49874
 Updated by:   sjo...@php.net
 Reported By:  jketterl at chipxonio dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Filesystem function related
 Operating System: linux (ubuntu)
 PHP Version:  5.2.11
 New Comment:

Thank you for your bug report. Does your test.csv file start with a
BOM? You can determine this by viewing the file in a hex editor. If it
starts with fffe or feff, it has a BOM (byte order mark).


Previous Comments:


[2009-10-14 11:39:39] jketterl at chipxonio dot de

Description:

exact php version: PHP 5.2.11-0.dotdeb.1 with Suhosin-Patch 0.9.7 (cli)
(built: Sep 20 2009 09:41:43)
this bug is also be filter-/stream-related. i just believe it might be
easier to fix on the filesystem side, that's why i chose that category.

when using a php stream filter to convert input from utf-16 into
iso8859 (or most probably from any 2byte-encoded charset into any
single-byte-encode charset) the ftell() and fseek() functions start to
behave inconsistently.

more precisely: fseek() jumps to exact offsets ignoring the
2byte-encoding, whereas ftell() seems to return the number of bytes read
*after* the filter has been applied. thus it is not possible to fseek()
back to a certain offset that has been stored with ftell() before.

the content of the testfile used in the code examples is as follows:
Line 01
Line 02
Line 03
Line 04

Reproduce code:
---
$file = 'test.csv';

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
$line = fgets($fp);
var_dump($line);
fclose($fp);

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
fseek($fp, ftell($fp)); // this shouldn't move anything - but it
does...
$line = fgets($fp);
var_dump($line);
fclose($fp);

Expected result:

string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(8) "Line 02
"

Actual result:
--
string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(4) " 01
"





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



#49873 [Opn->Bgs]: array_map + htmlspecialchars_decode problem

2009-10-14 Thread Sjoerd
 ID:   49873
 Updated by:   sjo...@php.net
 Reported By:  webmaster at flex-code dot net
-Status:   Open
+Status:   Bogus
 Bug Type: Unknown/Other Function
 Operating System: Ubuntu Linux
 PHP Version:  5.3.0
 New Comment:

Thank you for your report.

The behavior you report is not a bug. Also note that bugs.php.net is
not a place to ask for support; it is a place to file bugs. For support,
please see:
http://nl2.php.net/support.php

Please try:
array_map('htmlspecialchars_decode', $anArray);


Previous Comments:


[2009-10-14 11:38:41] webmaster at flex-code dot net

Description:

Trying to decode encoded html special characters by using the array_map
and htmlspecialchars_decode functions returns an error by
htmlspecialchars_decode.

Reproduce code:
---
return array_map('htmlspecialchars_decode', array($aArray,
ENT_QUOTES));

Expected result:

All encoded special characters should be decoded to their respective
html characters, eg. ' => ', " => "

Actual result:
--
ERRNO: 2
TEXT: htmlspecialchars_decode() expects parameter 1 to be string, array
given
LOCATION:
/var/www/live/i/intranet-rewrite/base/includes/class_postgres.php, line
345, at October 14, 2009, 1:25 pm

Debug Backtrace:

- htmlspecialchars_decode(Array[57]) # line 0, file: unknown
- array_map("htmlspecialchars_decode", Array[2]) # line 345, file:
/var/www/live/i/intranet-rewrite/base/includes/class_postgres.php
- Resultset.convertCharacters(Array[57]) # line 336, file:
/var/www/live/i/intranet-rewrite/base/includes/class_postgres.php
- Resultset.fetchRow() # line 87, file:
/var/www/live/i/intranet-rewrite/hr/person_add_edit.php





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



#49876 [Opn]: configure fails --with-ldap Cannot find ldap libraries in /usr/lib

2009-10-14 Thread graham dot simpson at hsbcib dot com
 ID:   49876
 User updated by:  graham dot simpson at hsbcib dot com
 Reported By:  graham dot simpson at hsbcib dot com
 Status:   Open
 Bug Type: Compile Failure
 Operating System: SuSE Linux 10 SP 2 x86_64
 PHP Version:  5.3.0
 New Comment:

Sorry, meant to post my configure line also...
CFLAGS="-DSYB_LP64" ./configure  --prefix=${TDIR}/php-5.3.0 --with-ldap
--enable-libgcc --with-oci8 --with-pdo-oci
--with-sybase-ct=${SYBASE}/${SYBASE_OCS}
--with-pdo-dblib=${TDIR}/freetds-0.82 --with-curl --enable-pcntl
--with-gettext --with-mcrypt --enable-soap --with-pear --with-zlib
--disable-cgi --with-readline --with-bz2
--with-apxs2=${TDIR}/httpd-2.2.13/bin/apxs
--with-libxml-dir=${TDIR}/libxml2-2.7.5
--with-xsl=${TDIR}/libxslt-1.1.26 --with-openssl=${TDIR}/openssl-0.9.8k


Previous Comments:


[2009-10-14 14:59:56] graham dot simpson at hsbcib dot com

Description:

64bit SuSE 10.2 with openldap2-2.3, openldap2-devel-2.3 installed.
Configure --with-ldap fails with:
checking for LDAP support... yes
checking for LDAP Cyrus SASL support... no
configure: error: Cannot find ldap libraries in /usr/lib.
-
rpm -q -l openldap2-devel
/usr/include/lber.h
/usr/include/lber_types.h
/usr/include/ldap.h
/usr/include/ldap_cdefs.h
/usr/include/ldap_features.h
/usr/include/ldap_schema.h
/usr/include/ldap_utf8.h
/usr/include/slapi-plugin.h
/usr/lib64/liblber.a
/usr/lib64/liblber.so
/usr/lib64/libldap.a
/usr/lib64/libldap.so
/usr/lib64/libldap_r.a
/usr/lib64/libldap_r.so
-
Should be looking in /usr/lib64. Which is odd because my
LD_LIBRARY_PATH contains /usr/lib64.
-
Altering --with-ldap to --with-ldap=/usr or /usr/lib64, then complains
about not finding the ldap.h, viz:
checking for LDAP support... yes
checking for LDAP Cyrus SASL support... no
configure: error: Cannot find ldap.h
-
The problem seems to be the configure script find ldap.h in
/usr/include/ldap.h, so sets LDAP_LIBDIR=/usr/lib (line 52114), later it
looks for /usr/lib/liblber.a instead of /usr/lib64/liblber.a.
-
Maybe I've got that wrong. The weird thing is I know other directives
in my configure are picking up stuff from /usr/lib64.
-
Thanks for any help you can give.
GSi







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



#49876 [NEW]: configure fails --with-ldap Cannot find ldap libraries in /usr/lib

2009-10-14 Thread graham dot simpson at hsbcib dot com
From: graham dot simpson at hsbcib dot com
Operating system: SuSE Linux 10 SP 2 x86_64
PHP version:  5.3.0
PHP Bug Type: Compile Failure
Bug description:  configure fails --with-ldap Cannot find ldap libraries in 
/usr/lib

Description:

64bit SuSE 10.2 with openldap2-2.3, openldap2-devel-2.3 installed.
Configure --with-ldap fails with:
checking for LDAP support... yes
checking for LDAP Cyrus SASL support... no
configure: error: Cannot find ldap libraries in /usr/lib.
-
rpm -q -l openldap2-devel
/usr/include/lber.h
/usr/include/lber_types.h
/usr/include/ldap.h
/usr/include/ldap_cdefs.h
/usr/include/ldap_features.h
/usr/include/ldap_schema.h
/usr/include/ldap_utf8.h
/usr/include/slapi-plugin.h
/usr/lib64/liblber.a
/usr/lib64/liblber.so
/usr/lib64/libldap.a
/usr/lib64/libldap.so
/usr/lib64/libldap_r.a
/usr/lib64/libldap_r.so
-
Should be looking in /usr/lib64. Which is odd because my LD_LIBRARY_PATH
contains /usr/lib64.
-
Altering --with-ldap to --with-ldap=/usr or /usr/lib64, then complains
about not finding the ldap.h, viz:
checking for LDAP support... yes
checking for LDAP Cyrus SASL support... no
configure: error: Cannot find ldap.h
-
The problem seems to be the configure script find ldap.h in
/usr/include/ldap.h, so sets LDAP_LIBDIR=/usr/lib (line 52114), later it
looks for /usr/lib/liblber.a instead of /usr/lib64/liblber.a.
-
Maybe I've got that wrong. The weird thing is I know other directives in
my configure are picking up stuff from /usr/lib64.
-
Thanks for any help you can give.
GSi



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



#49349 [NoF->Asn]: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors)

2009-10-14 Thread pajoye
 ID:   49349
 Updated by:   paj...@php.net
 Reported By:  raulsalitrero at gmail dot com
-Status:   No Feedback
+Status:   Assigned
 Bug Type: Gettext related
 Operating System: win32 only - windows xp sp3
 PHP Version:  5.3.0
 Assigned To:  pajoye


Previous Comments:


[2009-10-14 13:45:51] roger dot olivier at gmail dot com

As asked by paj...@php.net you can found here an archive with a working
script with 5.2.5 and not with 5.3.0
Tested on Xp pro Sp3

http://www.lanforums.com/dl/gettext-setlocale_BUG_5.3.0.zip

Unzip and launch index.php.
Expected result => print "Hello world" on screen
Actual result =>   print "bonjour le monde" on screen



[2009-10-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".



[2009-09-24 18:05:55] paj...@php.net

Yes, but nobody managed to get to it at this stage. I assign it to me
so I won't forget to check this problem.

To ease my work it would be nice if someone can zip a working script
with 5.2, with mo/po files, where it should be placed, etc. and
describe. That will shorten the time I will have to spend on the issue.



[2009-09-24 16:51:48] bkraul at yahoo dot com

I was wondering this this issue is expected to be resolved in the near
future? Right know I have gotten around it by reverting back to php
5.2.11. Is this a problem with the extension itself?

Regards,

Belman Kraul



[2009-09-09 12:55:57] ameoba32 at gmail dot com

On windows vista sp2 + php-5.3.0-Win32-VC9-x86 

gettext function always searches for "en_US" or "en" path in locale
directory.

PHP 5.2.3 is okay.

this code produces different results



In php 5.3.0 it does not translate.



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

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



#49349 [Com]: gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors)

2009-10-14 Thread roger dot olivier at gmail dot com
 ID:   49349
 Comment by:   roger dot olivier at gmail dot com
 Reported By:  raulsalitrero at gmail dot com
 Status:   No Feedback
 Bug Type: Gettext related
 Operating System: win32 only - windows xp sp3
 PHP Version:  5.3.0
 Assigned To:  pajoye
 New Comment:

As asked by paj...@php.net you can found here an archive with a working
script with 5.2.5 and not with 5.3.0
Tested on Xp pro Sp3

http://www.lanforums.com/dl/gettext-setlocale_BUG_5.3.0.zip

Unzip and launch index.php.
Expected result => print "Hello world" on screen
Actual result =>   print "bonjour le monde" on screen


Previous Comments:


[2009-10-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".



[2009-09-24 18:05:55] paj...@php.net

Yes, but nobody managed to get to it at this stage. I assign it to me
so I won't forget to check this problem.

To ease my work it would be nice if someone can zip a working script
with 5.2, with mo/po files, where it should be placed, etc. and
describe. That will shorten the time I will have to spend on the issue.



[2009-09-24 16:51:48] bkraul at yahoo dot com

I was wondering this this issue is expected to be resolved in the near
future? Right know I have gotten around it by reverting back to php
5.2.11. Is this a problem with the extension itself?

Regards,

Belman Kraul



[2009-09-09 12:55:57] ameoba32 at gmail dot com

On windows vista sp2 + php-5.3.0-Win32-VC9-x86 

gettext function always searches for "en_US" or "en" path in locale
directory.

PHP 5.2.3 is okay.

this code produces different results



In php 5.3.0 it does not translate.



[2009-08-24 16:49:49] raulsalitrero at gmail dot com

Description:

usign gettext functions under php 5.3.0 (built with vc9) works
differently to how it used to work in php 5.2.x (tested on 5.2.10 built
with vc6).

it used to work even after a setlocale error, (locale not supported on
my machine), after the error it continued loading the .mo (.po) files
from the locale folder in the app. in php 5.3 it doesn't seem to load
the files, i've tried changing the locale to the correct name for
windows wich is "enu" and the path to the correct locale folder to:
locale/
  enu/...
  en_us/...
  en_US/...
  English_United States/...
  English_United States.1252/... (changing the setlocale codeset from
"UTF-8" to "CP1252" and "1252", and various combinations of the above
settings, also with and without the codeset functions, and it didn't
show translations.

in php 5.2.10 it loaded the files directly from the first settings
id like to know if it is possible to make php_gettext to ignore the
setlocal error and work out the folder name from the LANG and LC_ALL
enviroment variables like it apparently used to be in earlier versions
of php. or if it would be too much troublesome, then if it could be
possible to add a new function that returns the folder name where the
the .mo files are being expected to be, something like:

gettext_getpath([$text_domain = Current_default_domain])

and get something like "en_US\LC_MESSAGES\domain.mo" (locale folder
name) or the full path something like
"C:\Apache\htdocs\app\locale\en_US\LC_MESSAGES\domain.mo" or
"/var/www/app1/locale/en_US/LC_MESSAGES/domain.mo" in *nix (even if the
file doesn't exists to know if its necessary to rename/move folders

thanks in advance

Reproduce code:
---
 "hello world" (english)
in the relative path "locale/en/LC_MESSAGES/"

"hello world"

Actual result:
--
"hola mundo" (text not being translated)





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



#49871 [Bgs]: unexpected result converting float to int

2009-10-14 Thread rasmus
 ID:   49871
 Updated by:   ras...@php.net
 Reported By:  daniel dot buschke at nextiraone dot de
 Status:   Bogus
 Bug Type: Math related
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

Add 

ini_set('precision',20); 

to the top of your script.  That sets the output precision and will
cause your var_dump() to show:

- 2.3198401 
float(2.3198401)
float(231.97158)
int(231)
- 8.2793605 
float(8.2793605)
float(827.88631)
int(827)

This precision setting, because it is lossy, isn't applied until you
try to convert the float to a string, usually on output, but as the
previous comment mentioned, you could force it to apply before output
with an explicit conversion.  Or you can set your own fuzz factor and
use that.  If we magically applied this precision setting on every math
operation, these small floating point errors would become much bigger
when you actually were expecting your floating point to behave as
floating point values.


Previous Comments:


[2009-10-14 11:37:44] daniel dot buschke at nextiraone dot de

(int)(string)$b

that does the job but is ugly, too



[2009-10-14 11:16:23] sjo...@php.net

Floating point values have a limited precision. Hence a value might 
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly 
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
 
Thank you for your interest in PHP.





[2009-10-14 08:36:03] daniel dot buschke at nextiraone dot de

Description:

Hi,
when I convert following float:

float(232)

into an int I get:

int(231).


The float was calculated by 2.32 * 100. I know that this may result in
232.001 or 231.9 but the behavior is unexcpected because
var_dump does not show the real (more or less wrong) float number.

This one is exact the same as #2835 but the bug was closed without any
further comments. The provided solution is unacceptable.

How to convert 2.32 into an integer of the value 232?


BTW: Please do not set this bug to bogus or closed with the default
text for that problem ;-). As you can see in your bugtracker the
community wants a solution for that. Please also remember that PHP is a
scripting language which mainly ignores datatypes. This problem is not
comprehensible to beginners (webdesigners ;-) ).


I do not want to blame you with that but I just want to find a usefull
solution. Please keep communication with community.


regards
Daniel

Reproduce code:
---



Expected result:

- 2.32 
float(2.32)
float(232)
int(232)
- 8.28 
float(8.28)
float(828)
int(828)


or (but not preferred ;-) )

- 2.32 
float(2.32)
float(231.999)
int(231)
- 8.28 
float(8.28)
float(827.999)
int(827)


Actual result:
--
- 2.32 
float(2.32)
float(232)
int(231)
- 8.28 
float(8.28)
float(828)
int(827)






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



#49874 [NEW]: ftell()/fseek() inconsistency when using stream filters

2009-10-14 Thread jketterl at chipxonio dot de
From: jketterl at chipxonio dot de
Operating system: linux (ubuntu)
PHP version:  5.2.11
PHP Bug Type: Filesystem function related
Bug description:  ftell()/fseek() inconsistency when using stream filters

Description:

exact php version: PHP 5.2.11-0.dotdeb.1 with Suhosin-Patch 0.9.7 (cli)
(built: Sep 20 2009 09:41:43)
this bug is also be filter-/stream-related. i just believe it might be
easier to fix on the filesystem side, that's why i chose that category.

when using a php stream filter to convert input from utf-16 into iso8859
(or most probably from any 2byte-encoded charset into any
single-byte-encode charset) the ftell() and fseek() functions start to
behave inconsistently.

more precisely: fseek() jumps to exact offsets ignoring the
2byte-encoding, whereas ftell() seems to return the number of bytes read
*after* the filter has been applied. thus it is not possible to fseek()
back to a certain offset that has been stored with ftell() before.

the content of the testfile used in the code examples is as follows:
Line 01
Line 02
Line 03
Line 04

Reproduce code:
---
$file = 'test.csv';

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
$line = fgets($fp);
var_dump($line);
fclose($fp);

$fp = fopen($file, 'r');
stream_filter_append($fp, 'convert.iconv.utf16/iso8859-15');
$line = fgets($fp);
var_dump($line);
fseek($fp, ftell($fp)); // this shouldn't move anything - but it does...
$line = fgets($fp);
var_dump($line);
fclose($fp);

Expected result:

string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(8) "Line 02
"

Actual result:
--
string(8) "Line 01
"
string(8) "Line 02
"
string(8) "Line 01
"
string(4) " 01
"

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



#49873 [NEW]: array_map + htmlspecialchars_decode problem

2009-10-14 Thread webmaster at flex-code dot net
From: webmaster at flex-code dot net
Operating system: Ubuntu Linux
PHP version:  5.3.0
PHP Bug Type: Unknown/Other Function
Bug description:  array_map + htmlspecialchars_decode problem

Description:

Trying to decode encoded html special characters by using the array_map
and htmlspecialchars_decode functions returns an error by
htmlspecialchars_decode.

Reproduce code:
---
return array_map('htmlspecialchars_decode', array($aArray, ENT_QUOTES));

Expected result:

All encoded special characters should be decoded to their respective html
characters, eg. ' => ', " => "

Actual result:
--
ERRNO: 2
TEXT: htmlspecialchars_decode() expects parameter 1 to be string, array
given
LOCATION:
/var/www/live/i/intranet-rewrite/base/includes/class_postgres.php, line
345, at October 14, 2009, 1:25 pm

Debug Backtrace:

- htmlspecialchars_decode(Array[57]) # line 0, file: unknown
- array_map("htmlspecialchars_decode", Array[2]) # line 345, file:
/var/www/live/i/intranet-rewrite/base/includes/class_postgres.php
- Resultset.convertCharacters(Array[57]) # line 336, file:
/var/www/live/i/intranet-rewrite/base/includes/class_postgres.php
- Resultset.fetchRow() # line 87, file:
/var/www/live/i/intranet-rewrite/hr/person_add_edit.php

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



#49871 [Bgs]: unexpected result converting float to int

2009-10-14 Thread daniel dot buschke at nextiraone dot de
 ID:   49871
 User updated by:  daniel dot buschke at nextiraone dot de
 Reported By:  daniel dot buschke at nextiraone dot de
 Status:   Bogus
 Bug Type: Math related
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

(int)(string)$b

that does the job but is ugly, too


Previous Comments:


[2009-10-14 11:16:23] sjo...@php.net

Floating point values have a limited precision. Hence a value might 
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly 
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
 
Thank you for your interest in PHP.





[2009-10-14 08:36:03] daniel dot buschke at nextiraone dot de

Description:

Hi,
when I convert following float:

float(232)

into an int I get:

int(231).


The float was calculated by 2.32 * 100. I know that this may result in
232.001 or 231.9 but the behavior is unexcpected because
var_dump does not show the real (more or less wrong) float number.

This one is exact the same as #2835 but the bug was closed without any
further comments. The provided solution is unacceptable.

How to convert 2.32 into an integer of the value 232?


BTW: Please do not set this bug to bogus or closed with the default
text for that problem ;-). As you can see in your bugtracker the
community wants a solution for that. Please also remember that PHP is a
scripting language which mainly ignores datatypes. This problem is not
comprehensible to beginners (webdesigners ;-) ).


I do not want to blame you with that but I just want to find a usefull
solution. Please keep communication with community.


regards
Daniel

Reproduce code:
---



Expected result:

- 2.32 
float(2.32)
float(232)
int(232)
- 8.28 
float(8.28)
float(828)
int(828)


or (but not preferred ;-) )

- 2.32 
float(2.32)
float(231.999)
int(231)
- 8.28 
float(8.28)
float(827.999)
int(827)


Actual result:
--
- 2.32 
float(2.32)
float(232)
int(231)
- 8.28 
float(8.28)
float(828)
int(827)






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



#49868 [Com]: max_execution_time affected by max_input_time

2009-10-14 Thread majkl578 at gmail dot com
 ID:   49868
 Comment by:   majkl578 at gmail dot com
 Reported By:  majkl578 at gmail dot com
 Status:   Open
 Bug Type: Scripting Engine problem
 Operating System: Linux Debian
 PHP Version:  5.3SVN-2009-10-13 (snap)
 New Comment:

This problem does not appear neither on PHP 5.2.6 (windows binary) nor
5.2.10 (gentoo pkg).


Previous Comments:


[2009-10-13 18:02:05] sjo...@php.net

See also bug #37306 max_execution_time = max_input_time



[2009-10-13 17:41:55] majkl578 at gmail dot com

Description:

PHP ignores the max_execution_time set in php.ini and sets (somehow
internally) it to the value of max_input_time. ini_get returns correct
values of both of these settings, but the script is halted after the
time set as max_input_time.

This bug affects PHP5.3RC1 and also the latest snapshot of PHP5.3.
It is probably similar to an old bug #37306.

Related php.ini values:
max_execution_time = 5
max_input_time = 10

Configure command:
./configure --prefix=/usr --sysconfdir=/etc --cache-file=./config.cache
--with-config-file-path=/etc/php
--with-config-file-scan-dir=/etc/php/extensions
--with-apxs2=/usr/bin/apxs2 --with-mysql --with-mysqli --with-curl
--with-sqlite --enable-sqlite-utf8 --with-gd --enable-mbstring
--with-openssl --disable-short-tags --with-mcrypt --with-bz2 --with-zlib
--enable-zip --with-xmlrpc --enable-soap --without-mssql --with-pgsql
--with-tidy --enable-debug --disable-posix --enable-exif --enable-ftp
--with-gettext --with-mhash --enable-pcntl --with-pspell
--enable-sockets --with-xsl --enable-cli --enable-calendar --disable-cgi
--enable-zend-multibyte

Reproduce code:
---
http://bugs.php.net/?id=49868&edit=1



#49383 [NoF->Opn]: Lots of empty fstat() calls slow performance

2009-10-14 Thread olga at metacafe dot com
 ID:   49383
 User updated by:  olga at metacafe dot com
 Reported By:  olga at metacafe dot com
-Status:   No Feedback
+Status:   Open
 Bug Type: Performance problem
 Operating System: Red Hat 3.4.6-10
 PHP Version:  5.3, 6
 New Comment:

The problem persists.

We upgraded APC to the latest version (3.1.3p1). Cache full count is 0,
hit ratio is 99.9%. I understand that this shouldn't happen, but there
are still 3 fstat() calls per file opened.

Here's our APC configuration - maybe you can see if anything is wrong
with it? Do you have other versions?

apc.cache_by_default1
apc.canonicalize1
apc.coredump_unmap  0
apc.enable_cli  1
apc.enabled 1
apc.file_md50
apc.file_update_protection  2
apc.filters 
apc.gc_ttl  3600
apc.include_once_override   1
apc.lazy_classes0
apc.lazy_functions  0
apc.max_file_size   1M
apc.mmap_file_mask  /tmp/apc.IR76ZW
apc.num_files_hint  1024
apc.preload_path
apc.report_autofilter   0
apc.rfc1867 0
apc.rfc1867_freq0
apc.rfc1867_nameAPC_UPLOAD_PROGRESS
apc.rfc1867_prefix  upload_
apc.rfc1867_ttl 3600
apc.shm_segments1
apc.shm_size128
apc.stat0
apc.stat_ctime  0
apc.ttl 7200
apc.use_request_time1
apc.user_entries_hint   4096
apc.user_ttl7200
apc.write_lock  1


Previous Comments:


[2009-09-20 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".



[2009-09-03 16:49:18] ras...@php.net

The only time this code is executed if you are running APC is if the
script is not cached.  So, either your APC setup is not working, you are
constantly trashing your cache (check apc.php and look at the cache-full
counter), or something else weird is going on.  

These fstats are coming from compiler which reads the script from disk
and compiles it down to opcodes.  It is impossible for this code to
execute on an APC-cached script because we point the executor directly
at the already compiled opcodes in shared memory.




[2009-09-03 15:06:28] olga at metacafe dot com

Thanks for the quick response.

We do work with APC. I tested the new PHP without APC also, to make
sure the fstat() calls aren't caused by it. But the statistics I sent to
you are from web server that works with APC.

You can also see from my first submission that in 5.2.9 fstat() doesn't
take much time.



[2009-09-03 14:24:14] ras...@php.net

Still surprised these fstats take that long on your system.  Note also
that if you install APC, they completely go away.  If you are down to
caring about performance at the syscall level like that and you are not
running a decent opcode cache, you are kind of confused.

Here is a backtrace of those 3 fstats:

#1  0x0137642f in do_fstat ()
#2  0x0137768f in _php_stream_fopen ()
#3  0x013719ba in _php_stream_open_wrapper_ex ()
#4  0x0135a1a3 in php_stream_open_for_zend_ex ()
#5  0x0135a2e0 in php_stream_open_for_zend ()
#6  0x013ca05f in zend_stream_fixup ()
#7  0x01383ae7 in open_file_for_scanning ()
#8  0x01383c8d in compile_file ()
#9  0x011eb8f7 in phar_compile_file ()
#10 0x013b4fa7 in zend_execute_scripts ()
#11 0x0135be38 in php_execute_script ()

#1  0x0137642f in do_fstat ()
#2  0x01376ee1 in php_stdiop_stat ()
#3  0x0135a148 in php_zend_stream_fsizer ()
#4  0x0135a206 in php_stream_open_for_zend_ex ()
#5  0x0135a2e0 in php_stream_open_for_zend ()
#6  0x013ca05f in zend_stream_fixup ()
#7  0x01383ae7 in open_file_for_scanning ()
#8  0x01383c8d in compile_file ()
#9  0x011eb8f7 in phar_compile_file ()
#10 0x013b4fa7 in zend_execute_scripts ()
#11 0x0135be38 in php_execute_script ()

#1  0x0137642f in do_fstat ()
#2  0x01377189 in php_stdiop_set_option ()
#3  0x0136fc8e in _php_stream_set_option ()
#4  0x0137dcec in _php_stream_mmap_range ()
#5  0x0135a295 in php_stream_open_for_zend_ex ()
#6  0x0135a2e0 in php_stream_open_for_zend ()
#7  0x013ca05f in zend_stream_fixup ()
#8  0x01383ae7 in open_file_for_scanning ()
#9  0x01383c8d in compile_file ()
#10 0x011eb8f7 in phar_compile_file ()
#11 0x013b4fa7 in zend_execute_scripts ()
#12 0x0135be38 in php_execute_script ()

The do_fstat() function has a cache, but those 3 calls set the 'force'
flag to ignore the cached stat struct.  We need to track down whether it
is possible to not force these.  It seems like it should be possible to
get rid of at least one of those, if not 2.

But again, install an opcode cache, and this stops being a problem.


#49871 [Opn->Bgs]: unexpected result converting float to int

2009-10-14 Thread sjoerd
 ID:   49871
 Updated by:   sjo...@php.net
 Reported By:  daniel dot buschke at nextiraone dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Math related
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

Floating point values have a limited precision. Hence a value might 
not have the same string representation after any processing. That also
includes writing a floating point value in your script and directly 
printing it without any mathematical operations.

If you would like to know more about "floats" and what IEEE
754 is, read this:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
 
Thank you for your interest in PHP.




Previous Comments:


[2009-10-14 08:36:03] daniel dot buschke at nextiraone dot de

Description:

Hi,
when I convert following float:

float(232)

into an int I get:

int(231).


The float was calculated by 2.32 * 100. I know that this may result in
232.001 or 231.9 but the behavior is unexcpected because
var_dump does not show the real (more or less wrong) float number.

This one is exact the same as #2835 but the bug was closed without any
further comments. The provided solution is unacceptable.

How to convert 2.32 into an integer of the value 232?


BTW: Please do not set this bug to bogus or closed with the default
text for that problem ;-). As you can see in your bugtracker the
community wants a solution for that. Please also remember that PHP is a
scripting language which mainly ignores datatypes. This problem is not
comprehensible to beginners (webdesigners ;-) ).


I do not want to blame you with that but I just want to find a usefull
solution. Please keep communication with community.


regards
Daniel

Reproduce code:
---



Expected result:

- 2.32 
float(2.32)
float(232)
int(232)
- 8.28 
float(8.28)
float(828)
int(828)


or (but not preferred ;-) )

- 2.32 
float(2.32)
float(231.999)
int(231)
- 8.28 
float(8.28)
float(827.999)
int(827)


Actual result:
--
- 2.32 
float(2.32)
float(232)
int(231)
- 8.28 
float(8.28)
float(828)
int(827)






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



#49870 [Asn->Ana]: Installing TS PHP removes non-TS installation of PHP

2009-10-14 Thread pajoye
 ID:   49870
 Updated by:   paj...@php.net
 Reported By:  sameer at codecurry dot com
-Status:   Assigned
+Status:   Analyzed
 Bug Type: *General Issues
 Operating System: Windows 2008 Server
 PHP Version:  5.3.0


Previous Comments:


[2009-10-14 08:56:43] paj...@php.net

The installer does not support yet multiple install of php. We may
support it in a near future, in the meantime you have to install one of
them manually. FCGI is the easiest :)



[2009-10-14 04:16:43] sameer at codecurry dot com

Description:

We have been using Apache with PHP. And this new project required
developing on IIS+PHP.

Issue, is the installing TS version of PHP removes non-TS installation
of PHP affecting existing configured servers.

I had Apache running with 5.2 and then when setting up IIS7 to run PHP
the installer removed the files required by Apache server. 



Reproduce code:
---


Expected result:

The installer should not tamper the existing installation. Even when
choosing to install the non-TS version of PHP, the installer removed the
files installed by the previous TS version installer.

I have discussed this here as well:
http://forums.iis.net/t/1161449.aspx

Currently I have IIS and Apache server both running on my Win 2008 x64
version. 

Actual result:
--
Running thread-safe PHP MSI installer removes non-TS installation of
PHP and vice-versa. 





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



#49855 [Ver]: import_request_variables always return false in any codition.

2009-10-14 Thread sjoerd
 ID:   49855
 Updated by:   sjo...@php.net
 Reported By:  easyeagel at gmx dot com
 Status:   Verified
 Bug Type: HTTP related
 Operating System: Linux
 PHP Version:  5.2.11
 New Comment:

Patch: http://pastebin.com/f236dcf35


Previous Comments:


[2009-10-13 10:55:20] sjo...@php.net

Actually, it seems to return null, not false.



[2009-10-13 02:16:16] easyeagel at gmx dot com

Description:

the import_request_variables always return false in any condition.

Reproduce code:
---
---
>From manual page: function.import-request-variables#Return Values
---

if(import_request_variables('p', 'post_'))
{
echo "unimport the request";
phpinfo();
}

if(isset($post_username))
{
echo "", $post_username, "";
}

if(isset($post_email))
{
echo "", $post_email, "";
}

if(isset($post_message))
{
echo "", $post_message, "";
}

Expected result:

I think the import_request_varibles return true

Actual result:
--
it return false, and return false anytime, if I run php5 in command
line or in apache.





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



#49870 [Opn->Asn]: Installing TS PHP removes non-TS installation of PHP

2009-10-14 Thread pajoye
 ID:   49870
 Updated by:   paj...@php.net
 Reported By:  sameer at codecurry dot com
-Status:   Open
+Status:   Assigned
 Bug Type: *General Issues
 Operating System: Windows 2008 Server
 PHP Version:  5.3.0
 New Comment:

The installer does not support yet multiple install of php. We may
support it in a near future, in the meantime you have to install one of
them manually. FCGI is the easiest :)


Previous Comments:


[2009-10-14 04:16:43] sameer at codecurry dot com

Description:

We have been using Apache with PHP. And this new project required
developing on IIS+PHP.

Issue, is the installing TS version of PHP removes non-TS installation
of PHP affecting existing configured servers.

I had Apache running with 5.2 and then when setting up IIS7 to run PHP
the installer removed the files required by Apache server. 



Reproduce code:
---


Expected result:

The installer should not tamper the existing installation. Even when
choosing to install the non-TS version of PHP, the installer removed the
files installed by the previous TS version installer.

I have discussed this here as well:
http://forums.iis.net/t/1161449.aspx

Currently I have IIS and Apache server both running on my Win 2008 x64
version. 

Actual result:
--
Running thread-safe PHP MSI installer removes non-TS installation of
PHP and vice-versa. 





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



#49843 [Fbk->Bgs]: Application Failure httpd.exe 2.2.14.0 in php5ts.dll 5.2.11.11

2009-10-14 Thread pajoye
 ID:   49843
 Updated by:   paj...@php.net
 Reported By:  lakiluk60 at go2 dot pl
-Status:   Feedback
+Status:   Bogus
 Bug Type: Apache2 related
 Operating System: Windows XP HE SP3
 PHP Version:  5.2.11
 New Comment:

Don't use mysql libmysql with PHP but only PHP's libmysql.dll, which is
in our releases (msi or zip). Be sure to put the PHP directory first in
your PATH, not mysql.


Previous Comments:


[2009-10-14 06:58:41] morgan at nm dot ru

Description:

Application Failure  httpd.exe 2.2.14.0 in php5ts.dll 5.2.11.11 

At library connection libmysql.dll from a package mysql versions 5.1.39
instead of from package delivery php 5.2.11 - phpinfo (); deduces that
costs and version API 5.1.39 is connected but at a conclusion of any
script falls apache, bring in release the version client API libraries
5.1. + also explain in what a problem

mysql 5.1.39
apache 2.2.14
php 5.2.11



[2009-10-12 16:12:56] lakiluk60 at go2 dot pl

No script/no code is running. This is during start of Apache with PHP
module!



[2009-10-12 13:25:57] paj...@php.net

Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.





[2009-10-12 13:03:53] lakiluk60 at go2 dot pl

Assigned to "Apache2 related"



[2009-10-12 13:02:59] lakiluk60 at go2 dot pl

Description:

Application Failure  httpd.exe 2.2.14.0 in php5ts.dll 5.2.11.11 at
offset 000f330d

Windows XP Home Edition SP3
Apache 2.2.14
PHP 5.2.11
MySQL 5.1.30

Apache+PHP+MySQL installed from MSI/EXE packages.






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



#49871 [NEW]: unexpected result converting float to int

2009-10-14 Thread daniel dot buschke at nextiraone dot de
From: daniel dot buschke at nextiraone dot de
Operating system: Linux
PHP version:  5.2.11
PHP Bug Type: Math related
Bug description:  unexpected result converting float to int

Description:

Hi,
when I convert following float:

float(232)

into an int I get:

int(231).


The float was calculated by 2.32 * 100. I know that this may result in
232.001 or 231.9 but the behavior is unexcpected because
var_dump does not show the real (more or less wrong) float number.

This one is exact the same as #2835 but the bug was closed without any
further comments. The provided solution is unacceptable.

How to convert 2.32 into an integer of the value 232?


BTW: Please do not set this bug to bogus or closed with the default text
for that problem ;-). As you can see in your bugtracker the community wants
a solution for that. Please also remember that PHP is a scripting language
which mainly ignores datatypes. This problem is not comprehensible to
beginners (webdesigners ;-) ).


I do not want to blame you with that but I just want to find a usefull
solution. Please keep communication with community.


regards
Daniel

Reproduce code:
---



Expected result:

- 2.32 
float(2.32)
float(232)
int(232)
- 8.28 
float(8.28)
float(828)
int(828)


or (but not preferred ;-) )

- 2.32 
float(2.32)
float(231.999)
int(231)
- 8.28 
float(8.28)
float(827.999)
int(827)


Actual result:
--
- 2.32 
float(2.32)
float(232)
int(231)
- 8.28 
float(8.28)
float(828)
int(827)


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