date:20090817

 ID:   48664
 Updated by:   paj...@php.net
 Reported By:  patrickdk at patrickdk dot com
-Status:   No Feedback
+Status:   Assigned
 Bug Type: Strings related
 Operating System: linux 2.6.x
 PHP Version:  5.2.10
 Assigned To:  pajoye


Previous Comments:


[2009-07-03 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-06-25 21:12:00] paj...@php.net

Yes, it can be a solution.

We can also simply implement the missing algo in php and always use
them, for the users benefits (portability).



[2009-06-25 03:26:18] patrickdk at patrickdk dot com

What I would like to see is this:

We can use the new php builtin crypt function for hashs it can
understand, like des, md5, and blowfish (I think it does md5)

For hashs it doesn't understand, by matching the the has type in the
supplied salt, if it start with $ and follows a type unknown, pass it
off to the system crypt function (or crypt_r). If one doesn't exist
(windows) then it can just fail.

Then it wouldn't matter if new crypt hashs come into being and php
can't handle them internally, as long as the system libs can.



[2009-06-25 02:16:13] patrickdk at patrickdk dot com

Ok, I tried php-5.3.0RC4 on ubuntu 8.04

It didn't work at first, and I found out it's cause it didn't detect
crypt_r, so php used it's internal routines, so that was to be
expected.

It seems configure doesn't test for crypt_r in libcrypt

So I overrode that, and it worked fine (same results though).

salt is truncated cause php only detects crypt_md5, and truncates salts
to 12bytes. If I hack the salt_max then everything works as expected.

same results using rhel5



[2009-06-24 18:48:36] paj...@php.net

Debian/Ubuntu should really stop to do stupid things with PHP.

Which version do you use (of ubuntu)? And have you tried using
5.3.0RC4? If not, please try.



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

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

#46015 [NoF-Csd]: Build fails with system gd

 ID:   46015
 Updated by:   paj...@php.net
 Reported By:  Fedora at FamilleCollet dot com
-Status:   No Feedback
+Status:   Closed
 Bug Type: GD related
 Operating System: Linux (Fedora 9)
 PHP Version:  5.3.0alpha2
 Assigned To:  pajoye
 New Comment:

Fixed in 5.3.0 and later.


Previous Comments:


[2009-04-15 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-04-07 09:27:06] paj...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2009-03-27 18:50:40] tsteiner at nerdclub dot net

Here's a quick patch that removes support for building against an
external libgd and replaces it with an error message.  It seems to work
as intended but I am by no means experienced with the autoconf system.

--- php-5.3.0RC1.orig/ext/gd/config.m4   2009-01-14
13:05:59.0 -0600
+++ php-5.3.0RC1/ext/gd/config.m4   2009-03-27 13:42:01.071603975
-0500
@@ -262,7 +262,6 @@
 dnl
 
 if test $PHP_GD = yes; then
-  GD_MODULE_TYPE=builtin
   extra_sources=libgd/gd.c libgd/gd_gd.c libgd/gd_gd2.c libgd/gd_io.c
libgd/gd_io_dp.c \
  libgd/gd_io_file.c libgd/gd_ss.c libgd/gd_io_ss.c
libgd/gd_png.c libgd/gd_jpeg.c \
  libgd/gdxpm.c libgd/gdfontt.c libgd/gdfonts.c
libgd/gdfontmb.c libgd/gdfontl.c \
@@ -339,57 +338,7 @@
 else
 
  if test $PHP_GD != no; then
-  GD_MODULE_TYPE=external
-  extra_sources=gdcache.c
-
-dnl Various checks for GD features
-  PHP_GD_ZLIB
-  PHP_GD_TTSTR
-  PHP_GD_JPEG
-  PHP_GD_PNG
-  PHP_GD_XPM
-  PHP_GD_FREETYPE2
-  PHP_GD_T1LIB
-
-dnl Header path
-  for i in include/gd1.3 include/gd include gd1.3 gd ; do
-test -f $PHP_GD/$i/gd.h  GD_INCLUDE=$PHP_GD/$i
-  done
-
-dnl Library path
-  for i in $PHP_LIBDIR/gd1.3 $PHP_LIBDIR/gd $PHP_LIBDIR gd1.3 gd ;
do
-test -f $PHP_GD/$i/libgd.$SHLIB_SUFFIX_NAME || test -f
$PHP_GD/$i/libgd.a  GD_LIB=$PHP_GD/$i
-  done
-
-  if test -n $GD_INCLUDE  test -n $GD_LIB; then
-PHP_ADD_LIBRARY_WITH_PATH(gd, $GD_LIB, GD_SHARED_LIBADD)
-AC_DEFINE(HAVE_LIBGD,1,[ ])
-PHP_GD_CHECK_VERSION
-  elif test -z $GD_INCLUDE; then
-AC_MSG_ERROR([Unable to find gd.h anywhere under $PHP_GD])
-  else
-AC_MSG_ERROR([Unable to find libgd.(a|so) anywhere under
$PHP_GD])
-  fi
-
-  PHP_EXPAND_PATH($GD_INCLUDE, GD_INCLUDE)
-
-  dnl
-  dnl Check for gd 2.0.4 greater availability
-  dnl
-  old_CPPFLAGS=$CPPFLAGS
-  CPPFLAGS=-I$GD_INCLUDE
-  AC_TRY_COMPILE([
-#include gd.h
-#include stdlib.h
-  ], [
-gdIOCtx *ctx;
-ctx = malloc(sizeof(gdIOCtx));
-ctx-gd_free = 1;
-  ], [
-AC_DEFINE(HAVE_LIBGD204, 1, [ ])
-  ])
-  CPPFLAGS=$old_CPPFLAGS
-
+  AC_MSG_ERROR([Building the GD extension against an external libgd is
not supported.])
  fi
 fi
 
@@ -399,23 +348,13 @@
 if test $PHP_GD != no; then
   PHP_NEW_EXTENSION(gd, gd.c $extra_sources, $ext_shared,,
\\$(GDLIB_CFLAGS))
 
-  if test $GD_MODULE_TYPE = builtin; then
-GDLIB_CFLAGS=-I$ext_srcdir/libgd $GDLIB_CFLAGS
-PHP_ADD_BUILD_DIR($ext_builddir/libgd)
-GD_HEADER_DIRS=ext/gd/ ext/gd/libgd/
-
-PHP_TEST_BUILD(foobar, [], [
-  AC_MSG_ERROR([GD build test failed. Please check the config.log
for details.])
-], [ $GD_SHARED_LIBADD ], [char foobar () {}])
-  else
-GD_HEADER_DIRS=ext/gd/
-GDLIB_CFLAGS=-I$GD_INCLUDE $GDLIB_CFLAGS
-PHP_ADD_INCLUDE($GD_INCLUDE)
-
-PHP_CHECK_LIBRARY(gd, gdImageCreate, [], [
-  AC_MSG_ERROR([GD build test failed. Please check the config.log
for details.])
-], [ -L$GD_LIB $GD_SHARED_LIBADD ])
-  fi
+  GDLIB_CFLAGS=-I$ext_srcdir/libgd $GDLIB_CFLAGS
+  PHP_ADD_BUILD_DIR($ext_builddir/libgd)
+  GD_HEADER_DIRS=ext/gd/ ext/gd/libgd/
+
+  PHP_TEST_BUILD(foobar, [], [
+AC_MSG_ERROR([GD build test failed. Please check the config.log
for details.])
+  ], [ $GD_SHARED_LIBADD ], [char foobar () {}])
 
   PHP_INSTALL_HEADERS([$GD_HEADER_DIRS])
   PHP_SUBST(GDLIB_CFLAGS)



[2009-03-27 18:03:22] tsteiner at nerdclub dot net

This is still an issue in 5.3.0RC1.  If building against an external
version of GD is no longer supported, the configure script should
probably be updated to throw an error or at least a warning should one
try to do so.  Currently, the build just fails during make with the
error:

ext/gd/gd.c:72:23: error: gdhelpers.h: No such file or directory

leaving the user with no idea what to do.

#45447 [NoF-Csd]: filesystem time functions

 ID:   45447
 Updated by:   paj...@php.net
 Reported By:  Bryan dot Gallant at hma dot com
-Status:   No Feedback
+Status:   Closed
 Bug Type: Filesystem function related
 Operating System: Windows Server 2008
 PHP Version:  5.2.6
 Assigned To:  pajoye
 New Comment:

Fixed in 5.3+


Previous Comments:


[2008-08-23 01:00:01] 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-08-15 18:36:46] paj...@php.net

Fixed in CVS. Please try the 5.3 snapshot from http://snaps.php.net
(the zip, not the MSI).



[2008-08-13 07:46:56] paj...@php.net

http://phpfi.com/342491 should fix it.

I'm working on fixing many filesystem functions on Windows (touch,
filemtime, stat, etc.).  98% of the file tests pass now on 2k8, xp and
vista.



[2008-08-13 06:55:38] j...@php.net

What filesystem is used in the one that fails and on the one where it
doesn't fail..?



[2008-08-04 21:13:56] Bryan dot Gallant at hma dot com

Interesting Update.  using the same code on an old Win2k Box against
the files on the 2008 server, it works as intended.



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

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

#40858 [NoF-Csd]: Thread safety issue in GD

 ID:   40858
 Updated by:   paj...@php.net
 Reported By:  scottmacvicar at ntlworld dot com
-Status:   No Feedback
+Status:   Closed
 Bug Type: GD related
 Operating System: RHEL 4
 PHP Version:  5.2.1
 Assigned To:  pajoye
 New Comment:

fixed in all branches.


Previous Comments:


