#26730 [NEW]: [chm] bug on function.explode.html
From: tomas dot matousek at matfyz dot cz
Operating system: windows
PHP version: 5.0.0b2 (beta2)
PHP Bug Type: Scripting Engine problem
Bug description: [chm] bug on function.explode.html
Description:
The explode() function misbehaves if the limit parameter has invalid
value.
Reproduce code:
---
explode(",","a,b,c,d,e,f",-8);
explode(",","a,b,c,d,e,f",0);
Expected result:
Warning + returning FALSE
Actual result:
--
invalid value is treated as if it was 2 and 1 respectively
--
Edit bug report at http://bugs.php.net/?id=26730&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26730&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26730&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26730&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26730&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26730&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26730&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26730&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26730&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26730&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26730&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26730&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26730&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26730&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26730&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26730&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26730&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26730&r=float
#26618 [Opn]: include_once() sometimes works, sometimes doesn't with each page refresh
ID: 26618 User updated by: t dot steve at ariadne-quatra dot com Reported By: t dot steve at ariadne-quatra dot com Status: Open Bug Type: IIS related Operating System: Windows 2000 server SP4 PHP Version: 5CVS-2003-12-14 New Comment: IIS related bug? But all previous versions of PHP worked fine even with the "ugly" ASP delimiters (<% %>) which I have top use. :( The problem arose only as of version 5.x ! Previous Comments: [2003-12-16 03:09:58] [EMAIL PROTECTED] Don't bother with new reports. I don't really think this is any PHP bug either, but I'll leave this open for now. (It's some IIS bug, iirc, use Apache which works) [2003-12-16 03:04:33] t dot steve at ariadne-quatra dot com YES, with conventional tags the includes work perfectly and consistently! :) However, this IS still a problem - I need to use the <% %> because of the editor I must use (FP...)! ASP-style tags ARE - in theory - supported, aren't they? (They are enabled in the INI file, and I have been using them in all our sites for ages without any problems!) So then the problem changes to ASP-style <% %> tags versus regular tags... Do I have to open a new bug report, or just leave this one open? Thanks! [2003-12-16 02:48:32] [EMAIL PROTECTED] Try using the PHP tags, not those ugly ASP tags. (<% %> -> ) [2003-12-15 22:04:48] t dot steve at ariadne-quatra dot com - No, I get no errors even after adding 'error_reporting(E_ALL);'. - Yes, the same behaviour even if I use include() instead of include_once(). [2003-12-15 09:25:33] [EMAIL PROTECTED] Do you get any errors if you put 'error_reporting(E_ALL);' before the include_once() line? Does this happen if you use include() ? 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/26618 -- Edit this bug report at http://bugs.php.net/?id=26618&edit=1
#26731 [NEW]: i am unable to excute the php code
From: chennamaneni_sheela at yahoo dot com Operating system: windows 98 PHP version: Irrelevant PHP Bug Type: Output Control Bug description: i am unable to excute the php code Description: i wrote hello and saved it as first.php and excuted in intenet explorer but it is not excuting,WHY? Expected result: Hello world Actual result: -- its source code from notepad is coming. nothing is excuting but file is being saved as first.php.txt -- Edit bug report at http://bugs.php.net/?id=26731&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26731&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26731&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26731&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26731&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26731&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26731&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26731&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26731&r=support Expected behavior: http://bugs.php.net/fix.php?id=26731&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26731&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26731&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26731&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26731&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26731&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26731&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26731&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26731&r=float
#26731 [Opn]: i am unable to excute the php code
ID: 26731 User updated by: chennamaneni_sheela at yahoo dot com Reported By: chennamaneni_sheela at yahoo dot com Status: Open Bug Type: Output Control Operating System: windows 98 PHP Version: Irrelevant New Comment: please send reply as early as posiible Previous Comments: [2003-12-28 08:25:43] chennamaneni_sheela at yahoo dot com Description: i wrote hello and saved it as first.php and excuted in intenet explorer but it is not excuting,WHY? Expected result: Hello world Actual result: -- its source code from notepad is coming. nothing is excuting but file is being saved as first.php.txt -- Edit this bug report at http://bugs.php.net/?id=26731&edit=1
#26731 [Opn->Bgs]: i am unable to excute the php code
ID: 26731 Updated by: [EMAIL PROTECTED] Reported By: chennamaneni_sheela at yahoo dot com -Status: Open +Status: Bogus Bug Type: Output Control Operating System: windows 98 PHP Version: Irrelevant New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. You need to save it as .php and .php.txt. Read the docs of your system/editor. Previous Comments: [2003-12-28 08:28:20] chennamaneni_sheela at yahoo dot com please send reply as early as posiible [2003-12-28 08:25:43] chennamaneni_sheela at yahoo dot com Description: i wrote hello and saved it as first.php and excuted in intenet explorer but it is not excuting,WHY? Expected result: Hello world Actual result: -- its source code from notepad is coming. nothing is excuting but file is being saved as first.php.txt -- Edit this bug report at http://bugs.php.net/?id=26731&edit=1
#4312 [Com]: -2147467259 (0x80004005)
ID: 4312 Comment by: pons18 at yahoo dot com Reported By: deegee at harco dot co dot id Status: Closed Bug Type: Scripting Engine problem Operating System: Windows 2000 Advanced Server PHP Version: 4.0 Release Candidate 1 New Comment: make sure to give read and execution access to the file involved in the sapi process. i.e. php.exe php4isapi.dll and php4ts.dll. hth Previous Comments: [2003-01-24 16:07:10] gugelhupf78 at lycos dot de I had the same problem. Every PHP-srcipt just gave me that -2147467259 (0x80004005) output and the IIS-service crashed. I changed the IIS access-mode from 'anonymous access' to 'integrated athentification' and voila, everything worked fine... After a while now the anonyouse modus works, too - BUT I DON'T KNOW WHY? IIS5, Win2K Advanced Server PHP 4.3.0 ISAPI [2000-07-24 17:29:18] [EMAIL PROTECTED] No feedback. Please reopen this bug and give further details if you still have trouble after upgrading to PHP 4.0.1pl2. [2000-05-22 05:28:38] joey at cvs dot php dot net So you are saying the script: prints -2147467259 (0x80004005) in your browser? Or it causes a crash? Can you try a more recent version? [2000-05-22 05:09:46] deegee at harco dot co dot id the error is in the subject, when run the php code the page that generated is only : -2147467259 (0x80004005) [2000-05-21 17:25:57] jimw at cvs dot php dot net and the bug is? 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/4312 -- Edit this bug report at http://bugs.php.net/?id=4312&edit=1
#26732 [NEW]: php_{flag,value,...} in .htaccess are ignored
From: dingoth at hotmail dot com
Operating system: windows 2000
PHP version: 4.3.4
PHP Bug Type: Apache2 related
Bug description: php_{flag,value,...} in .htaccess are ignored
Description:
I have Apache 2.0.47, PHP 4.3.4, with virtual hosts under windows 2000.
In every host, a .htaccess file is used to define its own include_path,
prepend_file, append_file.
The structure of my directory is like this one : (arena is a virtual
host)
H:\www\arena\htdocs<< website
H:\www\arena\includes << files to be included
So, here is a common .htaccess source :
php_value include_path".;H:\www\arena\includes"
php_value auto_prepend_file "prepend.php"
php_value auto_append_file"append.php"
So, when I call the following script within a page under my htdocs
directory :
The webpage shows exactly .;D:\dev\php\includes . That line is the default
include_path I use in my php.ini ! It would write .;H:\www\arena\includes
because I asked it in the .htaccess file !
Reproduce code:
---
Expected result:
.;H:\www\arena\includes
Actual result:
--
.;D:\dev\php\includes
--
Edit bug report at http://bugs.php.net/?id=26732&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26732&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26732&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26732&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26732&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26732&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26732&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26732&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26732&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26732&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26732&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26732&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26732&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26732&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26732&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26732&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26732&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26732&r=float
#26733 [NEW]: End of an array created by explode corrupted
From: n0spam_socrate_omega at hotmail dot com
Operating system: Windows XP Home/Pro
PHP version: 4.3.4
PHP Bug Type: Arrays related
Bug description: End of an array created by explode corrupted
Description:
I have a string encrypted with mcrypt and encoded in base64. I unbase64
this string and I decrypt it using mcrypt. I got the exact same string but
when I try to explode it into an array with the explode() function, I
cannot make comparison == with the last element of the newly created
array.
Reproduce code:
---
$key = "validkey";
$input = base64_decode($txtEncrypted);
$decrypted = mcrypt_ecb(MCRYPT_RIJNDAEL_128, $key, $input,
MCRYPT_DECRYPT);
echo $decrypted."";
$array_data = explode('||', $decrypted);
echo "|".$array_data."|";
if ($array_data[8] == 'end') {
echo "it works!";
}
Expected result:
data||ddata||daata||dadta||dasta||datad||daata||datsa||end
|end|
it works!
Actual result:
--
data||ddata||daata||dadta||dasta||datad||daata||datsa||end
|end|
--
Edit bug report at http://bugs.php.net/?id=26733&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26733&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26733&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26733&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26733&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26733&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26733&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26733&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26733&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26733&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26733&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26733&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26733&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26733&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26733&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26733&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26733&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26733&r=float
#26733 [Opn->Bgs]: End of an array created by explode corrupted
ID: 26733
Updated by: [EMAIL PROTECTED]
Reported By: n0spam_socrate_omega at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Windows XP Home/Pro
PHP Version: 4.3.4
New Comment:
This is not a bug. If you use a block cipher like Rijndael then mcrypt
needs to pad your data with zeroes to fill up the whole block to
encrypt. If you are decrypting the encrypted string those trailing
zeroes are still there, and thus the comparison of the last element
fails.
Before you start asking if we can't trim the string while decrypting;
no this is not possible because we don't know if you are encrypting
binary data (which might end in a zero) or not. You'll have to take
care of this yourself then by using rtrim during comparison.
Previous Comments:
[2003-12-28 14:01:56] n0spam_socrate_omega at hotmail dot com
Description:
I have a string encrypted with mcrypt and encoded in base64. I unbase64
this string and I decrypt it using mcrypt. I got the exact same string
but when I try to explode it into an array with the explode() function,
I cannot make comparison == with the last element of the newly created
array.
Reproduce code:
---
$key = "validkey";
$input = base64_decode($txtEncrypted);
$decrypted = mcrypt_ecb(MCRYPT_RIJNDAEL_128, $key, $input,
MCRYPT_DECRYPT);
echo $decrypted."";
$array_data = explode('||', $decrypted);
echo "|".$array_data."|";
if ($array_data[8] == 'end') {
echo "it works!";
}
Expected result:
data||ddata||daata||dadta||dasta||datad||daata||datsa||end
|end|
it works!
Actual result:
--
data||ddata||daata||dadta||dasta||datad||daata||datsa||end
|end|
--
Edit this bug report at http://bugs.php.net/?id=26733&edit=1
#26635 [Opn->Csd]: imagettfbbox() & imagettftext() fontfile does not allow relative path
ID: 26635 Updated by: [EMAIL PROTECTED] Reported By: choinet at rocketmail dot com -Status: Open +Status: Closed Bug Type: GD related Operating System: Windows XP PHP Version: 4CVS-2003-12-24 New Comment: I have tried path with spaces in them on Windows XP and they work properly. Previous Comments: [2003-12-26 01:34:05] choinet at rocketmail dot com When I read the previous response, I was almost completely baffled. I see two confirmations that the bug has been fixed, yet here I am at my computer with clean installs of the various PHP4,PHP4 CVS, PHP5 beta 3, and PHP5 CVS, and still have the problem. I even went to my other computer running Windows XP/Apache2/PHP to verify that I wasn't encountering an isolated problem. Still, I found it quite odd that the bug was fixed by the developers and that the bug was unreplicable. Then I remembered having to place NetPBM binaries in a directory like "c:\netpbm" without any spaces in the pathname in order for a php-powered gallery application to recognize them. I decided to try the same thing with the Apache DocumentRoot directive and set it to the location of a copy of the test script, "C:/htdocs", instead of the usual "C:/Program Files/Apache Group/Apache2/htdocs". After restarting the server, the pathnames worked fine just like Iliaa described. So, I found that the culprit (spaces in the pathname) affected not only the absolute pathnames but the relative ones as well. For the absolute pathnames, if they contain spaces, the same error in opening the font will occur. This can only be remedied by using the MS-DOS 8.3 convention, e.g. "C:/Progra~1/Apache~1/Apache2/htdocs/arial.ttf" as aforementioned. However, there is no such alternative for Linux pathnames with spaces in them. Furthermore, concerning relative pathnames, which much of the responses have been centered around: the fonts work as intended when called as 'arial', 'arial.ttf', and so on only if the directory containing them has no spaces in its pathname. I'm not sure why the naming format of the parent directories affects the relative pathname, but it somehow does. That is why the two gd functions work only when the font file is located in a pathname without spaces (c:\htdocs) and does not for the other (c:\Program Files\Apache Group\Apache2\htdocs). So, I think that the problem of spaces is affecting all of the other remaining issues. I am assuming that the developers reported no problems on the Windows setup because the http document root's or the fontfile's pathname had no spaces. The thing is, the Apache webserver installs by default at "c:\Program Files\Apache Group", so the DocumentRoot will still generate this error. Sorry for making this report seem long and drawn out, but the problem has finally been pinpointed after much obfuscation, and I am wondering if the outstanding issues can be fixed. [2003-12-25 13:56:59] [EMAIL PROTECTED] Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Neither Jani (sniper) nor I could replicate the bug on Win32 or Linux. The font checking code works with full paths, font name (without extension) and font name with extension. [2003-12-24 15:59:49] choinet at rocketmail dot com sniper states that the bug has been fixed and such changes should be reflected within the STABLE CVS in due time. However, there must have been a mistake in the determination of the status. If he/she is referring to the initial fix that has been made by iliaa, I am still reporting problems with that, for I am sure that such changes have been reflected in the latest snapshot, and it has been a little over a week now since word of the fix. This seems to be the case, as there, indeed, has been a change in the CVS to accomodate relative pathnames. However, the fix is still incomplete, as one may not directly list the complete relative pathname of the fontfile, only 'filename' (instead of 'filename.ext'). This is a problem if the filename does not have the extension .pfa, .pfb, or .ttf (which I saw from the source code in gdft.c). In addition, there is no way to open a fontfile named 'arial', for example, if it does not have a file extension. Again, the other three extensions that can be opened must be referred to by the basename without the extension. This problem is reproducible by using imagettftext(font resource, font size, font angle, x-coordinate, y-coordinate, color resource, fontfile, "Hello World"); where the file is named 'arial.ttf' and the argument pathname is 'arial.ttf', or where the file is named 'arial' and the argument pathname is 'arial' as well. I would appreciate it if
#26732 [Opn->Bgs]: php_{flag,value,...} in .htaccess are ignored
ID: 26732 Updated by: [EMAIL PROTECTED] Reported By: dingoth at hotmail dot com -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: windows 2000 PHP Version: 4.3.4 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 You should be using php_admin_flag/value when setting php ini settings inside httpd.conf Previous Comments: [2003-12-28 12:17:45] dingoth at hotmail dot com Description: I have Apache 2.0.47, PHP 4.3.4, with virtual hosts under windows 2000. In every host, a .htaccess file is used to define its own include_path, prepend_file, append_file. The structure of my directory is like this one : (arena is a virtual host) H:\www\arena\htdocs<< website H:\www\arena\includes << files to be included So, here is a common .htaccess source : php_value include_path".;H:\www\arena\includes" php_value auto_prepend_file "prepend.php" php_value auto_append_file"append.php" So, when I call the following script within a page under my htdocs directory : The webpage shows exactly .;D:\dev\php\includes . That line is the default include_path I use in my php.ini ! It would write .;H:\www\arena\includes because I asked it in the .htaccess file ! Reproduce code: --- Expected result: .;H:\www\arena\includes Actual result: -- .;D:\dev\php\includes -- Edit this bug report at http://bugs.php.net/?id=26732&edit=1
#26727 [Opn->Bgs]: signal.h is not detected resulting in compile error in ext/php_mysql.c
ID: 26727 Updated by: [EMAIL PROTECTED] Reported By: jonny at bndlg dot de -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Linux, Debian 3.0 woody PHP Version: 4CVS-2003-12-27 (stable) New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The fact signal.h cannot be used/detected implies a problem with your system's headers. This is not a PHP bug, unless you determine that the problem is due to PHP looking in the wrong places for signal.h Previous Comments: [2003-12-27 11:08:57] jonny at bndlg dot de Description: Configure is not able to detect asm/signal.h any more. This problem started to occur in PHP 4.3.4 with several of my Debian boxes. Compilation failes with the following error: /bin/sh /usr/src/php-4.3.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/mysql/ -I/usr/src/php-4.3.4/ext/mysql/ -DPHP_ATOM_INC -I/usr/src/php-4.3.4/include -I/usr/src/php-4.3.4/main -I/usr/src/php-4.3.4 -I/usr/src/php-4.3.4/Zend -I/usr/include/libxml2 -I/usr/src/FDFToolkitForUNIX/HeadersAndLibraries/headers -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/c-client -I/usr/src/php-4.3.4/ext/mbstring/mbregex -I/usr/src/php-4.3.4/ext/mbstring/libmbfl -I/usr/src/php-4.3.4/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/src/php-4.3.4/TSRM -g -O2 -prefer-pic -c /usr/src/php-4.3.4/ext/mysql/php_mysql.c -o ext/mysql/php_mysql.lo /usr/src/php-4.3.4/ext/mysql/php_mysql.c: In function `_close_mysql_link': /usr/src/php-4.3.4/ext/mysql/php_mysql.c:288: `SIGPIPE' undeclared (first use in this function) /usr/src/php-4.3.4/ext/mysql/php_mysql.c:288: (Each undeclared identifier is reported only once /usr/src/php-4.3.4/ext/mysql/php_mysql.c:288: for each function it appears in.) /usr/src/php-4.3.4/ext/mysql/php_mysql.c:288: `SIG_IGN' undeclared (first use in this function) /usr/src/php-4.3.4/ext/mysql/php_mysql.c:288: warning: assignment makes pointer from integer without a cast /usr/src/php-4.3.4/ext/mysql/php_mysql.c: In function `_close_mysql_plink': /usr/src/php-4.3.4/ext/mysql/php_mysql.c:303: `SIGPIPE' undeclared (first use in this function) /usr/src/php-4.3.4/ext/mysql/php_mysql.c:303: `SIG_IGN' undeclared (first use in this function) /usr/src/php-4.3.4/ext/mysql/php_mysql.c:303: warning: assignment makes pointer from integer without a cast make: *** [ext/mysql/php_mysql.lo] Error 1 Reproduce code: --- My configure call: './configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs' '--with-regex=php' '--with-config-file-path=/etc/php4/apache' '--disable-rpath' '--disable-debug' '--enable-memory-limit' '--with-layout=GNU' '--enable-calendar' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db2' '--with-iconv' '--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext' '--enable-mbstring' '--with-pcre-regex' '--enable-shmop' '--enable-sockets' '--enable-wddx' '--disable-xml' '--with-expat-dir=/usr' '--enable-yp' '--with-zlib' '--without-pgsql' '--with-openssl=/usr' '--disable-static' '--with-dom=/usr' '--with-zlib-dir=/usr' '--with-gd' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-imap=/usr' '--with-mhash=/usr' '--with-mm' '--with-mysql=/usr' '--with-recode=/usr' '--with-ttf=/usr' '--with-t1lib=/usr' --with-pdflib --with-fdftk=../FDFToolkitForUNIX --with-xpm-dir=/usr --with-curl Actual result: -- configure outputs "signal.h not detected" and in main/php_config.h the line #define HAVE_SIGNAL_H is commented out. -- Edit this bug report at http://bugs.php.net/?id=26727&edit=1
#26727 [Bgs]: signal.h is not detected resulting in compile error in ext/php_mysql.c
ID: 26727 User updated by: jonny at bndlg dot de Reported By: jonny at bndlg dot de Status: Bogus Bug Type: Compile Failure Operating System: Linux, Debian 3.0 woody PHP Version: 4CVS-2003-12-27 (stable) New Comment: I agree with that, but all previous versions of PHP compile without any problems on the same machines with the same packets, so I suspected it was a problem in PHP, because from 4.3.4 onwoards it was not able to detect my signal.h any more. Previous Comments: [2003-12-28 14:27:02] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. The fact signal.h cannot be used/detected implies a problem with your system's headers. This is not a PHP bug, unless you determine that the problem is due to PHP looking in the wrong places for signal.h [2003-12-27 11:08:57] jonny at bndlg dot de Description: Configure is not able to detect asm/signal.h any more. This problem started to occur in PHP 4.3.4 with several of my Debian boxes. Compilation failes with the following error: /bin/sh /usr/src/php-4.3.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/mysql/ -I/usr/src/php-4.3.4/ext/mysql/ -DPHP_ATOM_INC -I/usr/src/php-4.3.4/include -I/usr/src/php-4.3.4/main -I/usr/src/php-4.3.4 -I/usr/src/php-4.3.4/Zend -I/usr/include/libxml2 -I/usr/src/FDFToolkitForUNIX/HeadersAndLibraries/headers -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/include/c-client -I/usr/src/php-4.3.4/ext/mbstring/mbregex -I/usr/src/php-4.3.4/ext/mbstring/libmbfl -I/usr/src/php-4.3.4/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/usr/src/php-4.3.4/TSRM -g -O2 -prefer-pic -c /usr/src/php-4.3.4/ext/mysql/php_mysql.c -o ext/mysql/php_mysql.lo /usr/src/php-4.3.4/ext/mysql/php_mysql.c: In function `_close_mysql_link': /usr/src/php-4.3.4/ext/mysql/php_mysql.c:288: `SIGPIPE' undeclared (first use in this function) /usr/src/php-4.3.4/ext/mysql/php_mysql.c:288: (Each undeclared identifier is reported only once /usr/src/php-4.3.4/ext/mysql/php_mysql.c:288: for each function it appears in.) /usr/src/php-4.3.4/ext/mysql/php_mysql.c:288: `SIG_IGN' undeclared (first use in this function) /usr/src/php-4.3.4/ext/mysql/php_mysql.c:288: warning: assignment makes pointer from integer without a cast /usr/src/php-4.3.4/ext/mysql/php_mysql.c: In function `_close_mysql_plink': /usr/src/php-4.3.4/ext/mysql/php_mysql.c:303: `SIGPIPE' undeclared (first use in this function) /usr/src/php-4.3.4/ext/mysql/php_mysql.c:303: `SIG_IGN' undeclared (first use in this function) /usr/src/php-4.3.4/ext/mysql/php_mysql.c:303: warning: assignment makes pointer from integer without a cast make: *** [ext/mysql/php_mysql.lo] Error 1 Reproduce code: --- My configure call: './configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs' '--with-regex=php' '--with-config-file-path=/etc/php4/apache' '--disable-rpath' '--disable-debug' '--enable-memory-limit' '--with-layout=GNU' '--enable-calendar' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-db2' '--with-iconv' '--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext' '--enable-mbstring' '--with-pcre-regex' '--enable-shmop' '--enable-sockets' '--enable-wddx' '--disable-xml' '--with-expat-dir=/usr' '--enable-yp' '--with-zlib' '--without-pgsql' '--with-openssl=/usr' '--disable-static' '--with-dom=/usr' '--with-zlib-dir=/usr' '--with-gd' '--with-jpeg-dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-imap=/usr' '--with-mhash=/usr' '--with-mm' '--with-mysql=/usr' '--with-recode=/usr' '--with-ttf=/usr' '--with-t1lib=/usr' --with-pdflib --with-fdftk=../FDFToolkitForUNIX --with-xpm-dir=/usr --with-curl Actual result: -- configure outputs "signal.h not detected" and in main/php_config.h the line #define HAVE_SIGNAL_H is commented out. -- Edit this bug report at http://bugs.php.net/?id=26727&edit=1
#26730 [Opn->Bgs]: [chm] bug on function.explode.html
ID: 26730
Updated by: [EMAIL PROTECTED]
Reported By: tomas dot matousek at matfyz dot cz
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: windows
PHP Version: 5.0.0b2 (beta2)
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
When number parts is <0 the value defaults to 1, when it is
0 it simply returns the specified string.
Previous Comments:
[2003-12-28 07:26:01] tomas dot matousek at matfyz dot cz
Description:
The explode() function misbehaves if the limit parameter has invalid
value.
Reproduce code:
---
explode(",","a,b,c,d,e,f",-8);
explode(",","a,b,c,d,e,f",0);
Expected result:
Warning + returning FALSE
Actual result:
--
invalid value is treated as if it was 2 and 1 respectively
--
Edit this bug report at http://bugs.php.net/?id=26730&edit=1
#26491 [Opn]: printing variable values
ID: 26491 Updated by: [EMAIL PROTECTED] Reported By: clyuri at uadec dot mx Status: Open Bug Type: Unknown/Other Function Operating System: Linux x86 PHP Version: Irrelevant New Comment: Would it be possible to provide a reproducing script? Previous Comments: [2003-12-03 15:12:02] clyuri at uadec dot mx no, it doesn't work [2003-12-02 21:35:18] [EMAIL PROTECTED] does this happen if you use: or ? [2003-12-01 13:33:42] clyuri at uadec dot mx Description: I have a problem with maybe the parsing of php script; where it says : print $variable, the browser returns : $variable=its value. the output it's only with IE I'm using php 4.2.2-17 out-of-the-box (preinstalled with RH), RedHat Intel Reproduce code: --- &astu=joo>Enter Expected result: send.php?nick=something&astu=joo Actual result: -- send.php?nick=somethingnimi2=something&astu=joo -- Edit this bug report at http://bugs.php.net/?id=26491&edit=1
#26734 [NEW]: (or) and (||) not the same
From: red at ixney dot net
Operating system: Win XP Pro
PHP version: 4.3.2
PHP Bug Type: MySQL related
Bug description: (or) and (||) not the same
Description:
I always thought '||' and 'or' was the same.
Combined with a mysql_query() however, they are not.
These lines are the same:
mysql_query("$var") or die("help!");
mysql_query("$var") || die("help!");
where $var is a DROP, INSERT or CREATE query, but they are *not* the same
if $var is a SELECT query; the returned value will not be a 'Resource ID'
in the latter line.
Reproduce code:
---
mysql_query("DROP TABLE IF EXISTS foobar") || die('Cannot drop table');
mysql_query("CREATE TABLE IF NOT EXISTS foobar (foo INT NOT NULL
AUTO_INCREMENT, bar TINYINT(1), PRIMARY KEY (foo))") || die('Cannot make
table');
// Let's insert some random stuff
mysql_query("INSERT INTO foobar (bar) VALUES (0)") || die('Cannot add
values 1');
mysql_query("INSERT INTO foobar (bar) VALUES (1)") || die('Cannot add
values 2');
mysql_query("INSERT INTO foobar (bar) VALUES (0)") or die('Cannot add
values 3');
mysql_query("INSERT INTO foobar (bar) VALUES (1)") or die('Cannot add
values 4');
$handle1 = mysql_query("SELECT * FROM foobar WHERE 1") || die('Cannot
select');
$handle2 = mysql_query("SELECT * FROM foobar WHERE 1") or die('Cannot
select');
echo '$handle1 is '.$handle1.'';
echo '$handle2 is '.$handle2.'';
Expected result:
$handle1 is Resource id #2
$handle2 is Resource id #3
Actual result:
--
$handle1 is 1
$handle2 is Resource id #3
--
Edit bug report at http://bugs.php.net/?id=26734&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26734&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26734&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26734&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26734&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26734&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26734&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26734&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26734&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26734&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26734&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26734&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26734&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26734&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26734&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26734&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26734&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26734&r=float
#26691 [Opn]: Incorrect behaviour of PPP using get_class_methods([obj]);
ID: 26691
Updated by: [EMAIL PROTECTED]
Reported By: redeye at erisx dot de
Status: Open
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.0b2 (beta2)
New Comment:
Well, there are more inconsistencies - like print_r() which can dump
values of protected/private values (var_dump() does not do that).
print_r() relies on internals of Zend and this is why it prints the
info about private/protected vars. Back to the current topic, imo it's
not a problem that you can see what's behind since private/protected
methods cannot be called outside of the $this context.
Previous Comments:
[2003-12-22 08:42:38] redeye at erisx dot de
Description:
Calling get_class_methods([obj]); on an object returns next to public
methods it's private and protected methods. I guess those methods
should only be returned when calling get_class_methods($this); within
an object.
Reproduce code:
---
$method_name ) {
echo $n." -> ".$method_name."\n";
}
?>
Expected result:
empty page :-)
Actual result:
--
0 -> pub_function
1 -> priv_function
--
Edit this bug report at http://bugs.php.net/?id=26691&edit=1
#26635 [Csd->Opn]: imagettfbbox() & imagettftext() fontfile does not allow relative path
ID: 26635 User updated by: choinet at rocketmail dot com Reported By: choinet at rocketmail dot com -Status: Closed +Status: Open Bug Type: GD related Operating System: Windows XP -PHP Version: 4CVS-2003-12-24 +PHP Version: 4CVS-2003-12-28 New Comment: What am I doing wrong, then? Here's a screenshot at http://icandy.sourceforge.net/phperror.gif, showing the script and font file in c:\htdocs and c:\htdocs\test directory, respectively, as well as the source code and the instance of the problem. The warning was generated on Windows XP and Apache2 using the latest STABLE CVS (I also checked 4.3.4, latest 5.x CVS, and 5.0.0 beta 3) Previous Comments: [2003-12-28 14:24:51] [EMAIL PROTECTED] I have tried path with spaces in them on Windows XP and they work properly. [2003-12-26 01:34:05] choinet at rocketmail dot com When I read the previous response, I was almost completely baffled. I see two confirmations that the bug has been fixed, yet here I am at my computer with clean installs of the various PHP4,PHP4 CVS, PHP5 beta 3, and PHP5 CVS, and still have the problem. I even went to my other computer running Windows XP/Apache2/PHP to verify that I wasn't encountering an isolated problem. Still, I found it quite odd that the bug was fixed by the developers and that the bug was unreplicable. Then I remembered having to place NetPBM binaries in a directory like "c:\netpbm" without any spaces in the pathname in order for a php-powered gallery application to recognize them. I decided to try the same thing with the Apache DocumentRoot directive and set it to the location of a copy of the test script, "C:/htdocs", instead of the usual "C:/Program Files/Apache Group/Apache2/htdocs". After restarting the server, the pathnames worked fine just like Iliaa described. So, I found that the culprit (spaces in the pathname) affected not only the absolute pathnames but the relative ones as well. For the absolute pathnames, if they contain spaces, the same error in opening the font will occur. This can only be remedied by using the MS-DOS 8.3 convention, e.g. "C:/Progra~1/Apache~1/Apache2/htdocs/arial.ttf" as aforementioned. However, there is no such alternative for Linux pathnames with spaces in them. Furthermore, concerning relative pathnames, which much of the responses have been centered around: the fonts work as intended when called as 'arial', 'arial.ttf', and so on only if the directory containing them has no spaces in its pathname. I'm not sure why the naming format of the parent directories affects the relative pathname, but it somehow does. That is why the two gd functions work only when the font file is located in a pathname without spaces (c:\htdocs) and does not for the other (c:\Program Files\Apache Group\Apache2\htdocs). So, I think that the problem of spaces is affecting all of the other remaining issues. I am assuming that the developers reported no problems on the Windows setup because the http document root's or the fontfile's pathname had no spaces. The thing is, the Apache webserver installs by default at "c:\Program Files\Apache Group", so the DocumentRoot will still generate this error. Sorry for making this report seem long and drawn out, but the problem has finally been pinpointed after much obfuscation, and I am wondering if the outstanding issues can be fixed. [2003-12-25 13:56:59] [EMAIL PROTECTED] Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Neither Jani (sniper) nor I could replicate the bug on Win32 or Linux. The font checking code works with full paths, font name (without extension) and font name with extension. [2003-12-24 15:59:49] choinet at rocketmail dot com sniper states that the bug has been fixed and such changes should be reflected within the STABLE CVS in due time. However, there must have been a mistake in the determination of the status. If he/she is referring to the initial fix that has been made by iliaa, I am still reporting problems with that, for I am sure that such changes have been reflected in the latest snapshot, and it has been a little over a week now since word of the fix. This seems to be the case, as there, indeed, has been a change in the CVS to accomodate relative pathnames. However, the fix is still incomplete, as one may not directly list the complete relative pathname of the fontfile, only 'filename' (instead of 'filename.ext'). This is a problem if the filename does not have the extension .pfa, .pfb, or .ttf (which I saw from the source code in gdft.c). In addition, there is no
#26635 [Opn]: imagettfbbox() & imagettftext() fontfile does not allow relative path
ID: 26635 User updated by: choinet at rocketmail dot com Reported By: choinet at rocketmail dot com Status: Open Bug Type: GD related Operating System: Windows XP PHP Version: 4CVS-2003-12-28 New Comment: eh, that hyperlink should be without the comma Previous Comments: [2003-12-28 18:25:22] choinet at rocketmail dot com What am I doing wrong, then? Here's a screenshot at http://icandy.sourceforge.net/phperror.gif, showing the script and font file in c:\htdocs and c:\htdocs\test directory, respectively, as well as the source code and the instance of the problem. The warning was generated on Windows XP and Apache2 using the latest STABLE CVS (I also checked 4.3.4, latest 5.x CVS, and 5.0.0 beta 3) [2003-12-28 14:24:51] [EMAIL PROTECTED] I have tried path with spaces in them on Windows XP and they work properly. [2003-12-26 01:34:05] choinet at rocketmail dot com When I read the previous response, I was almost completely baffled. I see two confirmations that the bug has been fixed, yet here I am at my computer with clean installs of the various PHP4,PHP4 CVS, PHP5 beta 3, and PHP5 CVS, and still have the problem. I even went to my other computer running Windows XP/Apache2/PHP to verify that I wasn't encountering an isolated problem. Still, I found it quite odd that the bug was fixed by the developers and that the bug was unreplicable. Then I remembered having to place NetPBM binaries in a directory like "c:\netpbm" without any spaces in the pathname in order for a php-powered gallery application to recognize them. I decided to try the same thing with the Apache DocumentRoot directive and set it to the location of a copy of the test script, "C:/htdocs", instead of the usual "C:/Program Files/Apache Group/Apache2/htdocs". After restarting the server, the pathnames worked fine just like Iliaa described. So, I found that the culprit (spaces in the pathname) affected not only the absolute pathnames but the relative ones as well. For the absolute pathnames, if they contain spaces, the same error in opening the font will occur. This can only be remedied by using the MS-DOS 8.3 convention, e.g. "C:/Progra~1/Apache~1/Apache2/htdocs/arial.ttf" as aforementioned. However, there is no such alternative for Linux pathnames with spaces in them. Furthermore, concerning relative pathnames, which much of the responses have been centered around: the fonts work as intended when called as 'arial', 'arial.ttf', and so on only if the directory containing them has no spaces in its pathname. I'm not sure why the naming format of the parent directories affects the relative pathname, but it somehow does. That is why the two gd functions work only when the font file is located in a pathname without spaces (c:\htdocs) and does not for the other (c:\Program Files\Apache Group\Apache2\htdocs). So, I think that the problem of spaces is affecting all of the other remaining issues. I am assuming that the developers reported no problems on the Windows setup because the http document root's or the fontfile's pathname had no spaces. The thing is, the Apache webserver installs by default at "c:\Program Files\Apache Group", so the DocumentRoot will still generate this error. Sorry for making this report seem long and drawn out, but the problem has finally been pinpointed after much obfuscation, and I am wondering if the outstanding issues can be fixed. [2003-12-25 13:56:59] [EMAIL PROTECTED] Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Neither Jani (sniper) nor I could replicate the bug on Win32 or Linux. The font checking code works with full paths, font name (without extension) and font name with extension. [2003-12-24 15:59:49] choinet at rocketmail dot com sniper states that the bug has been fixed and such changes should be reflected within the STABLE CVS in due time. However, there must have been a mistake in the determination of the status. If he/she is referring to the initial fix that has been made by iliaa, I am still reporting problems with that, for I am sure that such changes have been reflected in the latest snapshot, and it has been a little over a week now since word of the fix. This seems to be the case, as there, indeed, has been a change in the CVS to accomodate relative pathnames. However, the fix is still incomplete, as one may not directly list the complete relative pathname of the fontfile, only 'filename' (instead of 'filename.ext'). This is a problem if the filename does
#26735 [NEW]: php.ini not read
From: cmouse at youzen dot projectb2 dot net Operating system: Linux 2.4.23 PHP version: 4.3.4 PHP Bug Type: PHP options/info functions Bug description: php.ini not read Description: php.ini appears not to be read properly by php. I've tried changing values on the file stated by phpinfo() to be the one to read. Unfortunately after restart of apache, no changes reflect. F.ex. I have upload_tmp_dir set to a path, but phpinfo() claims that it's not set. -- Edit bug report at http://bugs.php.net/?id=26735&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26735&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26735&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26735&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26735&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26735&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26735&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26735&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26735&r=support Expected behavior: http://bugs.php.net/fix.php?id=26735&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26735&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26735&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26735&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26735&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26735&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26735&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26735&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26735&r=float
#26735 [Opn]: php.ini not read
ID: 26735 Updated by: [EMAIL PROTECTED] Reported By: cmouse at youzen dot projectb2 dot net Status: Open Bug Type: PHP options/info functions Operating System: Linux 2.4.23 PHP Version: 4.3.4 New Comment: Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). Previous Comments: [2003-12-28 19:06:21] cmouse at youzen dot projectb2 dot net Description: php.ini appears not to be read properly by php. I've tried changing values on the file stated by phpinfo() to be the one to read. Unfortunately after restart of apache, no changes reflect. F.ex. I have upload_tmp_dir set to a path, but phpinfo() claims that it's not set. -- Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#26735 [Opn->Fbk]: php.ini not read
ID: 26735 Updated by: [EMAIL PROTECTED] Reported By: cmouse at youzen dot projectb2 dot net -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Linux 2.4.23 PHP Version: 4.3.4 New Comment: Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). Previous Comments: [2003-12-28 19:07:56] [EMAIL PROTECTED] Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). [2003-12-28 19:06:21] cmouse at youzen dot projectb2 dot net Description: php.ini appears not to be read properly by php. I've tried changing values on the file stated by phpinfo() to be the one to read. Unfortunately after restart of apache, no changes reflect. F.ex. I have upload_tmp_dir set to a path, but phpinfo() claims that it's not set. -- Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#26735 [Fbk->Opn]: php.ini not read
ID: 26735 User updated by: cmouse at youzen dot projectb2 dot net Reported By: cmouse at youzen dot projectb2 dot net -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: Linux 2.4.23 PHP Version: 4.3.4 New Comment: yes, I can confirm it Previous Comments: [2003-12-28 19:08:15] [EMAIL PROTECTED] Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). [2003-12-28 19:07:56] [EMAIL PROTECTED] Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). [2003-12-28 19:06:21] cmouse at youzen dot projectb2 dot net Description: php.ini appears not to be read properly by php. I've tried changing values on the file stated by phpinfo() to be the one to read. Unfortunately after restart of apache, no changes reflect. F.ex. I have upload_tmp_dir set to a path, but phpinfo() claims that it's not set. -- Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#26735 [Opn->Fbk]: php.ini not read
ID: 26735 Updated by: [EMAIL PROTECTED] Reported By: cmouse at youzen dot projectb2 dot net -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Linux 2.4.23 PHP Version: 4.3.4 New Comment: Can you post your phpinfo() and your php.ini? Previous Comments: [2003-12-28 19:10:51] cmouse at youzen dot projectb2 dot net yes, I can confirm it [2003-12-28 19:08:15] [EMAIL PROTECTED] Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). [2003-12-28 19:07:56] [EMAIL PROTECTED] Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). [2003-12-28 19:06:21] cmouse at youzen dot projectb2 dot net Description: php.ini appears not to be read properly by php. I've tried changing values on the file stated by phpinfo() to be the one to read. Unfortunately after restart of apache, no changes reflect. F.ex. I have upload_tmp_dir set to a path, but phpinfo() claims that it's not set. -- Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#26735 [Fbk->Opn]: php.ini not read
ID: 26735 User updated by: cmouse at youzen dot projectb2 dot net Reported By: cmouse at youzen dot projectb2 dot net -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: Linux 2.4.23 PHP Version: 4.3.4 New Comment: I'll paste the thing I'm trying to modify: ### php.ini ### ; Temporary directory for HTTP uploaded files (will use system default if not ; specified). upload_tmp_dir = /www/tmp ### phpinfo() ### upload_tmp_dir no value no value Previous Comments: [2003-12-28 19:12:25] [EMAIL PROTECTED] Can you post your phpinfo() and your php.ini? [2003-12-28 19:10:51] cmouse at youzen dot projectb2 dot net yes, I can confirm it [2003-12-28 19:08:15] [EMAIL PROTECTED] Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). [2003-12-28 19:07:56] [EMAIL PROTECTED] Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). [2003-12-28 19:06:21] cmouse at youzen dot projectb2 dot net Description: php.ini appears not to be read properly by php. I've tried changing values on the file stated by phpinfo() to be the one to read. Unfortunately after restart of apache, no changes reflect. F.ex. I have upload_tmp_dir set to a path, but phpinfo() claims that it's not set. -- Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#26735 [Opn->Fbk]: php.ini not read
ID: 26735 Updated by: [EMAIL PROTECTED] Reported By: cmouse at youzen dot projectb2 dot net -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Linux 2.4.23 PHP Version: 4.3.4 New Comment: Works fine for me: 19:49:41([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r 'phpinfo();' | grep php.ini Configuration File (php.ini) Path => /usr/local/lib/php.ini 19:49:48([EMAIL PROTECTED])[~/src/php-4.3.4]> cat /usr/local/ lib/php.iniupload_tmp_dir = /www/tmp 19:49:57([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r 'phpinfo();' | grep upload_tmp_dir upload_tmp_dir => /www/tmp => /www/tmp Again, 10-1 your php.ini is not what you expect it is. Please repeat the above steps on your system, If you are running this as mod_php, make steps 1 and 3 be clips from the html dump. Previous Comments: [2003-12-28 19:15:35] cmouse at youzen dot projectb2 dot net I'll paste the thing I'm trying to modify: ### php.ini ### ; Temporary directory for HTTP uploaded files (will use system default if not ; specified). upload_tmp_dir = /www/tmp ### phpinfo() ### upload_tmp_dir no value no value [2003-12-28 19:12:25] [EMAIL PROTECTED] Can you post your phpinfo() and your php.ini? [2003-12-28 19:10:51] cmouse at youzen dot projectb2 dot net yes, I can confirm it [2003-12-28 19:08:15] [EMAIL PROTECTED] Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). [2003-12-28 19:07:56] [EMAIL PROTECTED] Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). 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/26735 -- Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#26735 [Fbk->Opn]: php.ini not read
ID: 26735 User updated by: cmouse at youzen dot projectb2 dot net Reported By: cmouse at youzen dot projectb2 dot net -Status: Feedback +Status: Open Bug Type: PHP options/info functions Operating System: Linux 2.4.23 PHP Version: 4.3.4 New Comment: Ok. Here goes: php -r 'phpinfo();' | grep php.ini Configuration File (php.ini) Path => /etc/php/php.ini cat /etc/php/php.ini | grep upload_tmp_dir upload_tmp_dir = "/www/tmp" php -r 'phpinfo();' | grep upload_tmp_dir upload_tmp_dir => no value => no value Previous Comments: [2003-12-28 19:40:28] [EMAIL PROTECTED] Works fine for me: 19:49:41([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r 'phpinfo();' | grep php.ini Configuration File (php.ini) Path => /usr/local/lib/php.ini 19:49:48([EMAIL PROTECTED])[~/src/php-4.3.4]> cat /usr/local/ lib/php.iniupload_tmp_dir = /www/tmp 19:49:57([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r 'phpinfo();' | grep upload_tmp_dir upload_tmp_dir => /www/tmp => /www/tmp Again, 10-1 your php.ini is not what you expect it is. Please repeat the above steps on your system, If you are running this as mod_php, make steps 1 and 3 be clips from the html dump. [2003-12-28 19:15:35] cmouse at youzen dot projectb2 dot net I'll paste the thing I'm trying to modify: ### php.ini ### ; Temporary directory for HTTP uploaded files (will use system default if not ; specified). upload_tmp_dir = /www/tmp ### phpinfo() ### upload_tmp_dir no value no value [2003-12-28 19:12:25] [EMAIL PROTECTED] Can you post your phpinfo() and your php.ini? [2003-12-28 19:10:51] cmouse at youzen dot projectb2 dot net yes, I can confirm it [2003-12-28 19:08:15] [EMAIL PROTECTED] Can you confirm that the file you are editing is the one that PHP is using (according to the php.ini line in phpinfo()). 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/26735 -- Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#26735 [Opn]: php.ini not read
ID: 26735 User updated by: cmouse at youzen dot projectb2 dot net Reported By: cmouse at youzen dot projectb2 dot net Status: Open Bug Type: PHP options/info functions Operating System: Linux 2.4.23 PHP Version: 4.3.4 New Comment: Ah and here are mod_php clips: Configuration File (php.ini) Path /etc/php/php.ini cat /etc/php/php.ini | grep upload_tmp_dir upload_tmp_dir = "/www/tmp" upload_tmp_dir no value no value Previous Comments: [2003-12-28 19:45:55] cmouse at youzen dot projectb2 dot net Ok. Here goes: php -r 'phpinfo();' | grep php.ini Configuration File (php.ini) Path => /etc/php/php.ini cat /etc/php/php.ini | grep upload_tmp_dir upload_tmp_dir = "/www/tmp" php -r 'phpinfo();' | grep upload_tmp_dir upload_tmp_dir => no value => no value [2003-12-28 19:40:28] [EMAIL PROTECTED] Works fine for me: 19:49:41([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r 'phpinfo();' | grep php.ini Configuration File (php.ini) Path => /usr/local/lib/php.ini 19:49:48([EMAIL PROTECTED])[~/src/php-4.3.4]> cat /usr/local/ lib/php.iniupload_tmp_dir = /www/tmp 19:49:57([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r 'phpinfo();' | grep upload_tmp_dir upload_tmp_dir => /www/tmp => /www/tmp Again, 10-1 your php.ini is not what you expect it is. Please repeat the above steps on your system, If you are running this as mod_php, make steps 1 and 3 be clips from the html dump. [2003-12-28 19:15:35] cmouse at youzen dot projectb2 dot net I'll paste the thing I'm trying to modify: ### php.ini ### ; Temporary directory for HTTP uploaded files (will use system default if not ; specified). upload_tmp_dir = /www/tmp ### phpinfo() ### upload_tmp_dir no value no value [2003-12-28 19:12:25] [EMAIL PROTECTED] Can you post your phpinfo() and your php.ini? [2003-12-28 19:10:51] cmouse at youzen dot projectb2 dot net yes, I can confirm it 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/26735 -- Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#26736 [NEW]: __autoload not invoked for missing parent classes
From: jaanus at heeringson dot com
Operating system: Linux
PHP version: 5CVS-2003-12-28 (dev)
PHP Bug Type: Class/Object related
Bug description: __autoload not invoked for missing parent classes
Description:
Autoload is not invoked for missing parent class in object declaration.
This worked with php5-beta2.
Reproduce code:
---
Child_class and Parent_class are in separate documents. Autoload function
is working.
class Child_class extends Parent_class {
}
$class=new Child_class();
Expected result:
No errors, everything loads.
Actual result:
--
Fatal error: Class 'Parent_class' not found in [path to Child_class
document] on line 2
--
Edit bug report at http://bugs.php.net/?id=26736&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26736&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26736&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26736&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26736&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26736&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26736&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26736&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26736&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26736&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26736&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26736&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26736&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26736&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26736&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26736&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26736&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26736&r=float
#26734 [Opn->Ver]: (or) and (||) not the same
ID: 26734
Updated by: [EMAIL PROTECTED]
Reported By: red at ixney dot net
-Status: Open
+Status: Verified
-Bug Type: MySQL related
+Bug Type: Scripting Engine problem
-Operating System: Win XP Pro
+Operating System: Irrelevant
-PHP Version: 4.3.2
+PHP Version: 4.3.4
New Comment:
Nothing to do with Mysql, but more like a parser problem
Apparently || casts the resource to bool (true) and assigns it to the
variable. IMHO the || should either produce a parse error in this
context or behave like 'or'.
Previous Comments:
[2003-12-28 18:11:51] red at ixney dot net
Description:
I always thought '||' and 'or' was the same.
Combined with a mysql_query() however, they are not.
These lines are the same:
mysql_query("$var") or die("help!");
mysql_query("$var") || die("help!");
where $var is a DROP, INSERT or CREATE query, but they are *not* the
same if $var is a SELECT query; the returned value will not be a
'Resource ID' in the latter line.
Reproduce code:
---
mysql_query("DROP TABLE IF EXISTS foobar") || die('Cannot drop table');
mysql_query("CREATE TABLE IF NOT EXISTS foobar (foo INT NOT NULL
AUTO_INCREMENT, bar TINYINT(1), PRIMARY KEY (foo))") || die('Cannot
make table');
// Let's insert some random stuff
mysql_query("INSERT INTO foobar (bar) VALUES (0)") || die('Cannot add
values 1');
mysql_query("INSERT INTO foobar (bar) VALUES (1)") || die('Cannot add
values 2');
mysql_query("INSERT INTO foobar (bar) VALUES (0)") or die('Cannot add
values 3');
mysql_query("INSERT INTO foobar (bar) VALUES (1)") or die('Cannot add
values 4');
$handle1 = mysql_query("SELECT * FROM foobar WHERE 1") || die('Cannot
select');
$handle2 = mysql_query("SELECT * FROM foobar WHERE 1") or die('Cannot
select');
echo '$handle1 is '.$handle1.'';
echo '$handle2 is '.$handle2.'';
Expected result:
$handle1 is Resource id #2
$handle2 is Resource id #3
Actual result:
--
$handle1 is 1
$handle2 is Resource id #3
--
Edit this bug report at http://bugs.php.net/?id=26734&edit=1
#9496 [Ver->NoF]: Mixing non persistant and persistant connection makes all connexions persistant
ID: 9496
Updated by: [EMAIL PROTECTED]
Reported By: jean-francois dot gosset at telintrans dot fr
-Status: Verified
+Status: No Feedback
Bug Type: OCI8 related
Operating System: linux red hat 6.2
PHP Version: 4.0.4pl1
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2003-12-19 02:29:13] [EMAIL PROTECTED]
Could you, please, try it with latest CVS snapshots of PHP5 & PHP4?
This behaviour was changed in PHP5 recently.
[2003-12-18 17:14:41] kamil at okac dot org
The behaviour is correct for the case when you call OCILogon('u1','p1')
and OCIPLogon('u1','p1') (with the same user), but incorrect when you
call OCILogon('u1','p1') and OCIPlogon('u2','p2'). The latter case
creates two sessions (that's correct - can't be shared, because two
different users are logging in), but both sessions are made
persistent.
This happens even if OCIPlogon and OCILogon are not called within one
script but handled by the same process.
Maybe the problem is in the reusing of persistent server connections
(where usernames are not involved).
[2002-04-13 08:18:07] [EMAIL PROTECTED]
i still cannot see any problem. you approach would consume _more_
resourcs on the oracle server. anyhow this is not a bug.
[2001-06-15 03:53:55] jean-francois dot gosset at telintrans dot fr
I think this behaviour is confusing.
One can have the needs to mix persistant and non persistant connexion
on the same database. In my case, I want to validate an account with a
personal username and after use a generic account. The first one must
not be persistant because we would have too much connexions open.
[2001-05-04 10:44:07] [EMAIL PROTECTED]
OCIPlogon() will do the same as OCILogon() but mark the sever and
session handle as persistent, which means that PHP won't close them on
script-end. if your script does a OCILogon("s","t") and later a
OCIPLogon("s","t") _no_ new server or session handle will be created
but instead the existing ones will be marked persistent.
this is intended behaviour - why would we want to change it?
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/9496
--
Edit this bug report at http://bugs.php.net/?id=9496&edit=1
#26734 [Ver->Bgs]: (or) and (||) not the same
ID: 26734
Updated by: [EMAIL PROTECTED]
Reported By: red at ixney dot net
-Status: Verified
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Irrelevant
PHP Version: 4.3.4
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
|| is boolean or
'or' is logical or
they are not the same
Previous Comments:
[2003-12-28 21:37:58] [EMAIL PROTECTED]
Nothing to do with Mysql, but more like a parser problem
Apparently || casts the resource to bool (true) and assigns it to the
variable. IMHO the || should either produce a parse error in this
context or behave like 'or'.
[2003-12-28 18:11:51] red at ixney dot net
Description:
I always thought '||' and 'or' was the same.
Combined with a mysql_query() however, they are not.
These lines are the same:
mysql_query("$var") or die("help!");
mysql_query("$var") || die("help!");
where $var is a DROP, INSERT or CREATE query, but they are *not* the
same if $var is a SELECT query; the returned value will not be a
'Resource ID' in the latter line.
Reproduce code:
---
mysql_query("DROP TABLE IF EXISTS foobar") || die('Cannot drop table');
mysql_query("CREATE TABLE IF NOT EXISTS foobar (foo INT NOT NULL
AUTO_INCREMENT, bar TINYINT(1), PRIMARY KEY (foo))") || die('Cannot
make table');
// Let's insert some random stuff
mysql_query("INSERT INTO foobar (bar) VALUES (0)") || die('Cannot add
values 1');
mysql_query("INSERT INTO foobar (bar) VALUES (1)") || die('Cannot add
values 2');
mysql_query("INSERT INTO foobar (bar) VALUES (0)") or die('Cannot add
values 3');
mysql_query("INSERT INTO foobar (bar) VALUES (1)") or die('Cannot add
values 4');
$handle1 = mysql_query("SELECT * FROM foobar WHERE 1") || die('Cannot
select');
$handle2 = mysql_query("SELECT * FROM foobar WHERE 1") or die('Cannot
select');
echo '$handle1 is '.$handle1.'';
echo '$handle2 is '.$handle2.'';
Expected result:
$handle1 is Resource id #2
$handle2 is Resource id #3
Actual result:
--
$handle1 is 1
$handle2 is Resource id #3
--
Edit this bug report at http://bugs.php.net/?id=26734&edit=1
#26735 [Opn->Fbk]: php.ini not read
ID: 26735 Updated by: [EMAIL PROTECTED] Reported By: cmouse at youzen dot projectb2 dot net -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Linux 2.4.23 PHP Version: 4.3.4 New Comment: what does this (with correct path substiitution) return you: strace -eopen ./sapi/cli/php -r '' 2>&1 | grep ini Previous Comments: [2003-12-28 19:48:22] cmouse at youzen dot projectb2 dot net Ah and here are mod_php clips: Configuration File (php.ini) Path /etc/php/php.ini cat /etc/php/php.ini | grep upload_tmp_dir upload_tmp_dir = "/www/tmp" upload_tmp_dir no value no value [2003-12-28 19:45:55] cmouse at youzen dot projectb2 dot net Ok. Here goes: php -r 'phpinfo();' | grep php.ini Configuration File (php.ini) Path => /etc/php/php.ini cat /etc/php/php.ini | grep upload_tmp_dir upload_tmp_dir = "/www/tmp" php -r 'phpinfo();' | grep upload_tmp_dir upload_tmp_dir => no value => no value [2003-12-28 19:40:28] [EMAIL PROTECTED] Works fine for me: 19:49:41([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r 'phpinfo();' | grep php.ini Configuration File (php.ini) Path => /usr/local/lib/php.ini 19:49:48([EMAIL PROTECTED])[~/src/php-4.3.4]> cat /usr/local/ lib/php.iniupload_tmp_dir = /www/tmp 19:49:57([EMAIL PROTECTED])[~/src/php-4.3.4]> ./sapi/cli/php -r 'phpinfo();' | grep upload_tmp_dir upload_tmp_dir => /www/tmp => /www/tmp Again, 10-1 your php.ini is not what you expect it is. Please repeat the above steps on your system, If you are running this as mod_php, make steps 1 and 3 be clips from the html dump. [2003-12-28 19:15:35] cmouse at youzen dot projectb2 dot net I'll paste the thing I'm trying to modify: ### php.ini ### ; Temporary directory for HTTP uploaded files (will use system default if not ; specified). upload_tmp_dir = /www/tmp ### phpinfo() ### upload_tmp_dir no value no value [2003-12-28 19:12:25] [EMAIL PROTECTED] Can you post your phpinfo() and your php.ini? 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/26735 -- Edit this bug report at http://bugs.php.net/?id=26735&edit=1
#13207 [Com]: open_basedir not restricting file access properly
ID: 13207 Comment by: etng at zju dot edu dot cn Reported By: jedi at tstonramp dot com Status: Bogus Bug Type: IIS related Operating System: NT 4.0 PHP Version: 4.0.6 New Comment: I'am use PHP/4.3.5-dev under windows server2003(build3790) with Apache/2.0.45. I want to make my computer do as a server for my classmate to publish their websites use the pattern ~/username. so i create a dir named pws in drive G:\.And then add a test username as test and make a dir public_html unser it. And i have set the httpd.conf of Apache right,when I visit http://localhost:8080//~test/opendir.php I found it is too dangerous to do that if someone try to hack me. the sourcecode of the opendir.php is like this: "; } closedir($handle); ?> Is there something wrong whith the paramiter open_basedir in my php.ini file? in that section,i set like this: ; open_basedir, if set, limits all file operations to the defined directory ; and below. This directive makes most sense if used in a per-directory ; or per-virtualhost web server configuration file. This directive is ; *NOT* affected by whether Safe Mode is turned On or Off. open_basedir =G:\PWS\*\public_html;E:\QSC ~ user_dir;~~~apache docroot so how can I make it more safe? please tell me ,3x. C:\Documents and Settings\Administrator>apache -V Server version: Server built: Apr 1 2003 09:24:16 Server's Module Magic Number: 20020903:0 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/winnt" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/apache" -D SUEXEC_BIN="/apache/bin/suexec" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error.log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" Previous Comments: [2002-06-03 12:16:18] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately your version of PHP is too old -- 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. [2001-12-02 04:47:36] [EMAIL PROTECTED] Reproduced with 4.1.0RC4 on Windows 2000 with Apache 1.3.22! Is this a bug or non-documented behaviour??? [2001-11-11 12:20:29] [EMAIL PROTECTED] Try using a slahs (/) or a double backslash (\\) instead of a single backslash. Does that work? [2001-09-10 02:20:12] jedi at tstonramp dot com Unless there is some other configuration I'm not aware of, I mentioned in the bug report that I have open_basedir enabled in that it says C:\inetpub as my open_basedir value when I do phpinfo() If there's something wrong with the path format, I guess I could understand that, although I've seen other Win-style path formats in phpinfo that take the same format. [2001-09-07 21:25:52] [EMAIL PROTECTED] You don't have open_basedir enabled. The error message from an open_basedir restriction is not "permission denied". Does your phpinfo() output tell you that open_basedir is in effect? 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/13207 -- Edit this bug report at http://bugs.php.net/?id=13207&edit=1
#26737 [NEW]: unexpected __sleep() serialization behavior
From: rob at cue dot cc
Operating system: Mac OSX 10.3.2
PHP version: 5.0.0b2 (beta2)
PHP Bug Type: Session related
Bug description: unexpected __sleep() serialization behavior
Description:
I have an object instance ($obj_root) that I want to
persist in a
session.
The object's class (object_container) defines the
__sleep() function, and
returns the array of member variables to be serialized.
function __sleep()
{
return array("objs");
}
The member variable 'objs' ($this->objs = array('foo');)
is not serialized as expected;
Arrays or other object-types result in null strings.
Upon comparing the serialized instance strings, I have
discovered that the string-ified names of the member
variables are very different:
serialize() without __sleep() wraps null chars around
the instance class name, followed by the member variable
name.
obj_root|O:16:"object_container":1:{s:
22:"[EMAIL PROTECTED]@objs";a:1:{s:3:"foo"
serialize() with __sleep() uses the plain member
variable name, and dismisses it as null.
If I use the __sleep() function and supply the member
variable name with null chars quoting the class name the
serialization works.
function __sleep()
{
return array("\0object_container\0objs");
}
Could this be a bug, or should the documentation be
updated to reflect this curious behaviour of __sleep().
--
Edit bug report at http://bugs.php.net/?id=26737&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26737&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26737&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26737&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26737&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26737&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26737&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26737&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26737&r=support
Expected behavior: http://bugs.php.net/fix.php?id=26737&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26737&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26737&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26737&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26737&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26737&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26737&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26737&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26737&r=float