[2007-04-12 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.



[2007-04-04 01:59:07] paj...@php.net

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





[2007-03-23 12:39:34] scottmacvicar at ntlworld dot com

I don't have access to a Windows machine at the moment but the
following patch should fix the issues in libGD, I'll try and do a test
when I have access to the machine.

PHP 5.2 Patch: http://public.vbulletin.com/bugs/php/gd-mutex-patch.txt
libGD Patch:
http://public.vbulletin.com/bugs/php/libgd-mutex-patch.txt

Explanation:
* pthread now initialises the mutex only once
* win32 can set the mutex within DLLMain
* Race condition fix by locking prior to checking font cache

Problems not fixed:
* calling gdFontCacheSetup before obtaining a lock is going to cause
the race condition still, I know the ruby wrappers do this.
* Unusure about behaviour of using the non bundled GD library on
windows with PHP since DLLMain and gdFontCacheMutexSetup may setup the
critical section twice. Could make gdMutexSetup(x) a no-op for win32
too.



[2007-03-23 01:21:26] paj...@php.net

Hi Scott, Nuno,

Regarding the patch to the bundled GD library and the php wrapper,
does it look reasonable? We've been running it for the past 2 days now
without issue on a production server. I'd rather see something put
into
5.2.2 

Yes, the patch for php (and unix) looks good. I will apply it during
the weekend as well (or Nuno, you can do it if you have the time
before).

For the windows version, that's a good news, thanks to take the time to
work on it.



[2007-03-23 00:31:35] scottmacvicar at ntlworld dot com

I have some time to spare over the weekend and a copy of VC6 installed
now so I'll have a go at the win32 implementation.

Regarding the patch to the bundled GD library and the php wrapper, does
it look reasonable? We've been running it for the past 2 days now
without issue on a production server. I'd rather see something put into
5.2.2 and then fix libGD.



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

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

#49276 [NEW]: Sybase 15 incorrect library name references

2009-08-17 Thread andy at networkjabber dot com

From: andy at networkjabber dot com
Operating system: Fedora Core 9
PHP version:  5.3.0
PHP Bug Type: Compile Failure
Bug description:  Sybase 15 incorrect library name references

Description:

This problem was originally logged on 24/2/2006 under #36516, but marked
as bogus. However, the problem still exists. Sybase have changed the
library names of 4 of their ASE libraries: libsybcs, libsybct, lsybcomn and
lsybintl. The default automake profile references these as -lcs -lct -lcomn
-lintl so the compile fails with libraries being reported as missing. Both
./configure and ./ext/sybase_ct/config.m4 need to be editied so that these
references are -lsybcs -lsybct -lsybcomn -lsybsybintl. After these changes
are made all compiles correctly.


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

#49274 [Opn-Fbk]: filter_var() should accept objects without fatal error

 ID:   49274
 Updated by:   j...@php.net
 Reported By:  cel...@php.net
-Status:   Open
+Status:   Feedback
 Bug Type: Filter related
 Operating System: *
 PHP Version:  5.3SVN-2009-08-16 (SVN)
 New Comment:

Does this happen ONLY with PHP_5_3 branch? If not, please use the
proper version string.


Previous Comments:


[2009-08-16 22:09:05] cel...@php.net

Description:

?php
filter_var(new stdClass, FILTER_VALIDATE_EMAIL);
?

throws a fatal error because stdClass can't be converted into a string.
 filter_var() should be more flexible and simply return false in this
situation, it makes it very difficult to provide validation not just for
untrusted user input but for untrusted third party use of libraries who
may make it insecure by passing in the wrong value to a field for
setting.






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

#49276 [Opn-Bgs]: Sybase 15 incorrect library name references

 ID:   49276
 Updated by:   j...@php.net
 Reported By:  andy at networkjabber dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Sybase-ct (ctlib) related
 Operating System: Fedora Core 9
 PHP Version:  5.3.0
 New Comment:

Bug #36516 was marked as being bogus because it was duplicate of bug
#45357 and both didn't get any feedback when asked to test this patch:

  http://sitten-polizei.de/php/sybase-configm4.diff

So please apply the patch, run ./buildconf --force and see if it works
then.


Previous Comments:


[2009-08-17 08:56:52] andy at networkjabber dot com

Description:

This problem was originally logged on 24/2/2006 under #36516, but
marked as bogus. However, the problem still exists. Sybase have changed
the library names of 4 of their ASE libraries: libsybcs, libsybct,
lsybcomn and lsybintl. The default automake profile references these as
-lcs -lct -lcomn -lintl so the compile fails with libraries being
reported as missing. Both ./configure and ./ext/sybase_ct/config.m4 need
to be editied so that these references are -lsybcs -lsybct -lsybcomn
-lsybsybintl. After these changes are made all compiles correctly.






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

#49224 [Opn-Asn]: Segmentation fault

 ID:   49224
 Updated by:   j...@php.net
 Reported By:  alahaye at fm2i dot com
-Status:   Open
+Status:   Assigned
 Bug Type: Apache2 related
 Operating System: HPUX 11.31
 PHP Version:  5.3.0
-Assigned To:  
+Assigned To:  scottmac


Previous Comments:


[2009-08-14 12:11:35] alahaye at fm2i dot com

Hi, did you receive my files ?



[2009-08-12 10:36:34] scott...@php.net

Can you mail me your config.log and your resolv.h file.





[2009-08-12 09:37:01] alahaye at fm2i dot com

Bind version is 9.3.2. For me it's very strange because last
compilation about PHP 5.3.0 stable was successfull and not with the
snap.



[2009-08-12 09:24:47] alahaye at fm2i dot com

unfortunatly no... it's on a local network, no VPN or DMZ access.



[2009-08-12 09:12:21] scott...@php.net

Is there any chance to get an account on this box to do some testing?

I can provide an SSH key.



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

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

#49254 [Opn-Bgs]: setlocale affects math functions

 ID:   49254
 Updated by:   j...@php.net
 Reported By:  stakadush at yahoo dot com
-Status:   Open
+Status:   Bogus
 Bug Type: Math related
 Operating System: Ubuntu 9.04  OS X 10.5.7
 PHP Version:  5.3.0
 New Comment:

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




Previous Comments:


[2009-08-14 14:49:35] stakadush at yahoo dot com

Description:

setlocalte affects the return of math functions, making them unusable.
in this example the dot is being replaced with the italian comma 
notation.

Reproduce code:
---
setlocale(LC_ALL, 'it_IT.UTF-8');

echo abs(-5.5);

Expected result:

5.5

Actual result:
--
5,5





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

#49151 [Opn-Asn]: relocation must bind locally

 ID:   49151
 Updated by:   j...@php.net
 Reported By:  tech at uscki dot nl
-Status:   Open
+Status:   Assigned
 Bug Type: Compile Failure
 Operating System: Sun Solaris 5.10 (i386)
 PHP Version:  5.3.0
 Assigned To:  nlopess
 New Comment:

It should be as simple as adding 'static' in the macro
ZEND_DECLARE_MODULE_GLOBALS since those should be static anyway..




Previous Comments:


[2009-08-14 23:13:32] tech at uscki dot nl

Yeah, got it compiling! I removed -fvisibility=hidden from the
Makefile after running ./configure, guess that boils down to the same
result, though your suggestion is a bit tidier.

Compiler: gcc (GCC) 4.0.1

Thanks for all your help!



[2009-08-14 21:54:04] nlop...@php.net

sorry, I forgot to say that before ./configure you must run ./buildconf



[2009-08-14 16:49:14] nlop...@php.net

you can disable the visibility patch by editing the configure.in file
and removing the occurrence of -fvisibility=hidden. Then do a
./vcsclean  ./configure  make. Then please report if it worked, and
which compiler version you used. thanks.



[2009-08-14 10:08:07] tech at uscki dot nl

Hmmm, adding static isn't trivial, these first two methods were the tip
of the iceberg... Looks like I'll be adding it all through the code if I
go through with this (I stopped after about 10 changes in various
files). 

How do I disable the visibility thing, as Nuno noted?



[2009-08-13 10:01:53] j...@php.net

in ext/date/php_date.c:485, add static in front of this line:

ZEND_DECLARE_MODULE_GLOBALS(date)




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

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

#49278 [NEW]: SoapClient::__getLastResponseHeaders returns NULL if wsdl operation !has output

2009-08-17 Thread jeroen at asystance dot nl

From: jeroen at asystance dot nl
Operating system: linux
PHP version:  5.3SVN-2009-08-17 (snap)
PHP Bug Type: SOAP related
Bug description:  SoapClient::__getLastResponseHeaders returns NULL if wsdl 
operation !has output

Description:

For wsdl:operations that do not have output, SoapClient does not return
last response headers.

Reproduce code:
---
download http://jayvee.nl/soaptest3.tar
change URL in interface.wsdl to point to SOAPtest.php
SOAPtest.php contains both client and server code, so just run
php SOAPtest.php

Expected result:

SoapClient::getLastResponseHeaders should return string

Actual result:
--
SoapClient::getLastResponseHeaders returns NULL

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

#49276 [Bgs-Asn]: Sybase 15 incorrect library name references

 ID:   49276
 Updated by:   j...@php.net
 Reported By:  andy at networkjabber dot com
-Status:   Bogus
+Status:   Assigned
 Bug Type: Sybase-ct (ctlib) related
 Operating System: Fedora Core 9
 PHP Version:  5.3.0
-Assigned To:  
+Assigned To:  thekid
 New Comment:

Ok, so the patch works, lets keep this assigned to the maintainer then.
:)


Previous Comments:


[2009-08-17 10:15:27] andy at networkjabber dot com

Hi. 

Thanks for the quick reply. I can confirm that the patch works
correctly and PHP compiles correctly with the specified directives to
build Sybase ASE support. Perhaps it would be worth adding an extra
autoconf argument in subsequent PHP releases for Sybase ASE versions
previous to 12.5 and those later? i.e. --with-sybase-ct-oldlib or
--with-sybase-ct-newlib, for example. 

Many thanks,
Andy



[2009-08-17 09:36:09] j...@php.net

Bug #36516 was marked as being bogus because it was duplicate of bug
#45357 and both didn't get any feedback when asked to test this patch:

  http://sitten-polizei.de/php/sybase-configm4.diff

So please apply the patch, run ./buildconf --force and see if it works
then.



[2009-08-17 08:56:52] andy at networkjabber dot com

Description:

This problem was originally logged on 24/2/2006 under #36516, but
marked as bogus. However, the problem still exists. Sybase have changed
the library names of 4 of their ASE libraries: libsybcs, libsybct,
lsybcomn and lsybintl. The default automake profile references these as
-lcs -lct -lcomn -lintl so the compile fails with libraries being
reported as missing. Both ./configure and ./ext/sybase_ct/config.m4 need
to be editied so that these references are -lsybcs -lsybct -lsybcomn
-lsybsybintl. After these changes are made all compiles correctly.






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

#49276 [Asn]: Sybase 15 incorrect library name references

 ID:   49276
 Updated by:   j...@php.net
 Reported By:  andy at networkjabber dot com
 Status:   Assigned
 Bug Type: Sybase-ct (ctlib) related
 Operating System: Fedora Core 9
 PHP Version:  5.3.0
 Assigned To:  thekid
 New Comment:

Oh, and you don't need extra configure options with the patch since
then it detects the libs properly.. :)


Previous Comments:


[2009-08-17 11:15:43] j...@php.net

Ok, so the patch works, lets keep this assigned to the maintainer then.
:)



[2009-08-17 10:15:27] andy at networkjabber dot com

Hi. 

Thanks for the quick reply. I can confirm that the patch works
correctly and PHP compiles correctly with the specified directives to
build Sybase ASE support. Perhaps it would be worth adding an extra
autoconf argument in subsequent PHP releases for Sybase ASE versions
previous to 12.5 and those later? i.e. --with-sybase-ct-oldlib or
--with-sybase-ct-newlib, for example. 

Many thanks,
Andy



[2009-08-17 09:36:09] j...@php.net

Bug #36516 was marked as being bogus because it was duplicate of bug
#45357 and both didn't get any feedback when asked to test this patch:

  http://sitten-polizei.de/php/sybase-configm4.diff

So please apply the patch, run ./buildconf --force and see if it works
then.



[2009-08-17 08:56:52] andy at networkjabber dot com

Description:

This problem was originally logged on 24/2/2006 under #36516, but
marked as bogus. However, the problem still exists. Sybase have changed
the library names of 4 of their ASE libraries: libsybcs, libsybct,
lsybcomn and lsybintl. The default automake profile references these as
-lcs -lct -lcomn -lintl so the compile fails with libraries being
reported as missing. Both ./configure and ./ext/sybase_ct/config.m4 need
to be editied so that these references are -lsybcs -lsybct -lsybcomn
-lsybsybintl. After these changes are made all compiles correctly.






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

#49248 [Asn]: undefined reference to `zlib_globals'

 ID:   49248
 Updated by:   j...@php.net
-Summary:  make error
 Reported By:  e dot ehritt at web dot de
 Status:   Assigned
 Bug Type: Compile Failure
 Operating System: Linux/2.6.30.4 x86_64
 PHP Version:  5.3SVN-2009-08-14 (snap)
 Assigned To:  jani
 New Comment:

Related to fix for bug #48994


Previous Comments:


[2009-08-16 05:50:52] ka...@php.net

Jani, you changed to use ZLIBG in main, but unless thats exported it
cannot be used when its built shared. So we need to either export it or
just skip this part in main/ if zlib is shared.



[2009-08-14 00:07:02] e dot ehritt at web dot de

Description:

$ export CFLAGS=-march=athlon64 -O3 -pipe -fstack-protector
-fstack-protector-all export
EXTENSION_DIR=/home/eddi/opt/php/5.3.0/lib ./configure
--prefix=/home/eddi/opt/php/5.3.0 --mandir=/home/eddi/opt/man
--build=x86_64-pc-linux-gnu --with-config-file-path=/home/eddi/opt/conf
--with-zend-vm=GOTO --disable-all --with-bz2=shared --with-curl=shared
--with-curlwrappers --with-gd=shared --with-gettext=shared
--with-iconv=shared --with-openssl=shared --with-regex=shared
--with-xmlrpc=shared --with-xsl=shared --with-zlib=shared
--enable-bcmath=shared --enable-calendar=shared --enable-ctype=shared
--enable-dom=shared --enable-exif=shared --enable-fileinfo=shared
--enable-filter=shared --enable-ftp=shared --enable-hash=shared
--enable-libxml=shared --enable-pcntl=shared --enable-phar=shared
--enable-posix=shared --enable-shmop=shared --enable-simplexml=shared
--enable-soap=shared --enable-sockets=shared --enable-sysvmsg=shared
--enable-sysvsem=shared --enable-sysvshm=shared
--enable-tokenizer=shared --enable-wddx=shared --enable-xml=shared
--enable-xmlreader=shared --enable-xmlwriter=shared --enable-zip=shared
--enable-sigchild --enable-cgi --disable-short-tags


$ make  /dev/null

/home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c: In function
'date_format':
/home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c:1058:
warning: incompatible implicit declaration of built-in function 'llabs'
/home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c: In function
'_php_stream_cast':
/home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:222:
warning: cast to pointer from integer of different size
/home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:225:
warning: cast to pointer from integer of different size
/home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c: In function
'zend_objects_destroy_object':
/home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c:95: warning:
assignment discards qualifiers from pointer target type
main/.libs/SAPI.o: In function `sapi_send_headers':
SAPI.c:(.text+0x1fca): undefined reference to `zlib_globals'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1



Reproduce code:
---
$ gcc -v

Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror
--enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp --disable-libgcj
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r3
p1.6, pie-10.1.5'
Thread model: posix
gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5)


$ ld -v

GNU ld (GNU Binutils) 2.18








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

#49274 [Fbk]: filter_var() should accept objects without fatal error

2009-08-17 Thread cellog

 ID:   49274
 Updated by:   cel...@php.net
 Reported By:  cel...@php.net
 Status:   Feedback
 Bug Type: Filter related
 Operating System: *
 PHP Version:  5.3SVN-2009-08-16 (SVN)
 New Comment:

don't know, that's up to the developers to decide, don't you think?


Previous Comments:


[2009-08-17 09:32:59] j...@php.net

Does this happen ONLY with PHP_5_3 branch? If not, please use the
proper version string.



[2009-08-16 22:09:05] cel...@php.net

Description:

?php
filter_var(new stdClass, FILTER_VALIDATE_EMAIL);
?

throws a fatal error because stdClass can't be converted into a string.
 filter_var() should be more flexible and simply return false in this
situation, it makes it very difficult to provide validation not just for
untrusted user input but for untrusted third party use of libraries who
may make it insecure by passing in the wrong value to a field for
setting.






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

#42516 [Csd-Opn]: FILE resolves symlinks - not mentioned in manual

2009-08-17 Thread michael at zedeler dot dk

 ID:   42516
 User updated by:  michael at zedeler dot dk
 Reported By:  michael at zedeler dot dk
-Status:   Closed
+Status:   Open
-Bug Type: Documentation problem
+Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  4.4.7
 Assigned To:  bjori
 New Comment:

Moved to Feature/Change request category.


Previous Comments:


[2009-04-24 05:58:24] bj...@php.net

Please use the developers mailinglist for feature discussions
(intern...@lists.php.net).



[2009-04-23 18:51:59] michael at zedeler dot dk

Wrong category.



[2009-04-23 17:53:20] michael at zedeler dot dk

Sorry to bug you again, but as I am writing in the report, just putting
a description of the errant behaviour is not a useful fix.



[2008-04-13 23:46:35] bj...@php.net

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.





[2007-09-01 21:02:38] michael at zedeler dot dk

Description:

__FILE__ does not return the path used to invoke the current file, but
resolves symlinks.

This behaviour is extremely problematics, since important information
is thrown away. The web is teeming with postings from people that are
experiencing problems because of this.

In http://bugs.php.net/bug.php?id=37603 this bug was mentioned and the
response was that it is intended behavior with a reference to the
manual.

The page

http://es.php.net/manual/en/language.constants.predefined.php

is the primary source of information for __FILE__, and it does not
mention resolving symlinks at all.

I'd like if we could have som kind of dialogue about how to solve the
problem, in stead of just having this bug being closed with a Bogus
status.

My suggestions are:

 1) introduce a new magical constant that behaves as it should.
 2) put a parameter in php.ini that changes how __FILE__ behaves.


Reproduce code:
---
This is basically a reopening of http://bugs.php.net/bug.php?id=37603

Expected result:

This is basically a reopening of http://bugs.php.net/bug.php?id=37603

Actual result:
--
This is basically a reopening of http://bugs.php.net/bug.php?id=37603





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

#42516 [Opn]: FILE resolves symlinks

2009-08-17 Thread michael at zedeler dot dk

 ID:   42516
 User updated by:  michael at zedeler dot dk
-Summary:  __FILE__ resolves symlinks - not mentioned in manual
 Reported By:  michael at zedeler dot dk
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: Linux
 PHP Version:  4.4.7
 Assigned To:  bjori
 New Comment:

Fixed subject.


Previous Comments:


[2009-08-17 12:56:08] michael at zedeler dot dk

Moved to Feature/Change request category.



[2009-04-24 05:58:24] bj...@php.net

Please use the developers mailinglist for feature discussions
(intern...@lists.php.net).



[2009-04-23 18:51:59] michael at zedeler dot dk

Wrong category.



[2009-04-23 17:53:20] michael at zedeler dot dk

Sorry to bug you again, but as I am writing in the report, just putting
a description of the errant behaviour is not a useful fix.



[2008-04-13 23:46:35] bj...@php.net

This bug has been fixed in the documentation's XML sources. Since the
online and downloadable versions of the documentation need some time
to get updated, we would like to ask you to be a bit patient.

Thank you for the report, and for helping us make our documentation
better.





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

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

#49274 [Fbk-Bgs]: filter_var() should accept objects without fatal error

 ID:   49274
 Updated by:   j...@php.net
 Reported By:  cel...@php.net
-Status:   Feedback
+Status:   Bogus
 Bug Type: Filter related
 Operating System: *
 PHP Version:  5.3SVN-2009-08-16 (SVN)
 New Comment:

This is not a bug. It's exactly what's supposed to happen. When you
pass crap in you get crap out. The language isn't supposed to hold your
hand in every corner.


Previous Comments:


[2009-08-17 11:45:09] cel...@php.net

don't know, that's up to the developers to decide, don't you think?



[2009-08-17 09:32:59] j...@php.net

Does this happen ONLY with PHP_5_3 branch? If not, please use the
proper version string.



[2009-08-16 22:09:05] cel...@php.net

Description:

?php
filter_var(new stdClass, FILTER_VALIDATE_EMAIL);
?

throws a fatal error because stdClass can't be converted into a string.
 filter_var() should be more flexible and simply return false in this
situation, it makes it very difficult to provide validation not just for
untrusted user input but for untrusted third party use of libraries who
may make it insecure by passing in the wrong value to a field for
setting.






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

#49248 [Asn]: undefined reference to `zlib_globals'

 ID:   49248
 Updated by:   j...@php.net
 Reported By:  e dot ehritt at web dot de
 Status:   Assigned
 Bug Type: Compile Failure
 Operating System: *
-PHP Version:  5.*, 6
+PHP Version:  5.*
 Assigned To:  jani
 New Comment:

And this is 5.* only, HEAD has better output handling.


Previous Comments:


[2009-08-17 11:28:35] j...@php.net

Related to fix for bug #48994



[2009-08-16 05:50:52] ka...@php.net

Jani, you changed to use ZLIBG in main, but unless thats exported it
cannot be used when its built shared. So we need to either export it or
just skip this part in main/ if zlib is shared.



[2009-08-14 00:07:02] e dot ehritt at web dot de

Description:

$ export CFLAGS=-march=athlon64 -O3 -pipe -fstack-protector
-fstack-protector-all export
EXTENSION_DIR=/home/eddi/opt/php/5.3.0/lib ./configure
--prefix=/home/eddi/opt/php/5.3.0 --mandir=/home/eddi/opt/man
--build=x86_64-pc-linux-gnu --with-config-file-path=/home/eddi/opt/conf
--with-zend-vm=GOTO --disable-all --with-bz2=shared --with-curl=shared
--with-curlwrappers --with-gd=shared --with-gettext=shared
--with-iconv=shared --with-openssl=shared --with-regex=shared
--with-xmlrpc=shared --with-xsl=shared --with-zlib=shared
--enable-bcmath=shared --enable-calendar=shared --enable-ctype=shared
--enable-dom=shared --enable-exif=shared --enable-fileinfo=shared
--enable-filter=shared --enable-ftp=shared --enable-hash=shared
--enable-libxml=shared --enable-pcntl=shared --enable-phar=shared
--enable-posix=shared --enable-shmop=shared --enable-simplexml=shared
--enable-soap=shared --enable-sockets=shared --enable-sysvmsg=shared
--enable-sysvsem=shared --enable-sysvshm=shared
--enable-tokenizer=shared --enable-wddx=shared --enable-xml=shared
--enable-xmlreader=shared --enable-xmlwriter=shared --enable-zip=shared
--enable-sigchild --enable-cgi --disable-short-tags


$ make  /dev/null

/home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c: In function
'date_format':
/home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c:1058:
warning: incompatible implicit declaration of built-in function 'llabs'
/home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c: In function
'_php_stream_cast':
/home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:222:
warning: cast to pointer from integer of different size
/home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:225:
warning: cast to pointer from integer of different size
/home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c: In function
'zend_objects_destroy_object':
/home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c:95: warning:
assignment discards qualifiers from pointer target type
main/.libs/SAPI.o: In function `sapi_send_headers':
SAPI.c:(.text+0x1fca): undefined reference to `zlib_globals'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1



Reproduce code:
---
$ gcc -v

Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror
--enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp --disable-libgcj
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r3
p1.6, pie-10.1.5'
Thread model: posix
gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5)


$ ld -v

GNU ld (GNU Binutils) 2.18








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

#49274 [Bgs-Opn]: filter_var() should accept objects without fatal error

2009-08-17 Thread cellog

 ID:   49274
 Updated by:   cel...@php.net
 Reported By:  cel...@php.net
-Status:   Bogus
+Status:   Open
 Bug Type: Filter related
 Operating System: *
 PHP Version:  5.3SVN-2009-08-16 (SVN)
 New Comment:

?php
var_dump(filter_var(null, FILTER_VALIDATE_INT));
var_dump(filter_var(array(), FILTER_VALIDATE_INT));
var_dump(filter_var('hi', FILTER_VALIDATE_INT));
var_dump(filter_var(1.1, FILTER_VALIDATE_INT));
var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT));
var_dump(filter_var(1, FILTER_VALIDATE_INT));
var_dump(filter_var('1.0', FILTER_VALIDATE_INT));
?

all work without error.

?php
class blah {function __toString(){return '1';}}
var_dump(filter_var(new blah, FILTER_VALIDATE_INT));
?

works without error.

Only filter_var with an object that doesn't implement __toString fails
with an error.  Either filter is incorrectly returning false with no
error on all of those other random types, or you're wrong, Jani.


Previous Comments:


[2009-08-17 13:13:43] j...@php.net

This is not a bug. It's exactly what's supposed to happen. When you
pass crap in you get crap out. The language isn't supposed to hold your
hand in every corner.



[2009-08-17 11:45:09] cel...@php.net

don't know, that's up to the developers to decide, don't you think?



[2009-08-17 09:32:59] j...@php.net

Does this happen ONLY with PHP_5_3 branch? If not, please use the
proper version string.



[2009-08-16 22:09:05] cel...@php.net

Description:

?php
filter_var(new stdClass, FILTER_VALIDATE_EMAIL);
?

throws a fatal error because stdClass can't be converted into a string.
 filter_var() should be more flexible and simply return false in this
situation, it makes it very difficult to provide validation not just for
untrusted user input but for untrusted third party use of libraries who
may make it insecure by passing in the wrong value to a field for
setting.






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

#49279 [NEW]: Current does not seem to work with Iterator

2009-08-17 Thread andrew at ajohnstone dot com

From: andrew at ajohnstone dot com
Operating system: debain
PHP version:  5.2.10
PHP Bug Type: *General Issues
Bug description:  Current does not seem to work with Iterator

Description:

Current does not seem to work with Iterator

Reproduce code:
---
?php

class test implements IteratorAggregate, Iterator {

protected $_data = array(
0=1,
1=2,
2=3,
3=4,
4=5,
);

public function getIterator() {
var_dump(__FUNCTION__);
return $this-getCurrentItems();
}

public function getCurrentItems() {
return $this-_data;
}

public function current() {
var_dump(__FUNCTION__);
$this-_data = $this-getCurrentItems();
return current($this-_data);
}

public function key() {
var_dump(__FUNCTION__);
return key($this-_data);
}

public function next() {
var_dump(__FUNCTION__);
next($this-_data);
}

public function rewind() {
var_dump(__FUNCTION__);
$this-_data = $this-getCurrentItems();
$this-_pointer = 0;
reset($this-_data);
}

public function valid() {
var_dump(__FUNCTION__);
return (current($this-_data) !== FALSE);
}


}

$c = new test();
var_dump(current($c));


Expected result:

string 'current' (length=7)
1

Actual result:
--
bool(false)

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

#49274 [Opn-Fbk]: filter_var() should accept objects without fatal error

 ID:   49274
 Updated by:   paj...@php.net
 Reported By:  cel...@php.net
-Status:   Open
+Status:   Feedback
 Bug Type: Filter related
 Operating System: *
 PHP Version:  5.3SVN-2009-08-16 (SVN)
 New Comment:

As StdClass has no __toString implementation (obviously), it can't be
converted to string.

I tend to agree that it should not raise a fatal (recovable error) here
as it defeats the main purpose of this API.

I'm however not sure it is worth the effort to add custom error handler
for this edge case. Patch welcome, it could help to get this edge case
solved (I can't work on this exact issue any time soon).


Previous Comments:


[2009-08-17 13:27:50] cel...@php.net

?php
var_dump(filter_var(null, FILTER_VALIDATE_INT));
var_dump(filter_var(array(), FILTER_VALIDATE_INT));
var_dump(filter_var('hi', FILTER_VALIDATE_INT));
var_dump(filter_var(1.1, FILTER_VALIDATE_INT));
var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT));
var_dump(filter_var(1, FILTER_VALIDATE_INT));
var_dump(filter_var('1.0', FILTER_VALIDATE_INT));
?

all work without error.

?php
class blah {function __toString(){return '1';}}
var_dump(filter_var(new blah, FILTER_VALIDATE_INT));
?

works without error.

Only filter_var with an object that doesn't implement __toString fails
with an error.  Either filter is incorrectly returning false with no
error on all of those other random types, or you're wrong, Jani.



[2009-08-17 13:13:43] j...@php.net

This is not a bug. It's exactly what's supposed to happen. When you
pass crap in you get crap out. The language isn't supposed to hold your
hand in every corner.



[2009-08-17 11:45:09] cel...@php.net

don't know, that's up to the developers to decide, don't you think?



[2009-08-17 09:32:59] j...@php.net

Does this happen ONLY with PHP_5_3 branch? If not, please use the
proper version string.



[2009-08-16 22:09:05] cel...@php.net

Description:

?php
filter_var(new stdClass, FILTER_VALIDATE_EMAIL);
?

throws a fatal error because stdClass can't be converted into a string.
 filter_var() should be more flexible and simply return false in this
situation, it makes it very difficult to provide validation not just for
untrusted user input but for untrusted third party use of libraries who
may make it insecure by passing in the wrong value to a field for
setting.






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

#49274 [Fbk]: filter_var() should accept objects without fatal error

2009-08-17 Thread cellog

 ID:   49274
 Updated by:   cel...@php.net
 Reported By:  cel...@php.net
 Status:   Feedback
 Bug Type: Filter related
 Operating System: *
 PHP Version:  5.3SVN-2009-08-16 (SVN)
 New Comment:

the stdClass was just to illustrate the point, this happens with any
object that doesn't have a __toString().  I would imagine it would be
easier to check for IS_OBJECT and then see if it implements __toString
than to do a custom error handler.  The performance should be about the
same (dismal).


Previous Comments:


[2009-08-17 13:48:45] paj...@php.net

As StdClass has no __toString implementation (obviously), it can't be
converted to string.

I tend to agree that it should not raise a fatal (recovable error) here
as it defeats the main purpose of this API.

I'm however not sure it is worth the effort to add custom error handler
for this edge case. Patch welcome, it could help to get this edge case
solved (I can't work on this exact issue any time soon).



[2009-08-17 13:27:50] cel...@php.net

?php
var_dump(filter_var(null, FILTER_VALIDATE_INT));
var_dump(filter_var(array(), FILTER_VALIDATE_INT));
var_dump(filter_var('hi', FILTER_VALIDATE_INT));
var_dump(filter_var(1.1, FILTER_VALIDATE_INT));
var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT));
var_dump(filter_var(1, FILTER_VALIDATE_INT));
var_dump(filter_var('1.0', FILTER_VALIDATE_INT));
?

all work without error.

?php
class blah {function __toString(){return '1';}}
var_dump(filter_var(new blah, FILTER_VALIDATE_INT));
?

works without error.

Only filter_var with an object that doesn't implement __toString fails
with an error.  Either filter is incorrectly returning false with no
error on all of those other random types, or you're wrong, Jani.



[2009-08-17 13:13:43] j...@php.net

This is not a bug. It's exactly what's supposed to happen. When you
pass crap in you get crap out. The language isn't supposed to hold your
hand in every corner.



[2009-08-17 11:45:09] cel...@php.net

don't know, that's up to the developers to decide, don't you think?



[2009-08-17 09:32:59] j...@php.net

Does this happen ONLY with PHP_5_3 branch? If not, please use the
proper version string.



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

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

#49279 [Opn-Bgs]: Current does not seem to work with Iterator

2009-08-17 Thread scottmac

 ID:   49279
 Updated by:   scott...@php.net
 Reported By:  andrew at ajohnstone dot com
-Status:   Open
+Status:   Bogus
 Bug Type: *General Issues
 Operating System: debain
 PHP Version:  5.2.10
 New Comment:

None of the array functions work with iterator interface, its designed
to allow you iterate through objects with foreach() / while().


Previous Comments:


[2009-08-17 13:45:24] andrew at ajohnstone dot com

Description:

Current does not seem to work with Iterator

Reproduce code:
---
?php

class test implements IteratorAggregate, Iterator {

protected $_data = array(
0=1,
1=2,
2=3,
3=4,
4=5,
);

public function getIterator() {
var_dump(__FUNCTION__);
return $this-getCurrentItems();
}

public function getCurrentItems() {
return $this-_data;
}

public function current() {
var_dump(__FUNCTION__);
$this-_data = $this-getCurrentItems();
return current($this-_data);
}

public function key() {
var_dump(__FUNCTION__);
return key($this-_data);
}

public function next() {
var_dump(__FUNCTION__);
next($this-_data);
}

public function rewind() {
var_dump(__FUNCTION__);
$this-_data = $this-getCurrentItems();
$this-_pointer = 0;
reset($this-_data);
}

public function valid() {
var_dump(__FUNCTION__);
return (current($this-_data) !== FALSE);
}


}

$c = new test();
var_dump(current($c));


Expected result:

string 'current' (length=7)
1

Actual result:
--
bool(false)





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

#49274 [Fbk-Ana]: filter_var() should accept objects without fatal error

 ID:   49274
 Updated by:   paj...@php.net
 Reported By:  cel...@php.net
-Status:   Feedback
+Status:   Analyzed
 Bug Type: Filter related
 Operating System: *
 PHP Version:  5.3SVN-2009-08-16 (SVN)
 New Comment:

it is indeed valid for all objects but it is still an edge case.

A check for IS_OBJECT + tostring() existence could be easy enough and
with almost no impact(perf impact is null on the existing application).
If you have some time to write one, go ahead.


Previous Comments:


[2009-08-17 13:52:56] cel...@php.net

the stdClass was just to illustrate the point, this happens with any
object that doesn't have a __toString().  I would imagine it would be
easier to check for IS_OBJECT and then see if it implements __toString
than to do a custom error handler.  The performance should be about the
same (dismal).



[2009-08-17 13:48:45] paj...@php.net

As StdClass has no __toString implementation (obviously), it can't be
converted to string.

I tend to agree that it should not raise a fatal (recovable error) here
as it defeats the main purpose of this API.

I'm however not sure it is worth the effort to add custom error handler
for this edge case. Patch welcome, it could help to get this edge case
solved (I can't work on this exact issue any time soon).



[2009-08-17 13:27:50] cel...@php.net

?php
var_dump(filter_var(null, FILTER_VALIDATE_INT));
var_dump(filter_var(array(), FILTER_VALIDATE_INT));
var_dump(filter_var('hi', FILTER_VALIDATE_INT));
var_dump(filter_var(1.1, FILTER_VALIDATE_INT));
var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT));
var_dump(filter_var(1, FILTER_VALIDATE_INT));
var_dump(filter_var('1.0', FILTER_VALIDATE_INT));
?

all work without error.

?php
class blah {function __toString(){return '1';}}
var_dump(filter_var(new blah, FILTER_VALIDATE_INT));
?

works without error.

Only filter_var with an object that doesn't implement __toString fails
with an error.  Either filter is incorrectly returning false with no
error on all of those other random types, or you're wrong, Jani.



[2009-08-17 13:13:43] j...@php.net

This is not a bug. It's exactly what's supposed to happen. When you
pass crap in you get crap out. The language isn't supposed to hold your
hand in every corner.



[2009-08-17 11:45:09] cel...@php.net

don't know, that's up to the developers to decide, don't you think?



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

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

#49280 [NEW]: Not possible to detect mysqlnd in php

From: ar at ez dot no
Operating system: All
PHP version:  5.3.0
PHP Bug Type: MySQLi related
Bug description:  Not possible to detect mysqlnd in php

Description:

There doesn't seem to be possible to cleanly* detect that mysqlnd is
currently in use.


* Constant would be nice, preferably already in 5.3.next
Detecting by presence off 'mysqli_fetch_all' or other functions is not
exactly clean.

Use case: Disabling / enabling Persistent Connections based on application
specific settings.
See: http://issues.ez.no/IssueView.php?Id=15315


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

#49281 [NEW]: Using . operator whilst assigning to a property gives misleading error.

2009-08-17 Thread RQuadling at GMail dot com

From: RQuadling at GMail dot com
Operating system: Irrelevant
PHP version:  5.3SVN-2009-08-17 (snap)
PHP Bug Type: Feature/Change Request
Bug description:  Using . operator whilst assigning to a property gives 
misleading error.

Description:

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

The Config.php class is using . to create a property.

The error that is generated is appropriate, but I feel it is misleading.

The error is different under slightly different circumstances.

The 2 scripts below show what I mean.

Having said that, the elements being concatenated are constant, so I 
believe there is some argument that these are NOT dynamic as say a 
function call would be.



Reproduce code:
---
= Test1.php =
?php
class Config {
public $string = __DIR__ . 'something';
}
?



= Test2.php =
?php
class Config {
public $array = array(__DIR__ . 'something');
}


Expected result:

An error along the lines that you cannot assign dynamic values to 
properties during class creation.



Actual result:
--
= Test1.php =
Parse error: parse error, expecting `','' or `';'' in Z:\Test1.php on 
line 3

= Test2.php =
Parse error: parse error, expecting `')'' in Z:\Test2.php on line 3



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

#49280 [Com]: Not possible to detect mysqlnd in php

 ID:   49280
 Comment by:   ar at ez dot no
 Reported By:  ar at ez dot no
 Status:   Open
 Bug Type: MySQLi related
 Operating System: All
 PHP Version:  5.3.0
 New Comment:

Seems to be possible with something like this as well:

strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false

But constant would still be a bit cleaner.


Previous Comments:


[2009-08-17 14:10:00] ar at ez dot no

Description:

There doesn't seem to be possible to cleanly* detect that mysqlnd is
currently in use.


* Constant would be nice, preferably already in 5.3.next
Detecting by presence off 'mysqli_fetch_all' or other functions is not
exactly clean.

Use case: Disabling / enabling Persistent Connections based on
application specific settings.
See: http://issues.ez.no/IssueView.php?Id=15315






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

#49280 [Opn-Fbk]: Not possible to detect mysqlnd in php

 ID:   49280
 Updated by:   j...@php.net
 Reported By:  ar at ez dot no
-Status:   Open
+Status:   Feedback
 Bug Type: MySQLi related
 Operating System: *
 PHP Version:  5.3.0
 New Comment:

So you want to circumvent a bug by adding a constant instead of fixing
the actual bug? Can you please explain WHAT does not work like it should
when you have enabled mysqlnd..?


Previous Comments:


[2009-08-17 14:21:35] ar at ez dot no

Seems to be possible with something like this as well:

strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false

But constant would still be a bit cleaner.



[2009-08-17 14:10:00] ar at ez dot no

Description:

There doesn't seem to be possible to cleanly* detect that mysqlnd is
currently in use.


* Constant would be nice, preferably already in 5.3.next
Detecting by presence off 'mysqli_fetch_all' or other functions is not
exactly clean.

Use case: Disabling / enabling Persistent Connections based on
application specific settings.
See: http://issues.ez.no/IssueView.php?Id=15315






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

#49280 [Com]: Not possible to detect mysqlnd in php

 ID:   49280
 Comment by:   ar at ez dot no
 Reported By:  ar at ez dot no
 Status:   Feedback
 Bug Type: MySQLi related
 Operating System: *
 PHP Version:  5.3.0
 New Comment:

Hi jani!

I'm not trying to workaround anything, its just that Persistent
Connections are only supported on mysqli when mysqlnd is used.

So it doesn't help to detect php version using PHP_VERSION, as the end
user might have mysqlnd disabled / not compiled in.

It is possible to detect it by by using function_exists. But since you
guys might add those extra mysqlnd functions to the other mysql driver
as well, that is not reliable not to mention clean.
see: http://no.php.net/mysqli.mysqlnd

For what I'm trying to do:
eZ Publish like other php projects abstracts things, one of those is
Persistent connection, witch is abstracted into a ini setting
(changeable in admin gui). So I need to prepend p: IF user has
mysqlnd, or trow a warning about unsupported setting.


Previous Comments:


[2009-08-17 14:30:15] j...@php.net

So you want to circumvent a bug by adding a constant instead of fixing
the actual bug? Can you please explain WHAT does not work like it should
when you have enabled mysqlnd..?



[2009-08-17 14:21:35] ar at ez dot no

Seems to be possible with something like this as well:

strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false

But constant would still be a bit cleaner.



[2009-08-17 14:10:00] ar at ez dot no

Description:

There doesn't seem to be possible to cleanly* detect that mysqlnd is
currently in use.


* Constant would be nice, preferably already in 5.3.next
Detecting by presence off 'mysqli_fetch_all' or other functions is not
exactly clean.

Use case: Disabling / enabling Persistent Connections based on
application specific settings.
See: http://issues.ez.no/IssueView.php?Id=15315






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

#49280 [Fbk-Opn]: Not possible to detect mysqlnd in php

 ID:   49280
 User updated by:  ar at ez dot no
 Reported By:  ar at ez dot no
-Status:   Feedback
+Status:   Open
 Bug Type: MySQLi related
 Operating System: *
 PHP Version:  5.3.0
 New Comment:

see above comment.


Previous Comments:


[2009-08-17 14:53:12] ar at ez dot no

Hi jani!

I'm not trying to workaround anything, its just that Persistent
Connections are only supported on mysqli when mysqlnd is used.

So it doesn't help to detect php version using PHP_VERSION, as the end
user might have mysqlnd disabled / not compiled in.

It is possible to detect it by by using function_exists. But since you
guys might add those extra mysqlnd functions to the other mysql driver
as well, that is not reliable not to mention clean.
see: http://no.php.net/mysqli.mysqlnd

For what I'm trying to do:
eZ Publish like other php projects abstracts things, one of those is
Persistent connection, witch is abstracted into a ini setting
(changeable in admin gui). So I need to prepend p: IF user has
mysqlnd, or trow a warning about unsupported setting.



[2009-08-17 14:30:15] j...@php.net

So you want to circumvent a bug by adding a constant instead of fixing
the actual bug? Can you please explain WHAT does not work like it should
when you have enabled mysqlnd..?



[2009-08-17 14:21:35] ar at ez dot no

Seems to be possible with something like this as well:

strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false

But constant would still be a bit cleaner.



[2009-08-17 14:10:00] ar at ez dot no

Description:

There doesn't seem to be possible to cleanly* detect that mysqlnd is
currently in use.


* Constant would be nice, preferably already in 5.3.next
Detecting by presence off 'mysqli_fetch_all' or other functions is not
exactly clean.

Use case: Disabling / enabling Persistent Connections based on
application specific settings.
See: http://issues.ez.no/IssueView.php?Id=15315






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

#49282 [NEW]: importNode() looses namespaceURI value

2009-08-17 Thread daniel at webdevelopers dot cz

From: daniel at webdevelopers dot cz
Operating system: Ubuntu 2.6.21 i686
PHP version:  5.3.0
PHP Bug Type: DOM XML related
Bug description:  importNode() looses namespaceURI value

Description:

libxml 2.6.31

When importing previously removed element into the new document the
namespaceURI is not preserved.

It is preserved only if the @xmlns declaration attribute is present on the
element itself. Does not work if it was declared on former ancestor.

Reproduce code:
---
$rcpt=new DOMDocument; $rcpt-loadXML(rcpt/rcpt);
// XMLNS on parent
$dnr1=new DOMDocument; $dnr1-loadXML(dnr
xmlns:sys='http://www.1stomni.com/spire'sys:donate//dnr);
// XMLNS on element
$dnr2=new DOMDocument; $dnr2-loadXML(dnrsys:donate
xmlns:sys='http://www.1stomni.com/spire'//dnr);

getGift($rcpt,
$dnr1-documentElement-removeChild($dnr1-documentElement-firstChild));
getGift($rcpt,
$dnr2-documentElement-removeChild($dnr2-documentElement-firstChild));

function getGift($dom, $gift) {
echo before: \$gift-namespaceURI\; after:
\.$dom-documentElement-appendChild($dom-importNode($gift))-namespaceURI.\\n;
}


Expected result:

before: http://www.1stomni.com/spire;; after:
http://www.1stomni.com/spire;
before: http://www.1stomni.com/spire;; after:
http://www.1stomni.com/spire;


Actual result:
--
before: http://www.1stomni.com/spire;; after: 
before: http://www.1stomni.com/spire;; after:
http://www.1stomni.com/spire;


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

#49280 [Opn]: ext/mysqlnd: Not possible to detect mysqlnd in php

 ID:   49280
 Updated by:   j...@php.net
-Summary:  Not possible to detect mysqlnd in php
 Reported By:  ar at ez dot no
 Status:   Open
-Bug Type: MySQLi related
+Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.3.0
 New Comment:

p: is allowed always since PHP 5.3.0. You only get a warning when
someone has disabled persistent connections with mysqli.allow_persistent
ini option. You don't need to know whether it's mysqlnd or libmysql that
is used. And you really should be checking if mysql*.allow_persistent is
on or off anyway. :)



Previous Comments:


[2009-08-17 14:53:12] ar at ez dot no

Hi jani!

I'm not trying to workaround anything, its just that Persistent
Connections are only supported on mysqli when mysqlnd is used.

So it doesn't help to detect php version using PHP_VERSION, as the end
user might have mysqlnd disabled / not compiled in.

It is possible to detect it by by using function_exists. But since you
guys might add those extra mysqlnd functions to the other mysql driver
as well, that is not reliable not to mention clean.
see: http://no.php.net/mysqli.mysqlnd

For what I'm trying to do:
eZ Publish like other php projects abstracts things, one of those is
Persistent connection, witch is abstracted into a ini setting
(changeable in admin gui). So I need to prepend p: IF user has
mysqlnd, or trow a warning about unsupported setting.



[2009-08-17 14:30:15] j...@php.net

So you want to circumvent a bug by adding a constant instead of fixing
the actual bug? Can you please explain WHAT does not work like it should
when you have enabled mysqlnd..?



[2009-08-17 14:21:35] ar at ez dot no

Seems to be possible with something like this as well:

strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false

But constant would still be a bit cleaner.



[2009-08-17 14:10:00] ar at ez dot no

Description:

There doesn't seem to be possible to cleanly* detect that mysqlnd is
currently in use.


* Constant would be nice, preferably already in 5.3.next
Detecting by presence off 'mysqli_fetch_all' or other functions is not
exactly clean.

Use case: Disabling / enabling Persistent Connections based on
application specific settings.
See: http://issues.ez.no/IssueView.php?Id=15315






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

#49280 [Opn]: ext/mysqlnd: Not possible to detect mysqlnd in php

 ID:   49280
 User updated by:  ar at ez dot no
 Reported By:  ar at ez dot no
 Status:   Open
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.3.0
 New Comment:

 And you really should be checking if mysql*.allow_persistent is
on or off anyway

We don't need hide php warnings, so if php trows a understandable
warning in such a case, then that would be sufficient.

So, for my use case this is not valid anymore then, Thanks;)

But as long as mysqlnd behaves differently then the old mysql client, I
would vote for such a constant anyway. Or you can close with reference
to the first comment(2:21) on how to detect mysqlnd if you absolutely
need to know about it in code.


Previous Comments:


[2009-08-17 17:18:45] j...@php.net

p: is allowed always since PHP 5.3.0. You only get a warning when
someone has disabled persistent connections with mysqli.allow_persistent
ini option. You don't need to know whether it's mysqlnd or libmysql that
is used. And you really should be checking if mysql*.allow_persistent is
on or off anyway. :)




[2009-08-17 14:53:12] ar at ez dot no

Hi jani!

I'm not trying to workaround anything, its just that Persistent
Connections are only supported on mysqli when mysqlnd is used.

So it doesn't help to detect php version using PHP_VERSION, as the end
user might have mysqlnd disabled / not compiled in.

It is possible to detect it by by using function_exists. But since you
guys might add those extra mysqlnd functions to the other mysql driver
as well, that is not reliable not to mention clean.
see: http://no.php.net/mysqli.mysqlnd

For what I'm trying to do:
eZ Publish like other php projects abstracts things, one of those is
Persistent connection, witch is abstracted into a ini setting
(changeable in admin gui). So I need to prepend p: IF user has
mysqlnd, or trow a warning about unsupported setting.



[2009-08-17 14:30:15] j...@php.net

So you want to circumvent a bug by adding a constant instead of fixing
the actual bug? Can you please explain WHAT does not work like it should
when you have enabled mysqlnd..?



[2009-08-17 14:21:35] ar at ez dot no

Seems to be possible with something like this as well:

strpos( mysqli_get_client_info(), 'mysqlnd ' ) !== false

But constant would still be a bit cleaner.



[2009-08-17 14:10:00] ar at ez dot no

Description:

There doesn't seem to be possible to cleanly* detect that mysqlnd is
currently in use.


* Constant would be nice, preferably already in 5.3.next
Detecting by presence off 'mysqli_fetch_all' or other functions is not
exactly clean.

Use case: Disabling / enabling Persistent Connections based on
application specific settings.
See: http://issues.ez.no/IssueView.php?Id=15315






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

#49248 [Asn-Csd]: undefined reference to `zlib_globals'

 ID:   49248
 Updated by:   j...@php.net
 Reported By:  e dot ehritt at web dot de
-Status:   Assigned
+Status:   Closed
 Bug Type: Compile Failure
 Operating System: *
 PHP Version:  5.*
 Assigned To:  jani


Previous Comments:


[2009-08-17 17:30:33] s...@php.net

Automatic comment from SVN on behalf of jani
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287423
Log: - Fixed bug #49248 by fixing bug #48994 properly



[2009-08-17 13:15:31] j...@php.net

And this is 5.* only, HEAD has better output handling.



[2009-08-17 11:28:35] j...@php.net

Related to fix for bug #48994



[2009-08-16 05:50:52] ka...@php.net

Jani, you changed to use ZLIBG in main, but unless thats exported it
cannot be used when its built shared. So we need to either export it or
just skip this part in main/ if zlib is shared.



[2009-08-14 00:07:02] e dot ehritt at web dot de

Description:

$ export CFLAGS=-march=athlon64 -O3 -pipe -fstack-protector
-fstack-protector-all export
EXTENSION_DIR=/home/eddi/opt/php/5.3.0/lib ./configure
--prefix=/home/eddi/opt/php/5.3.0 --mandir=/home/eddi/opt/man
--build=x86_64-pc-linux-gnu --with-config-file-path=/home/eddi/opt/conf
--with-zend-vm=GOTO --disable-all --with-bz2=shared --with-curl=shared
--with-curlwrappers --with-gd=shared --with-gettext=shared
--with-iconv=shared --with-openssl=shared --with-regex=shared
--with-xmlrpc=shared --with-xsl=shared --with-zlib=shared
--enable-bcmath=shared --enable-calendar=shared --enable-ctype=shared
--enable-dom=shared --enable-exif=shared --enable-fileinfo=shared
--enable-filter=shared --enable-ftp=shared --enable-hash=shared
--enable-libxml=shared --enable-pcntl=shared --enable-phar=shared
--enable-posix=shared --enable-shmop=shared --enable-simplexml=shared
--enable-soap=shared --enable-sockets=shared --enable-sysvmsg=shared
--enable-sysvsem=shared --enable-sysvshm=shared
--enable-tokenizer=shared --enable-wddx=shared --enable-xml=shared
--enable-xmlreader=shared --enable-xmlwriter=shared --enable-zip=shared
--enable-sigchild --enable-cgi --disable-short-tags


$ make  /dev/null

/home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c: In function
'date_format':
/home/eddi/opt/src/php5.3-200908132230/ext/date/php_date.c:1058:
warning: incompatible implicit declaration of built-in function 'llabs'
/home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c: In function
'_php_stream_cast':
/home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:222:
warning: cast to pointer from integer of different size
/home/eddi/opt/src/php5.3-200908132230/main/streams/cast.c:225:
warning: cast to pointer from integer of different size
/home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c: In function
'zend_objects_destroy_object':
/home/eddi/opt/src/php5.3-200908132230/Zend/zend_objects.c:95: warning:
assignment discards qualifiers from pointer target type
main/.libs/SAPI.o: In function `sapi_send_headers':
SAPI.c:(.text+0x1fca): undefined reference to `zlib_globals'
collect2: ld returned 1 exit status
make: *** [sapi/cgi/php-cgi] Error 1



Reproduce code:
---
$ gcc -v

Using built-in specs.
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.3.2-r3/work/gcc-4.3.2/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.2
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.2/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --enable-nls --without-included-gettext
--with-system-zlib --disable-checking --disable-werror
--enable-secureplt --disable-multilib --enable-libmudflap
--disable-libssp --enable-libgomp --disable-libgcj
--enable-languages=c,c++,treelang,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.3.2-r3
p1.6, pie-10.1.5'
Thread model: posix
gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5)


$ ld -v

GNU ld (GNU Binutils) 2.18








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

#41888 [Opn-Csd]: Segfault when attempting to update PDO LOB column in a stream wrapper

 ID:   41888
 Updated by:   j...@php.net
 Reported By:  hans at velum dot net
-Status:   Open
+Status:   Closed
 Bug Type: PDO related
 Operating System: Gentoo Linux
 PHP Version:  5.2.4
 Assigned To:  iliaa


Previous Comments:


[2009-06-16 20:09:34] paj...@php.net

 closed



[2009-06-16 20:06:21] hans at velum dot net

Indeed - this appears to be fixed in latest PHP 5.2.x release.  Thanks!



[2008-01-14 20:53:04] hans at velum dot net

Any idea when this issue might get fixed?  This is a big deal to us,
since this bug prevents us from swapping out filesystem-based storage
with a db-storage engine.



[2007-10-01 20:04:40] hans at velum dot net

Updating version to reflect that problem is still present in 5.2.4



[2007-09-06 13:40:07] hans at velum dot net

Note, here is some revised reproduce code (there was a bug in the
original code such that it was creating two DB connections):
http://pastebin.com/f40fa427d

Thanks!



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

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

#44639 [Opn]: PDO quotes integers in prepared statement

 ID:   44639
 Updated by:   j...@php.net
 Reported By:  jgauld at blueyonder dot co dot uk
 Status:   Open
 Bug Type: PDO related
 Operating System: WinXP
-PHP Version:  5.2.5
+PHP Version:  5.2.10
 New Comment:

But you didn't bother updating the version field. Done now..


Previous Comments:


[2009-07-21 00:30:49] whistl0r+php at googlemail dot com

Hi,

this bug is still present in the current PHP version.
Tested with PHP 5.2.10 stable and snapshot on Windows.

MySQL client api: 5.1.35



[2008-10-21 11:59:03] jgauld at blueyonder dot co dot uk

Tried windows snapshot as suggested (5.2.7RC2-dev), but no joy. Result
is same, ie:

select * from my_table where id'13'

If it helps, phpinfo() reports:

PDO Driver for MySQL, client library version5.0.51a



[2008-10-21 11:27:05] j...@php.net

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/





[2008-07-03 15:17:35] u...@php.net

This is not a driver issue. Its the PDO SQL driver messing up SQL
statements.



[2008-06-12 13:42:35] dobamail at gmail dot com

Hi.
PDO::MySQL
The code:
$stmt   = $db-prepare('
SELECT  id, hu_name, ord
FROMproducts
ORDER BY ord DESC, hu_name
LIMIT   :offset, :limit
');
$stmt-bindValue(':offset', ($offset*$limit));
$stmt-bindValue(':limit',  $limit);
$stmt-execute();
It is work on:
- PHP Version 5.2.0-8+etch11;
- PDO Driver for MySQL, client library version 5.0.32
- MySQL version: 5.0.32-Debian_7etch5-log
Not work on:
- PHP Version 5.2.3-1ubuntu6.3
- PDO Driver for MySQL, client library version 5.0.45
- 5.0.45-Debian_1ubuntu3.3

I hope this help you.
Best regards.



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

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

#48614 [Opn-Asn]: Loading pdo_sqlite.so fails: undefined symbol: sqlite3_libversion

 ID:   48614
 Updated by:   j...@php.net
 Reported By:  kaspernj at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: PDO related
 Operating System: Ubuntu Jaunty
 PHP Version:  5.3.0RC4
-Assigned To:  
+Assigned To:  scottmac


Previous Comments:


[2009-07-09 18:18:07] dkepplinger at gmail dot com

I have the same problem with PHP 5.3 on Debian 5.0.2 when loading the
pdo_sqlite.so extension in the config file.



[2009-06-23 07:18:49] dominics at gmail dot com

I can reproduce this bug (Debian Lenny) with the following minimal
configure line:

./configure --with-zlib --enable-pdo=shared --with-sqlite=shared
--with-pdo-sqlite=shared

For now, not building PDO as shared seems to be a workaround.



[2009-06-20 16:41:46] kaspernj at gmail dot com

sqlite3.so loads fine.

It does not help to load pdo_sqlite.so afterwards though - getting
the exact same error.

Here is what I did:
#!/opt/php53/bin/php
?php
dl(gd.so);
dl(sqlite3.so);
dl(pdo.so);
dl(pdo_sqlite.so);
echo(Hejsa\n);
?



[2009-06-20 16:35:43] scott...@php.net

If you load

sqlite3.so first does it work?



[2009-06-20 13:19:49] kaspernj at gmail dot com

Thank you for responding.

I used the following configure-line:

./configure --with-mysql=shared --with-gd=shared --with-pgsql=shared
--enable-pcntl=shared --with-gettext=shared --with-mysqli=shared
--with-imap=shared --with-mcrypt=shared --with-kerberos --with-imap-ssl
--with-sqlite=shared --enable-sockets=shared --with-pdo-mysql=shared
--with-pdo-sqlite=shared --enable-ftp=shared --enable-pdo=shared
--with-pdo-pgsql=shared --enable-sockets=shared --enable-cli
--disable-cgi --prefix=/opt/php53 --with-ldap=shared --with-pear=shared
--disable-debug --with-bz2=shared --with-iconv=shared
--with-regex=shared --enable-xml=shared --enable-dom=shared
--with-xmlrpc=shared --with-mhash=shared --with-unixODBC=shared,/usr
--enable-mbstring=shared --enable-xmlreader=shared --with-sqlite3=shared



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

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

#49206 [Opn-Asn]: PDO SQLite support for ATTR_FETCH_TABLE_NAMES and getColumnMeta fix

 ID:   49206
 Updated by:   j...@php.net
 Reported By:  patchnow at gmail dot com
-Status:   Open
+Status:   Assigned
 Bug Type: PDO related
 Operating System: Windows
 PHP Version:  5.3.0
 Assigned To:  scottmac


Previous Comments:


[2009-08-10 09:32:33] patchnow at gmail dot com

Description:

Patch for adding ATTR_FETCH_TABLE_NAMES support for PDO SQLite.

http://news.php.net/php.internals/45254

Fixes SQLite Bug 42589 for windows builds too, getColumnMeta didn't
return the table name.






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

#49236 [Opn-Csd]: Missing PHP_SUBST(PDO_MYSQL_SHARED_LIBADD)

 ID:   49236
 Updated by:   j...@php.net
 Reported By:  xueron at xueron dot com
-Status:   Open
+Status:   Closed
 Bug Type: PDO related
 Operating System: CentOS 5.3
 PHP Version:  5.3.0


Previous Comments:


[2009-08-17 17:57:41] s...@php.net

Automatic comment from SVN on behalf of jani
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287424
Log: - Fixed bug #49236 (Missing PHP_SUBST(PDO_MYSQL_SHARED_LIBADD)).



[2009-08-12 13:05:55] xueron at xueron dot com

Description:

[r...@cvs pdo_mysql]# pwd
/home/src/php-5.3.0/ext/pdo_mysql

[r...@cvs pdo_mysql]# ./configure
--with-php-config=/home/amos/bin/php-cconfig --with-pdo-mysql=/home/amos
--with-zlib-dir=/usr 

.

[r...@cvs pdo_mysql]# make
.
/src/php-5.3.0/ext/pdo_mysql/modules  pdo_mysql.lo mysql_driver.lo
mysql_statement.lo 
cc -shared  .libs/pdo_mysql.o .libs/mysql_driver.o
.libs/mysql_statement.o   -Wl,-soname -Wl,pdo_mysql.so -o
.libs/pdo_mysql.so
creating pdo_mysql.la

Here, I found pdo_mysql.so was not linked with libmysqlclient_r.so. So
I checked the Makefile, and compared whit my working version(5.2.10), I
found, PDO_MYSQL_SHARED_LIBADD was missed in the Makefile.

After I add:
PDO_MYSQL_SHARED_LIBADD = -Wl,-rpath,/home/amos/lib/ -L/home/amos/lib/
-Wl,-rpath,/home/amos/lib/mysql -L/home/amos/lib/mysql -lmysqlclient -lz
-lcrypt -lnsl -lm -lssl -lcr
ypto

to Makefile and remake, it works.






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

#49251 [Opn-Ver]: wrong object created

 ID:   49251
 Updated by:   j...@php.net
 Reported By:  ies_clan at hotmail dot com
-Status:   Open
+Status:   Verified
 Bug Type: SimpleXML related
-Operating System: Windows XP SP3
+Operating System: *
-PHP Version:  5.3.0
+PHP Version:  5.*, 6 (2009-08-17)
 New Comment:

Quite weird indeed. And verified in all branches.


Previous Comments:


[2009-08-14 13:49:22] ies_clan at hotmail dot com

Description:

if u try to create a new object from an simple xml-objekt-property you
got an simple xml object :(

Reproduce code:
---
class test {}

$Xml = new
SimpleXMLElement('rootclassnamestdclass/classname/root');
$XmlClass = new $Xml-classname('root /');
print_r($XmlClass);

$MyClass = new stdclass();
$MyClass-classname = 'test';
$stdclass = new $MyClass-classname();
print_r($stdclass);


Expected result:

stdclass Object
(
)
test Object
(
)


Actual result:
--
SimpleXMLElement Object
(
)
test Object
(
)






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

#49251 [Ver]: wrong object created

 ID:   49251
 Updated by:   j...@php.net
 Reported By:  ies_clan at hotmail dot com
 Status:   Verified
 Bug Type: SimpleXML related
 Operating System: *
 PHP Version:  5.*, 6 (2009-08-17)
 New Comment:

And it only happens with 'new'.


Previous Comments:


[2009-08-17 18:19:09] j...@php.net

Quite weird indeed. And verified in all branches.



[2009-08-14 13:49:22] ies_clan at hotmail dot com

Description:

if u try to create a new object from an simple xml-objekt-property you
got an simple xml object :(

Reproduce code:
---
class test {}

$Xml = new
SimpleXMLElement('rootclassnamestdclass/classname/root');
$XmlClass = new $Xml-classname('root /');
print_r($XmlClass);

$MyClass = new stdclass();
$MyClass-classname = 'test';
$stdclass = new $MyClass-classname();
print_r($stdclass);


Expected result:

stdclass Object
(
)
test Object
(
)


Actual result:
--
SimpleXMLElement Object
(
)
test Object
(
)






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

#49252 [Opn-Fbk]: ext/ldap/config.m4 sasl2 checks wrong

 ID:   49252
 Updated by:   j...@php.net
 Reported By:  crrodriguez at opensuse dot org
-Status:   Open
+Status:   Feedback
 Bug Type: LDAP related
 Operating System: Linux
 PHP Version:  5.3SVN-2009-08-14 (SVN)
 New Comment:

It's actually intentional. What configure line did you use when it
fails..? The library is passed to the test via the 3rd parameter to
PHP_CHECK_LIBRARY() macro and if the ldap library is linked with it,
then the test will pass, otherwise it fails. :)


Previous Comments:


[2009-08-14 14:43:16] crrodriguez at opensuse dot org

Description:

in ext/ldap/config.m4 there is the following check

  PHP_CHECK_LIBRARY(ldap, sasl_version,

sasl_version symbol is not really found in ldap library but in sasl2,
that is correctly added soon after with

PHP_ADD_LIBRARY_WITH_PATH(sasl2, $LDAP_SASL_LIBDIR,
LDAP_SHARED_LIBADD)



I think you mean 

PHP_CHECK_LIBRARY(sasl2, sasl_version

Reproduce code:
---
...

Expected result:

extension build correctly

Actual result:
--
failure to build





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

#49265 [Opn-Bgs]: external program execution hangs, process sometimes never exits

 ID:   49265
 Updated by:   j...@php.net
 Reported By:  stefan dot launicke at gate8 dot de
-Status:   Open
+Status:   Bogus
 Bug Type: Program Execution
 Operating System: Linux 2.6.19
 PHP Version:  5.2.10
 New Comment:

We can only delete the comments. Can't edit initial entry in this
version of the bug tracker. Please repost this bug.


Previous Comments:


[2009-08-15 10:32:36] stefan dot launicke at gate8 dot de

I appologize for the double post. For some reason, I cannot edit my 
submission. Can some admin please delete the first entry? Thank you.



[2009-08-15 10:17:26] stefan dot launicke at gate8 dot de

Description:

When doing a external function call using either passthru(), 
proc_open() or system(), the external process hangs most of the time. 
Sometimes it works. Only appears when run through mod_php / apache2. 
Calling the script in the shell with CLI always works. 

ps shows:
11606 ?Sl 0:00 /usr/bin/pdftk 

No errors in any logs, no segfaults. top

Please Note:
- doing the exact same call in a Perl script running in Apache always 
works.
- calling the perl script which does the funtion call from within php 
will crash again with ps (passthru example):

11674 ?S  0:00 sh -c cd '/data/usr/inauris.com/tmp' ; 
/data/usr/inauris.com/tmp/test3.pl
11675 ?S  0:00 /usr/bin/perl -w 
/data/usr/inauris.com/tmp/test3.pl
11676 ?Sl 0:00 /usr/bin/pdftk 
/data/usr/inauris.com/management/home/app/pdf...

Apache Version: 2.2.11, Worker MPM

Reproduce code:
---
passthru (/usr/bin/pdftk /data/testin.pdf fill_form /data/workdata
output /data/testout.pdf flatten);

Expected result:

exec  return

Actual result:
--
hang





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

#49265 [Bgs]: external program execution hangs, process sometimes never exits

 ID:   49265
 Updated by:   j...@php.net
 Reported By:  stefan dot launicke at gate8 dot de
 Status:   Bogus
 Bug Type: Program Execution
 Operating System: Linux 2.6.19
 PHP Version:  5.2.10
 New Comment:

And please don't post the bug if you can't reproduce it using the
preform MPM. Threaded mpms are not supported.


Previous Comments:


[2009-08-17 18:49:00] j...@php.net

We can only delete the comments. Can't edit initial entry in this
version of the bug tracker. Please repost this bug.



[2009-08-15 10:32:36] stefan dot launicke at gate8 dot de

I appologize for the double post. For some reason, I cannot edit my 
submission. Can some admin please delete the first entry? Thank you.



[2009-08-15 10:17:26] stefan dot launicke at gate8 dot de

Description:

When doing a external function call using either passthru(), 
proc_open() or system(), the external process hangs most of the time. 
Sometimes it works. Only appears when run through mod_php / apache2. 
Calling the script in the shell with CLI always works. 

ps shows:
11606 ?Sl 0:00 /usr/bin/pdftk 

No errors in any logs, no segfaults. top

Please Note:
- doing the exact same call in a Perl script running in Apache always 
works.
- calling the perl script which does the funtion call from within php 
will crash again with ps (passthru example):

11674 ?S  0:00 sh -c cd '/data/usr/inauris.com/tmp' ; 
/data/usr/inauris.com/tmp/test3.pl
11675 ?S  0:00 /usr/bin/perl -w 
/data/usr/inauris.com/tmp/test3.pl
11676 ?Sl 0:00 /usr/bin/pdftk 
/data/usr/inauris.com/management/home/app/pdf...

Apache Version: 2.2.11, Worker MPM

Reproduce code:
---
passthru (/usr/bin/pdftk /data/testin.pdf fill_form /data/workdata
output /data/testout.pdf flatten);

Expected result:

exec  return

Actual result:
--
hang





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

#47118 [Asn-Csd]: Segmentation fault on ociexecute

2009-08-17 Thread sixd

ID: 47118
Updated by: s...@php.net
Reported By: holger at noefer dot org
-Status: Assigned
+Status: Closed
Bug Type: OCI8 related
Operating System: Solaris 8
PHP Version: 5.2.8
Assigned To: sixd
New Comment:

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

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

---

Duplicate of http://bugs.php.net/bug.php?id=41069

Previous Comments:

[2009-06-18 21:13:48] holger at noefer dot org

Hi,

sorry for my very late response.
The workaround to increase oci8.default_prefetch worked for me,
sometimes I got an segmenation fault.

After that I applied the patch and removed the increased
oci8.default_prefetch value from php.ini.
The patch works fine and resolved my problem, no segmentation
faults seen any more.

Thanks for helping with the bug.

Best regards,
Holger

[2009-02-10 19:41:36] s...@php.net

If you think it is #41069, you can examine use of Oracle dblinks in
your application.

The changes in php_oci_statement_set_prefetch() in
http://cvs.php.net/viewvc.cgi/pecl/oci8/oci8_statement.c?r1=1.7.2.14.2.28.2.4r2=1.7.2.14.2.28.2.5
are the patch, if you want to test a code fix.

If this doesn't help, I'd recommend upgrading OCI8 to 1.3.4 from PECL
before we continue investigation.

[2009-01-30 18:52:18] holger at noefer dot org

Hello,

I changed oci8.default_prefetch from 10 to 100.
The segmentation faults seems to be fewer than before.

Perhaps it is related to this bug?
http://bugs.php.net/bug.php?id=41069

Best regards,
Holger

[2009-01-30 15:04:24] holger at noefer dot org

Hello,

sorry for the long time I did not respond to the bug but it
is hard to aim the bug.

The bug seems to appear when I use persistent connections.

Here are the default settings in php.ini
oci8.default_prefetch = 10 = 10
oci8.max_persistent = -1 = -1
oci8.old_oci_close_semantics = 0 = 0
oci8.persistent_timeout = -1 = -1
oci8.ping_interval = 60 = 60
oci8.privileged_connect = Off = Off
oci8.statement_cache_size = 20 = 20

Should the oci8.persistent_timeout be changed?

I will try to post some code next week.

Best regards,
Holger

[2009-01-15 21:46:24] s...@php.net

Please help narrow down the problem with the aim of supplying a
reproducable testcase. Look at patterns in the frequency of crash, the
statement(s) that crash, and the environment (machine, environment
variables, build options, connection etc) that causes the crash.

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

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

#49223 [Opn-Csd]: Inconsistency using get_defined_constants(true)

2009-08-17 Thread garretts

 ID:   49223
 Updated by:   garre...@php.net
 Reported By:  carlos dot ballesteros at softonic dot com
-Status:   Open
+Status:   Closed
 Bug Type: Scripting Engine problem
 Operating System: win32 only
 PHP Version:  5.3.1-dev
 New Comment:

This bug has been fixed in SVN.

The internal module mhash was improperly registered


Previous Comments:


[2009-08-17 21:28:23] s...@php.net

Automatic comment from SVN on behalf of garretts
Revision: http://svn.php.net/viewvc/?view=revisionrevision=287429
Log: - Fix for bug #49223 Inconsistency using
get_defined_constants(true)



[2009-08-11 19:00:43] j...@php.net

Seems to be windows only issue.



[2009-08-11 12:59:00] carlos dot ballesteros at softonic dot com

It's not working even in the lastest snapshot.

C:\dev\php53php -v
PHP 5.3.1-dev (cli) (built: Aug 11 2009 10:52:16)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

C:\dev\php53php -rprint_r(get_defined_constants(true)); | more
Array
(
[mhash] = Array
(
[E_ERROR] = 1
...



[2009-08-11 11:29:29] j...@php.net

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

'Core' is correct. Dunno about windows, might be fixed now. Try the
snapshot.



[2009-08-11 10:43:48] carlos dot ballesteros at softonic dot com

Description:

Before PHP 5.3, get_defined_constants with a parameter returned the
core constants in a key called internal. In PHP5.3 in linux it's
returning them as Core key. But in windows it's returned as key
mhash. It's pretty weird.
It's similar to this bug: http://bugs.php.net/bug.php?id=47549
But at least in windows mhash key is wrong. And about linux, if the
key changed from 'internal' to 'Core', I think it should, at least, be
specified in the documentation.

http://es2.php.net/get_defined_constants

Reproduce code:
---
print_r(get_defined_constants(true));

Expected result:

Array
(
[internal] = Array
(
[E_ERROR] = 1
[E_RECOVERABLE_ERROR] = 4096
...

Actual result:
--
Linux:
-bash-3.2# php -rprint_r(get_defined_constants(true)); | more
Array
(
[Core] = Array
(
[E_ERROR] = 1
[E_RECOVERABLE_ERROR] = 4096
...
-bash-3.2# php -v
PHP 5.3.0 (cli) (built: Jun 30 2009 21:37:54)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies

Windows:
C:\php -rprint_r(get_defined_constants(true)); | more
Array
(
[mhash] = Array
(
[E_ERROR] = 1
[E_RECOVERABLE_ERROR] = 4096
...
C:\php -v
PHP 5.3.0 (cli) (built: Jun 29 2009 21:55:01)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2009 Zend Technologies






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

#49265 [Bgs]: external program execution hangs, process sometimes never exits

2009-08-17 Thread stefan dot launicke at gate8 dot de

 ID:   49265
 User updated by:  stefan dot launicke at gate8 dot de
 Reported By:  stefan dot launicke at gate8 dot de
 Status:   Bogus
 Bug Type: Program Execution
 Operating System: Linux 2.6.19
 PHP Version:  5.2.10
 New Comment:

reproduced with Apache Prefork model. Same behaviour,


Previous Comments:


[2009-08-17 18:49:51] j...@php.net

And please don't post the bug if you can't reproduce it using the
preform MPM. Threaded mpms are not supported.



[2009-08-17 18:49:00] j...@php.net

We can only delete the comments. Can't edit initial entry in this
version of the bug tracker. Please repost this bug.



[2009-08-15 10:32:36] stefan dot launicke at gate8 dot de

I appologize for the double post. For some reason, I cannot edit my 
submission. Can some admin please delete the first entry? Thank you.



[2009-08-15 10:17:26] stefan dot launicke at gate8 dot de

Description:

When doing a external function call using either passthru(), 
proc_open() or system(), the external process hangs most of the time. 
Sometimes it works. Only appears when run through mod_php / apache2. 
Calling the script in the shell with CLI always works. 

ps shows:
11606 ?Sl 0:00 /usr/bin/pdftk 

No errors in any logs, no segfaults. top

Please Note:
- doing the exact same call in a Perl script running in Apache always 
works.
- calling the perl script which does the funtion call from within php 
will crash again with ps (passthru example):

11674 ?S  0:00 sh -c cd '/data/usr/inauris.com/tmp' ; 
/data/usr/inauris.com/tmp/test3.pl
11675 ?S  0:00 /usr/bin/perl -w 
/data/usr/inauris.com/tmp/test3.pl
11676 ?Sl 0:00 /usr/bin/pdftk 
/data/usr/inauris.com/management/home/app/pdf...

Apache Version: 2.2.11, Worker MPM

Reproduce code:
---
passthru (/usr/bin/pdftk /data/testin.pdf fill_form /data/workdata
output /data/testout.pdf flatten);

Expected result:

exec  return

Actual result:
--
hang





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

#49274 [Ana]: filter_var() should accept objects without fatal error

 ID:   49274
 Updated by:   paj...@php.net
 Reported By:  cel...@php.net
 Status:   Analyzed
 Bug Type: Feature/Change Request
 Operating System: *
 PHP Version:  5.3SVN-2009-08-16 (SVN)
 New Comment:

http://pastie.org/586442 should do it. I did not not test more than the
test case here.


Previous Comments:


[2009-08-17 13:55:58] paj...@php.net

it is indeed valid for all objects but it is still an edge case.

A check for IS_OBJECT + tostring() existence could be easy enough and
with almost no impact(perf impact is null on the existing application).
If you have some time to write one, go ahead.



[2009-08-17 13:52:56] cel...@php.net

the stdClass was just to illustrate the point, this happens with any
object that doesn't have a __toString().  I would imagine it would be
easier to check for IS_OBJECT and then see if it implements __toString
than to do a custom error handler.  The performance should be about the
same (dismal).



[2009-08-17 13:48:45] paj...@php.net

As StdClass has no __toString implementation (obviously), it can't be
converted to string.

I tend to agree that it should not raise a fatal (recovable error) here
as it defeats the main purpose of this API.

I'm however not sure it is worth the effort to add custom error handler
for this edge case. Patch welcome, it could help to get this edge case
solved (I can't work on this exact issue any time soon).



[2009-08-17 13:27:50] cel...@php.net

?php
var_dump(filter_var(null, FILTER_VALIDATE_INT));
var_dump(filter_var(array(), FILTER_VALIDATE_INT));
var_dump(filter_var('hi', FILTER_VALIDATE_INT));
var_dump(filter_var(1.1, FILTER_VALIDATE_INT));
var_dump(filter_var(fopen('somefile', 'r'), FILTER_VALIDATE_INT));
var_dump(filter_var(1, FILTER_VALIDATE_INT));
var_dump(filter_var('1.0', FILTER_VALIDATE_INT));
?

all work without error.

?php
class blah {function __toString(){return '1';}}
var_dump(filter_var(new blah, FILTER_VALIDATE_INT));
?

works without error.

Only filter_var with an object that doesn't implement __toString fails
with an error.  Either filter is incorrectly returning false with no
error on all of those other random types, or you're wrong, Jani.



[2009-08-17 13:13:43] j...@php.net

This is not a bug. It's exactly what's supposed to happen. When you
pass crap in you get crap out. The language isn't supposed to hold your
hand in every corner.



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

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

#49039 [Fbk]: Can't pass file name with subfolder name 3 characters or less