[PHP-DEV] Generating code on fly
How to solve such problem: I need to generate PHP code on fly and then execute it. For example, $s='$var+=5;' - how to tell php to execute this code. Waiting for your replies. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10689: When adding the SID to the end of a URL in a a href, not HTML4 compliant.
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.5 PHP Bug Type: *Session related Bug description: When adding the SID to the end of a URL in a lt;a hrefgt;, not HTML4 compliant. When the session code adds the SID to the end of the a href it does it like: a href=test.php?q=somethingSID=123123123 The should be amp;. It fails on HTML4 validation. I can't get my pages to validate currently. -- Edit Bug report at: http://bugs.php.net/?id=10689edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend API changes
[Björn Schotte [EMAIL PROTECTED]] * Zeev Suraski wrote: There's a good starting point already, people are more than welcome to extend it. I don't understand why people should work in their spare-time on a tool which is published under the Zend Licence (which is similar to QPL). As we know of QPL, all developer's seem to be equal, but some seem to be more equal. As you know from Daniel Grossmann, I'm not the only one who has this opinion. Although I would not use the same tone, I completely understand why some people feel this way. Since the Zend engine is not pure open-source, IMHO Zend Ltd. have a bigger obligation to the PHP community to document all of the API than if Zend carried, say, a BSD license (because then it'd be more natural for the community to chip in). - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend API changes
[Zeev Suraski [EMAIL PROTECTED]] At 21:05 4/5/2001, Hartmut Holzgraefe wrote: PS: about the welcome thing above ... - you should know that i have put a lot of work into the manual (both english and german) and the function tables Hartmut, I wasn't trying to understate your work on the manual; I told you personally that the function reference mechanism that you build was very impressive and useful. I wasn't being sarcastic when I invited you (and anyone else) to help document the Zend API. I know I won't be getting around to doing it in the near future, so if nobody else does it, it'll simply remain undone. - afair there was someone who started to write a 'extension building manual' or something about a year ago and it was you , Zeev, who told him that this was useless effort as this was already beeing taken care off (without pointing him to this project or inviting him to join it) correct me if i'm wrong as i do not have found this posting in my archives yet You're not wrong; It's been done and published (http://www.zend.com/apidoc/), and is the base for additional work that I invited people to improve on. Hey, are the sources for this manual available somewhere? CVS maybe? - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend API changes
At 11:41 6/5/2001, Stig Sæther Bakken wrote: You're not wrong; It's been done and published (http://www.zend.com/apidoc/), and is the base for additional work that I invited people to improve on. Hey, are the sources for this manual available somewhere? CVS maybe? Yep, sure thing; cvs.zend.com, co ZendAPI; Released under OPL, and written in the same formats everyone in here's used to work with :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Generating code on fly
This is not the right forum to ask this type of questions - it's for people who develop PHP, not (necessarily) people who develop with PHP. The right forum to ask this question would be [EMAIL PROTECTED] In order to cut down time, look at http://www.php.net/eval Zeev At 12:23 6/5/2001, Pisman Dmitriy wrote: How to solve such problem: I need to generate PHP code on fly and then execute it. For example, $s='$var+=5;' - how to tell php to execute this code. Waiting for your replies. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: Bug #10682 Updated: php -l display the same errors
""Yasuo Ohgaki"" [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... If I disable one of display_errors and log_errors in php.ini, then it prints 2 errors. If I disable both them in php.ini, it does not display any errors. I thought there might be a problem. I guess this is the way it is. php -d display_errors=off -d log_errors=off [-l | -f] works *perfectly* while they are set "On" in php.ini. I noticed my mistake in this mail. php -d display_errors=off -d log_errors=off [-l | -f] does not work php -d display_errors=off -d error_log=off [-l | -f] works and prints only useful error messages for Emacs when debug is enabled. Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard fsock.c fsock.h /main network.cphp_network.h php_streams.h streams.c
On 2001-05-06 07:07:54, Sebastian Bergmann [EMAIL PROTECTED] wrote: Wez Furlong wrote: Fixed and on the PHP_4_0_6 branch. fsock.c D:\Programme\MS Visual Studio\Projekte\php\php4\ext\standard\fsock.c(431) : erro r C2065: 'FD_SETSIZE' : undeclared varaible Thats the PHP_WIN32 stuff; fixed by replacing a series of #includes with php_network.h. I'll merge it in a couple of minutes. --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #10684 Updated: Installation Problem
Sorry for direct posting - I can't get onto the bugs database at the moment. Copying php.ini is the last thing the installer does before running the bit that configures IIS - and this is the thing that uses MSCOMCTL. I suspect that your registration of that module failed or you have a dodgy module - is the Win98 dir a standard feature of W2K or perhaps something left over from an old Win98 installation - I'm guessing here but maybe the MSCOMCTL that you have is the wrong version for W2K? In any event, php will be installed ok on your system, all you need to do is forget the automatic IIS configuration and manually configure the php script mapping in the Microsoft Mamnagement Console as per the installation notes. Good luck! -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10689 Updated: When adding the SID to the end of a URL in a a href, not HTML4 compliant.
ID: 10689 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Session related Operating system: PHP Version: 4.0.5 Assigned To: Comments: Check the php.ini file for arg_separator.output directive. This is the old arg_separator directive. (There is also arg_separator.input but it's safe to leave it untouched.) --Jani Previous Comments: --- [2001-05-06 04:34:16] [EMAIL PROTECTED] When the session code adds the SID to the end of the a href it does it like: a href=test.php?q=somethingSID=123123123 The should be amp;. It fails on HTML4 validation. I can't get my pages to validate currently. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10689edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Branching 4.0.6...
On Sat, 5 May 2001, Wez Furlong wrote: On 2001-05-05 19:02:29, Andi Gutmans [EMAIL PROTECTED] wrote: Hi, Now that the pressing problems have been fixed in the CVS I'd like to branch 4.0.6 and release an RC1. Any objections? No, but you may want to check that my commit for fsock/network related files works for you all before you branch, just in case. It works for me, and it shouldn't affect you unless you enable the streams stuff in configure. The GD config stuff is also still busted. On www.php.net, the config system detected GIF support in GD-1.8.3.. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Zend API changes
You're not wrong; It's been done and published (http://www.zend.com/apidoc/), and is the base for additional work that I invited people to improve on. Hey, are the sources for this manual available somewhere? CVS maybe? Yep, sure thing; cvs.zend.com, co ZendAPI; Released under OPL, and written in the same formats everyone in here's used to work with :) At the moment its all one big XML file, would anyone object to me splitting it up into more manageable chunks like we do with phpdoc etc? - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Zend API changes
At 14:14 6/5/2001, James Moore wrote: You're not wrong; It's been done and published (http://www.zend.com/apidoc/), and is the base for additional work that I invited people to improve on. Hey, are the sources for this manual available somewhere? CVS maybe? Yep, sure thing; cvs.zend.com, co ZendAPI; Released under OPL, and written in the same formats everyone in here's used to work with :) At the moment its all one big XML file, would anyone object to me splitting it up into more manageable chunks like we do with phpdoc etc? Nope - go ahead! Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9896 Updated: segfaults at $xmldoc-add_root(root);
ID: 9896
Updated by: chregu
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DOM XML related
Operating system:
PHP Version: 4.0 Latest CVS (21/03/2001)
Assigned To:
Comments:
This still does not work in latest cvs (06/05/2001).
used another machine with libxml2-2.3.7 and linux-kernel 2.4.0. If one needs another
backtrace, i can make one...
also
$xml = xmldocfile(config.xml);
$root = domxml_root($xml);
produces a segfault (config.xml is a very simple xml file)
Previous Comments:
---
[2001-03-22 04:56:25] [EMAIL PROTECTED]
test-program:
$xmldoc = domxml_new_xmldoc('1.0');
$xmldoc-add_root(bla);
gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x401a3938 in objects () at zend_operators.c:1144
1144}
(gdb) bt
#0 0x401a3938 in objects () at zend_operators.c:1144
#1 0x402c13e4 in php4_module () from /usr/local/apache/libexec/libphp4.so
#2 0x401d892a in objects () at php_domxml.c:668
#3 0x40199707 in objects () at ./zend_execute.c:853
#4 0x401aafc0 in objects () at zend.c:260
#5 0x401c3be3 in objects () at main.c:1126
#6 0x401bf11e in objects () at sapi_apache.c:98
#7 0x401bfe89 in objects () at mod_php4.c:437
#8 0x401bfed3 in objects () at mod_php4.c:437
#9 0x8074c09 in ap_invoke_handler ()
#10 0x808a0cf in process_request_internal ()
#11 0x808a142 in ap_process_request ()
#12 0x8080d96 in child_main ()
#13 0x8080f55 in make_child ()
#14 0x80810d6 in startup_children ()
#15 0x808175c in standalone_main ()
#16 0x8081f8c in main ()
#17 0x40096a8e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93
---
[2001-03-21 15:27:09] [EMAIL PROTECTED]
Delete config.cache, add --enable-debug into your configure line, 'make clean ; make ;
make install' and generate a GDB backtrace of the crash and add it into this bug
report.
--Jani
---
[2001-03-21 06:08:29] [EMAIL PROTECTED]
Reproduce with:
$xmldoc = domxml_new_xmldoc('1.0');
domxml_add_root($xmldoc,bla);
Configure
./configure --with-config-file-path=/usr/local/apache/conf --with-zlib --with-mysql
--with-sablot --with-apxs=/usr/local/apache/bin/apxs --enable-versioning
--with-dom=/opt/gnome
libxml2-2.3.3
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9896edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] CVS Account Request
Full name: Dejan Gregor Email: [EMAIL PROTECTED] ID: ssddgreg Purpose: Educational -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10191 Updated: file missing
ID: 10191 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: Apache related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: No feedback Previous Comments: --- [2001-04-05 14:43:10] [EMAIL PROTECTED] there is no such thing as a *NT port*, all versions of PHP for different systems/platforms are built from the same source you are most likely refering to a special precompiled distribution of PHP for Windows? it might help if you gave us the link you got it from --- [2001-04-05 14:33:05] [EMAIL PROTECTED] File PEAR.php and all the structure is missing from the NT port. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10191edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9324 Updated: libmcrypt 2.4.9 causes problems
ID: 9324 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: mcrypt related Operating system: PHP Version: 4.0 Latest CVS (11/02/2001) Assigned To: derick Comments: NO Feedback Previous Comments: --- [2001-04-09 20:08:15] [EMAIL PROTECTED] I could not contact your site. Can you please check it with the latest CVS and libmcrypt 2.4.10? --- [2001-02-18 09:37:45] [EMAIL PROTECTED] Another one to investigate --- [2001-02-18 09:31:29] [EMAIL PROTECTED] on a phpinfo i get upto the mcrypt module then i get . . . mcrypt Fatal error: Maximum execution time of 15 seconds exceeded in /home/gamr/vhosts/tnt.dynomyte.net/htdocs/index.php on line 2 it was compiled against 2.4.9 not an old version then i updated mcrypt . . . any more details SHOULD be available at http://tnt.dynomyte.net --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9324edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] extension/module versioning
On 2001-05-06 02:06:42, [EMAIL PROTECTED] wrote:
what are the chances of having a function call for every extension that
returns the version? this would be extremely useful for determining
whether the correct version is installed, rather than checking to see
if the function_exists().
$version_id = xml_version();
As someone else suggested, get_extension_version('xml') is probably the
better way to implement this.
The zend module structure could very easily be adapted to retain the
version number.
Being lazy, I would like to see it bump automatically, but since it would
need to change each time a parameter/function is added/removed that's
difficult :-)
--Wez.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10150 Updated: Error when compiling Apache 1.3.14+SSL with static PHP4.0.4
ID: 10150 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: Compile Failure Operating system: PHP Version: 4.0.4 Assigned To: Comments: No feedback Previous Comments: --- [2001-04-04 06:00:47] [EMAIL PROTECTED] Could you please try the latest CVS snapshot from http://snaps.php.net/ as there have been some fixes regarding this. (and just use the configure line without any LIBS defined) --Jani --- [2001-04-04 01:47:26] [EMAIL PROTECTED] When compiling apache 1.3.14 (with apache-ssl patches applied) and php 4.0.4 (Static) I get the following results: ...snip... gcc -DLINUX=2 -DTARGET=httpsd -I/data/apache/php-4.0.4 -I/data/apache/php-4.0.4/main -I/data/apache/php-4.0.4/main -I/data/apache/php-4.0.4/Zend -I/data/apache/php-4.0.4/Zend -I/data/apache/php-4.0.4/TSRM -I/data/apache/php-4.0.4/TSRM -I/data/apache/php-4.0.4 -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED -DAPACHE_SSL `./apaci` -o httpsd buildmark.o modules.o modules/standard/libstandard.a modules/ssl/libssl.a modules/php4/libphp4.a main/libmain.a ./os/unix/libos.a ap/libap.a lib/expat-lite/libexpat.a -lnss_dns -rdynamic -Lmodules/php4 -L../modules/php4 -L../../modules/php4 -lmodphp4 -lpam -lc-client -ldl -lresolv -lm -ldl -lcrypt -lnsl -lresolv -lm -L/usr/local/ssl/lib -lssl -lcrypto modules/php4/libphp4.a(dns.lo): In function `php_if_checkdnsrr': /data/apache/php-4.0.4/ext/standard/dns.c:200: undefined reference to `__res_search' ...snip... I saw a similar problem reported (bug# 4739) but as you can see above, I attempted to run configure with the 'EXTRA_LIBS=-lnss_dns and still no luck. (Actually the configure script reported that EXTRA_LIBS was deprecated and should be replaced with simply LIBS so thats what I did.) Any suggestions? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10150edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10168 Updated: openssl.c function uses an undeclared variable
ID: 10168 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: Compile Failure Operating system: PHP Version: 4.0 Latest CVS (04/04/2001) Assigned To: Comments: Fixed no Feedback Previous Comments: --- [2001-04-05 04:48:26] [EMAIL PROTECTED] Thanks for pointing this out. That line should read: gmadjust = -(thetime.tm_isdst ? timezone - 3600 : timezone + 3600); so thats thetime.tm_isdst instead of is_dst. Sorry about that - my system has gmtoff, so I didn't catch this. Please either update your CVS or make the change and confirm that this works correct. --- [2001-04-04 15:48:17] [EMAIL PROTECTED] openssl.c: In function `asn1_time_to_time_t': openssl.c:459: `is_dst' undeclared (first use in this function) openssl.c:459: (Each undeclared identifier is reported only once openssl.c:459: for each function it appears in.) make[1]: *** [openssl.lo] Error 1 make[1]: Leaving directory `/space/pruebas/php4/ext/openssl' make: *** [all-recursive] Error 1 is_dst (as I saw in some other c files) should be defined at the begining of the function `asn1_time_to_time_t', but it's not. So I declared it as int with default value -1 and looks like that fixed it. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10168edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Branching 4.0.6...
On 2001-05-06 12:04:32, Sascha Schumann [EMAIL PROTECTED] wrote: The GD config stuff is also still busted. On www.php.net, the config system detected GIF support in GD-1.8.3.. How can that be? The gif stuff is detected via AC_CHECK_LIB (I didn't touch that part!) --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #5404 Updated: String conversion to integer is incorrect
ID: 5404 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Analyzed Status: Closed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.1 Assigned To: Comments: Fixed at last - thanks for the report! Previous Comments: --- [2000-08-05 12:27:47] [EMAIL PROTECTED] Yes, strtod makes mess from 0x-numbers (I suspect it being libc bug, but maybe they intended it to be so), so we should catch them in strtol. --- [2000-08-05 04:28:40] [EMAIL PROTECTED] Yes, of course, sorry about the typo. It seems to me that the place where this is done in such a way is in the function is_numeric_string() in the file zend_operators.* --- [2000-08-04 23:36:30] [EMAIL PROTECTED] you're talking about strtol() here, not strtod(), aren't you? --- [2000-08-04 01:50:38] [EMAIL PROTECTED] No, it is not necessary to create a new strtod function, because when php checks if the string is a number or not it explicitly tells strtod, that the string is a base 10 number, instead of letting strtod determine the base itself, which would result in the correct behaviour. --- [2000-08-03 21:52:51] [EMAIL PROTECTED] so maybe we should add some kind of strtod-wrapper to get around this libc 'feature'? --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5404edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #6385 Updated: __FILE__ returns lowercased filenames
ID: 6385
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Feedback
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0 Latest CVS (27/08/2000)
Assigned To:
Comments:
Does this still happen with 4.0.5 or latest CVS? I can't reproduce it.
Previous Comments:
---
[2001-01-08 15:40:35] [EMAIL PROTECTED]
not IIS-specific, reclassifying
---
[2000-11-04 06:34:12] [EMAIL PROTECTED]
tested on CGI+ApacheMod, both return lowercased
---
[2000-08-31 09:02:16] [EMAIL PROTECTED]
Does this happen with CGI version? I suspect it might be just IIS which sets your
filename lowercase...
---
[2000-08-27 21:28:47] [EMAIL PROTECTED]
if I´m calling a file FooBar.php, echo __FILE__; will
output foobar.php.
Although w32 allows files only in-sensitive (no FooBar.php
and foobar.php concurrently) it saves the case information
and thus __FILE__ (and related) should contain this cased
information too.
This will bug will also cause scripts not to be platform
independend:
// filename lowercased
$filename=basename(__FILE__);
// HTTP REQUEST, w cased filename
$fullpage=substr($tmp=strtolower(getenv('SERVER_PROTOCOL')),0,strpos($tmp,'/')).'://'.getenv('HTTP_HOST').getenv('REQUEST_URI');
$pageonly=substr($fullpage,0,strpos($fullpage,$filename)+strlen($filename));
hile this script should work on *nix calling foobar.php it
does not on w32
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6385edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] tracking down segfaults
I don't suppose any of you guys have a magic way of tracking down rare segfaults in apache? Occaisonally I get a seg fault in apache, but I can't pin down the precise circumstances. What would be nice is a way to automatically generate a backtrace during a segfault. Also, it would be great if the zend engine could catch the fault and dump the php call stack to the error log too. Any ideas? --Wez. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
AW: [PHP-DEV] Zend API changes
-Ursprüngliche Nachricht- Von: Zeev Suraski [mailto:[EMAIL PROTECTED]] Gesendet: Sonntag, 06. Mai 2001 10:49 An: Stig Sæther Bakken Cc: Hartmut Holzgraefe; [EMAIL PROTECTED] Betreff: Re: [PHP-DEV] Zend API changes At 11:41 6/5/2001, Stig Sæther Bakken wrote: You're not wrong; It's been done and published (http://www.zend.com/apidoc/), and is the base for additional work that I invited people to improve on. Hey, are the sources for this manual available somewhere? CVS maybe? Yep, sure thing; cvs.zend.com, co ZendAPI; Released under OPL, and written in the same formats everyone in here's used to work with :) cvs server: cannot find module `ZendAPI' - ignored cvs [checkout aborted]: cannot expand modules user: cvsread is there a downloadable version too ? chm or pdf would be really nice. harald -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: AW: [PHP-DEV] Zend API changes
At 16:32 6/5/2001, Harald Radi wrote: -Ursprüngliche Nachricht- Von: Zeev Suraski [mailto:[EMAIL PROTECTED]] Gesendet: Sonntag, 06. Mai 2001 10:49 An: Stig Sæther Bakken Cc: Hartmut Holzgraefe; [EMAIL PROTECTED] Betreff: Re: [PHP-DEV] Zend API changes At 11:41 6/5/2001, Stig Sæther Bakken wrote: You're not wrong; It's been done and published (http://www.zend.com/apidoc/), and is the base for additional work that I invited people to improve on. Hey, are the sources for this manual available somewhere? CVS maybe? Yep, sure thing; cvs.zend.com, co ZendAPI; Released under OPL, and written in the same formats everyone in here's used to work with :) cvs server: cannot find module `ZendAPI' - ignored cvs [checkout aborted]: cannot expand modules user: cvsread Are you sure you're using cvs.zend.com:/repository? is there a downloadable version too ? chm or pdf would be really nice. Right now there's only the online HTML version. It should be possible to generate other formats as well... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10690: pdf_open_memory_image() not implemented in Windows version
From: [EMAIL PROTECTED] Operating system: Win32 PHP version: 4.0.5 PHP Bug Type: PDF related Bug description: pdf_open_memory_image() not implemented in Windows version pdf_open_memory_image() is not implemented in PHP 4.0.5 and all previous versions - for Win32. Other platforms have this function since v4.0. NB: same as #10606, but it appears on all versions of windows. -- Edit Bug report at: http://bugs.php.net/?id=10690edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Porting to VMS, facing pedantic compiler
I've been porting PHP to VMS for the past couple of weeks, how can I feed back some of my changes into the source tree so it's less work to track the changes? The fixes I'm interested in don't apply to VMS per se, but rather cases where the compiler squawks about intermixing signed and unsigned char pointers. An example is at http://www.er6.eng.ohio-state.edu/~jonesd/php/diffs/html.c.diff You can tell the compiler to not issue pointer mismatch warnings, but that disables it for all types of pointers - not a good idea. -- David L. Jones | Phone:(614) 292-6929 Ohio State Unviversity | Internet: 1971 Neil Ave. Rm. 406 | [EMAIL PROTECTED] Columbus, OH 43210 | [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #5653 Updated: with setcookie(), only the last cookie is written
ID: 5653 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Other web server Operating system: PHP Version: 4.0 Release Candidate 2 Assigned To: Comments: is this still the case with the latest 4.0.5 release? Previous Comments: --- [2000-10-30 09:40:14] [EMAIL PROTECTED] reclassified. --- [2000-09-14 16:33:52] [EMAIL PROTECTED] This behaviour is still visible in PHP 4.0.2 with Roxen (pike 7.0.58). --- [2000-08-17 16:19:50] [EMAIL PROTECTED] This is not a session-related issue. Reclassifying. --- [2000-08-15 16:04:24] [EMAIL PROTECTED] seems to be another error related to roxen sapi and cookies ... PS: bug report form should have a sapi input field --- [2000-08-15 15:57:06] [EMAIL PROTECTED] user feedback: Yes, I tried the latest snapshot from 15.Aug.2000. But the Result is still the same. Maybe you can give me a hint how to give a trace or debug a certain part of php4 --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5653edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #5882 Updated: Use inline directive in *.c files for global functions in Zend engine
ID: 5882 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Compile Failure Operating system: PHP Version: 4.0.1pl2 Assigned To: Comments: Is this still the case with Php 4.0.5? Previous Comments: --- [2000-12-07 19:42:03] [EMAIL PROTECTED] User feedback: Yes, still not working. When run httpd -X and try to open .php file this message: 98571:/usr/local/apache/bin/httpd: rld: Fatal Error: attempted access to unresolvable symbol in /usr/local/apache/libexec/libphp4.so: _array_init MIPSPro C 7.3.1.1 IRIX 6.5.8 In .c files you still use static inline functions, which not supported for exporting in SGI C compiller. - --- [2000-11-21 06:12:34] [EMAIL PROTECTED] Please try the latest snapshot from http://snaps.php.net/ as this should be fixed now. --Jani --- [2000-11-01 02:09:56] [EMAIL PROTECTED] Does this still happen with the latest version? Try 4.0.3pl1 or get the latest snapshot from snaps.php.net. Thanks, Andi --- [2000-08-30 05:08:28] [EMAIL PROTECTED] User environment: MIPSPro C 7.3.1.1 IRIX 6.5.8 --- [2000-08-15 12:42:12] [EMAIL PROTECTED] The user probably needs to configure PHP with --enable-c9x-inline Please try this and report back to us whether it works for you. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5882edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #2892 Updated: php -a (interactive mode) doesn't call functions
ID: 2892
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Assigned
Status: Closed
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0 Beta 3
Assigned To: Andi
Comments:
Beat ya to it, Andi :)
Fixed in the CVS
Previous Comments:
---
[2001-04-29 13:39:24] [EMAIL PROTECTED]
Interactive mode is very limited and only meant to check simple things with. We can
keep it as an assigned bug but I don't think it'll ever be fixed.
---
[2000-07-23 11:06:27] [EMAIL PROTECTED]
Yes it does.
---
[2000-07-23 02:54:18] [EMAIL PROTECTED]
Is this problem still occuring in the most recent release?
---
[1999-12-02 06:43:12] [EMAIL PROTECTED]
Script set.php3:
?
class x {
var $a=2;
function seta ($b) {
$this-a = $b;
echo $bn;
}
}
$y = new x();
echo $y-a,n;
$y-seta(10);
echo $y-a,n;
?
Run: php -f set.php3
get:
2
10
10
still OK. Now run php -a set.php3:
Interactive mode enabled
Content-Type: text/html
2
2
Huh? where's my method call? Or interactive mode isn't what I thought it is?
Strange thing is that php set.php3 does work, so what interactive mode is in fact?
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=2892edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #6598 Updated: Memory overflow
ID: 6598 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Analyzed Status: Closed Bug Type: MySQL related Operating system: PHP Version: 4.0.1pl2 Assigned To: Comments: In php 4.0.5 there is a new function, called mysql_unbuffered_query() which will do this for you. Previous Comments: --- [2000-11-02 07:15:28] [EMAIL PROTECTED] Well, mysql_use_result is not too nice - it basically ties down your connection and any tables used until the end of the operation... But maybe it should indeed be possible to use this with some parameter to mysql_query. --- [2000-09-07 08:17:14] [EMAIL PROTECTED] When I try to get dump of my table (about 5.000.000 records) cause memory overflow. When I check problem, I found, that php always use mysql_store_result(), and never mysql_use_result() (from C API). At mysql (comand line tool) I can use option -q. which forse use mysql_use_result(). I need someting like in php. Maybe as additionall argument in mysql_query, maybe as constant in configuation file, maybe other. ?PHP mysql_connect(localhost,...,...); mysql_select_db(...); $res=mysql_query(select * from big_table); $row=mysql_fetch_row($res); echo $row[0]; mysql_free_result($res); ? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=6598edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #6922 Updated: Cannot load /etc/httpd/modules/libphp4.so into server
ID: 6922 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Dynamic loading Operating system: PHP Version: 4.0.2 Assigned To: Comments: Can you try this with php 4.0.5 and see if this problem still exists? Previous Comments: --- [2000-09-28 06:27:16] [EMAIL PROTECTED] I have the following configuration options for dynamic php: sh ./configure --prefix=/usr --without-gd --with-apxs=/usr/sbin/apxs --enable-versioning --with-config-file-path=/usr/lib --enable-debugger=yes --enable-safe-mode --with-exec-dir=/usr/bin --with-mysql --with-oci8=/u01/app/oracle/product/8.1.5 --with-pdflib=/usr --with-system-regex --enable-track-vars --with-ttf --with-zlib --with-wddx This configures and compiles fine. I configured the httpd.conf files with the appropriate module paths... LoadModule php4_modulemodules/libphp4.so AddModule mod_php4.c Since I'm running oracle 8.1.5.01(with patches) for linux, I even made sure the LD_LIBRARY_PATH was available for apache LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/u01/app/oracle/product/8.1.5/lib export LD_LIBRARY_PATH Then I start apache... /usr/local/apache/bin/apachectl start However, this is the error I get every time. [root@redora init.d]# ./httpd start Starting httpd: Syntax error on line 874 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/libphp4.so into server: /etc/httpd/modules/libphp 4.so: undefined symbol: php_regcomp [FAILED] [root@redora init.d]# I believe this problem involves how php4's routine interfaces with the oracle sqlplus calls although I'm not too sure exactly where it breaks. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=6922edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Success magazine says, We create millionaires!!
Is your business a very profitable one? Is it making you all the money that you need? Do you need a little bit MORE? READ ON, IT WILL CHANGE YOUR LIFE!!! It will only take a few minutes. You won't regret it!! $$ Dear Friend: Making over half million dollars every 4 to 5 months from your home for an investment of only $25 U.S. Dollars expense one time THANKS TO THE COMPUTER AGE AND THE INTERNET! === BE A MILLIONAIRE LIKE OTHERS WITHIN A YEAR !! Before you say Bull , please read the following. This is the letter you have been hearing about on the news lately. Due to the popularity of this letter on the internet, a national weekly news program recently devoted an entire show to the investigation of this program described below , to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are absolutely no laws prohibiting the participationin the program and if people can follow the simple instructions, they are bound to make some mega bucks with only $25 out of pocket cost. DUE TO THE RECENT INCREASE OF POPULARITY RESPECT THIS PROGRAM HAS ATTAINED, IT IS CURRENTLY WORKING BETTER THAN EVER. This is what one had to say: Thanks to this profitable opportunity. I was approached many times before but each time I passed on it. I am so glad I finally joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received total $ 610,470.00 in 21 weeks, with money still coming in. Pam Hedland, Fort Lee, New Jersey. - Here is another testimonial: This program has been around for a long time but I never believed in it. But one day when I received this again in the mail I decided to gamble my $25 on it. I followed the simple instructions and walaa . 3 weeks later the money started to come in. First month I only made $240.00 but the next 2 months after that I made a total of $290,000.00. So far, in the past 8 months by re-entering the program,I have made over $710,000.00 and I am playing it again. The key to success in this program is to follow the simple steps and NOT change anything . More testimonials later but first, ** PRINT THIS NOW FOR YOUR FUTURE REFERENCE *** $$$ If you would like to make at least $500,000 every 4 to 5 months easily and comfortably, please read the following...THEN READ IT AGAIN and AGAIN !!! $$$ FOLLOW THE SIMPLE INSTRUCTION BELOW AND YOUR FINANCIAL DREAMS WILL COME TRUE, GUARANTEED! INSTRUCTIONS: Order all 5 reports shown on the list below. For each report, send $5 CASH, THE NAME NUMBER OF THE REPORT YOU ARE ORDERING and YOUR E-MAIL ADDRESS to the person whose name appears ON THAT LIST next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE TOP LEFT CORNER in case of any mail problems. When you place your order, make sure you order each of the 5 reports. You will need all 5 reports so that you can save them on your computer and resell them. YOUR TOTAL COST $5 X 5 = $25.00. Within a few days you will receive, via e-mail, each of the 5 reports from these 5 different individuals. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. Also make a floppy of these reports and keep it on your desk in case something happen to your computer. .IMPORTANT - DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than what is instructedbelow in steps 1 through 6 or you will loose out on majority of your profits. Once you understand the way this works, you will also see how it does not work if you change it. Remember, this method has been tested, and if you alter, it will NOT work!!! People have tried to put their friends/relatives names on all five thinking they could get all the money. But it does not work this way. Believe us, we all have tried to be greedy and then nothing happened. So Do Not try to change anything other than what is instructed. Because if you do, it will not work for you. Remember, honesty reaps the reward!!! 1.. After you have ordered all 5 reports, take this advertisement and REMOVE the name address of the person in REPORT # 5. This person has made it through the cycle and is no doubt counting their fortune. 2 Move the name address in REPORT # 4 down TO REPORT # 5. 3 Move the name address in REPORT # 3 down TO REPORT # 4. 4 Move the name address in REPORT # 2 down TO REPORT # 3. 5 Move the name address in REPORT # 1 down TO REPORT # 2 6 Insert YOUR name address in the REPORT # 1 Position. PLEASE MAKE SURE you copy every name
[PHP-DEV] Bug #7015 Updated: Session.auto_start causes an error when generating PDFs with PDFlib
ID: 7015 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: *Session related Operating system: PHP Version: 4.0.1pl2 Assigned To: Comments: Is this still the case with php 4.0.5? I can't reproduce this with NS 4.76 on Linux with php 4.0.5 Previous Comments: --- [2000-10-04 11:02:19] [EMAIL PROTECTED] when switching on session.auto_start in php.ini, pdf output can't be viewed with acrobat reader on netscape browsers, but, it works fine with MS-Internet-Explorer (tested on Clinets on Linux, Windows-NT 4.0 SP6, Windows 98). starting the session manually with 'session_start()' works fine. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7015edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10691: PHP crashes when using ob_-functions
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.0.5
PHP Bug Type: Reproduceable crash
Bug description: PHP crashes when using ob_-functions
Using the following script, PHP 4.0.5 crashes under
Windows 2000:
?php
ob_start();
function foo($message = ) {
if ($message == )
exit;
}
foo();
ob_end_flush();
?
- Martin
--
Edit Bug report at: http://bugs.php.net/?id=10691edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7227 Updated: Incorrect values in phpinfo for error_*pend_string
ID: 7227 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: PHP options/info functions Operating system: PHP Version: 4.0.3 Assigned To: Comments: is this still the case with php 4.0.5 ? Previous Comments: --- [2000-11-23 05:00:25] [EMAIL PROTECTED] reclassify --- [2000-10-15 18:10:33] [EMAIL PROTECTED] In php.ini, I have: error_prepend_string = font color=ff error_append_string = /font and any error messages come up in red, but phpinfo() shows: error_append_string Off Off error_prepend_string Off Off --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7227edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7317 Updated: Configuring --with-sablot doesn't add --with-sablot to phpinfo()
ID: 7317 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: PHP options/info functions Operating system: PHP Version: 4.0.3pl1 Assigned To: Comments: Works fine for me, when I do ./buildconf; rm config.cache; make clean; ./configure ... Closing... Previous Comments: --- [2000-10-18 15:39:02] [EMAIL PROTECTED] The title says it all. Configure PHP with the --with-sablot flag, and it works fine (i.e. Sablotron support is configured in). However, do a phpinfo() and the --with-sablot flag is missing from the Configure Command section of phpinfo(), even though, further down, there is a section for Sablotron. - Colin --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7317edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7387 Updated: weird problems with unquoted array subscripts
ID: 7387 Updated by: derick Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Documentation problem Operating system: PHP Version: 4.0.3pl1 Assigned To: jmoore Comments: Any progress on this? Previous Comments: --- [2000-12-09 12:22:43] [EMAIL PROTECTED] James: Since you have a better idea of exactly what it is you want to document, I'm moving this to you. Close it whenever you think it is sufficently documented. --- [2000-11-17 11:17:15] [EMAIL PROTECTED] Maybe we should look at documenting how the engine corrects bad coding. We often get questions on #php about the engine correcting unquoted string constants and any other behaviour like this. I cant think of any others now but maybe a new chapter on debugging troublesome code or common errors etc is necessary in the manual. This might belong in the FAQ but I think a chapter in the docs wouldnt go amiss. Maybe another thing we should think about doing is including the FAQ in the manual as well as on php.net itself. --- [2000-10-24 04:44:00] [EMAIL PROTECTED] This is neither a bug in PHP, nor a doc bug...I will make the incompat entry more explicit as soon as I can get to the CVS, but you can see from the last comment what the problem is: you are using a predefined constant as a key in an assoc. array. This would be termed, at best, as undefined. --- [2000-10-22 19:45:09] [EMAIL PROTECTED] It won't work properly with any reserved word, which brings me back to the point : you should always quote constant strings. The only reason that it works at all is the parser is fixing your mistakes for you. If you set your error_reporting = E_ALL in your php.ini (and restart php), for the code $a[word] = foo; you'll see the warning Warning: Use of undefined constant word - assumed 'word' in /var/www/html/test2.php on line 3 I'll leave this issue open for someone from the documentation team to catch up with later. --- [2000-10-22 15:10:31] [EMAIL PROTECTED] moving to doc's problem, since it's clearly not engine bug but doc issue. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7387edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10323 Updated: 4.05-dev : non-html escaped strings on phpinfo
ID: 10323 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Function Specific Operating system: PHP Version: 4.0 Latest CVS (13/04/2001) Assigned To: Comments: Fixed in CVS. --Jani Previous Comments: --- [2001-04-13 23:10:28] [EMAIL PROTECTED] The PHPinfo() outputs data without running htmlspecialchars() For example: http://www.ispep.cx/phpinfo.php?scriptwindow.location='http://www.php.net';/script Keep up the great work, PHP is great! --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10323edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7227 Updated: Incorrect values in phpinfo for error_*pend_string
ID: 7227 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: PHP options/info functions Operating system: PHP Version: 4.0.3 Assigned To: Comments: Fixed in CVS now. --Jani Previous Comments: --- [2001-05-06 11:17:26] [EMAIL PROTECTED] is this still the case with php 4.0.5 ? --- [2000-11-23 05:00:25] [EMAIL PROTECTED] reclassify --- [2000-10-15 18:10:33] [EMAIL PROTECTED] In php.ini, I have: error_prepend_string = font color=ff error_append_string = /font and any error messages come up in red, but phpinfo() shows: error_append_string Off Off error_prepend_string Off Off --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7227edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7733 Updated: missing /ext/informix/php_informix.h
ID: 7733 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Informix related Operating system: PHP Version: 4.0.3pl1 Assigned To: Comments: Is this still the case with php 4.0.5? Previous Comments: --- [2000-11-27 07:13:01] [EMAIL PROTECTED] reclassify --- [2000-11-09 16:30:42] [EMAIL PROTECTED] I am tying to ./configure --with-informix=/usr1/informix and it come sout and tells me I am missing php_informix.h --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7733edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10241 Updated: php_flag dosn't work in httpd.conf, but it works in .htaccess files
ID: 10241 Updated by: sniper Reported By: [EMAIL PROTECTED] Status: Open Old-Bug Type: *Configuration Issues Bug Type: PHP options/info functions Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: one to be fixed before 4.0.6 Previous Comments: --- [2001-04-11 03:22:23] [EMAIL PROTECTED] Hi Yes, I do have the php options after the LoadModuleAddModule directives But I think it is wierd that it doesn't work in apache 1.3.14. Other modules like mod_rewrite manage to add directives that may be used in httpd.conf (RewriteEngine On is one example) I'll try to test with 1.3.19 after Easter. Best regards, vidar --- [2001-04-09 12:52:24] [EMAIL PROTECTED] This actually bit me yesterday. It seems that Apache hasn't retrived the new options from dynamically loaded modules at the time it parses the config file. Upgrading to Apache 1.3.19 solved it for me. Also make sure to place the php options after the LoadModuleAddModule directives in your config file. Please report if this solves your problem. --- [2001-04-09 08:45:06] [EMAIL PROTECTED] Hi Maybe I have missunderstud something but I thought that directives like php_value, php_flag, php_admin_value and php_admin_flag may be used in httpd.conf. This doesn't seem to be the case with php4.0.4pl1. I have tried it both in global, VirtualHost and in a directory section. It always cause this error message: # httpd -t Syntax error on line 1196 of /etc/httpd/conf/httpd.conf: Invalid command 'php_flag', perhaps mis-spelled or defined by a module not included in the server configuration I have php4 installed for sure Then I tried to put the statment in a .htaccess filephp_flag magic_quotes_gpc off Then it worked System is apache 1.3.14, php-4.0.4pl1, redhat6.2 and redhat7.0 ./configure --enable-ftp --with-xml --with-dom --enable-trans-sid --with-config-file-path=/etc/httpd --with-mysql --with-magic-quotes --with-apxs --with-ttf --with-qtdom --with-pgsql --with-gd --with-imap --includedir=/usr --with-openssl=/usr --enable-shmop --enable-sysvsem Best regards Vidar --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10241edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7878 Updated: intval base argument useless unless first arg is a string
ID: 7878
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Documentation problem
Operating system:
PHP Version: 4.0.3pl1
Assigned To:
Comments:
I guess no-one had thoughts about this. What are we going to do with this one?
Previous Comments:
---
[2000-11-19 00:55:06] [EMAIL PROTECTED]
The base argument for intval has no effect unless the first argument is a string.
I am not sure what the best fix for this is:
We could document that you should make the first argument a string to have the base
argument used.
We could convert the first argument to a string (using convert_to_string_ex) if there
is a second argument
That would mke calls made with base 10 would work as expected:
intval (1000, 11); // Returns 1331
intval ('1000', 11); // Returns 1331
However, calls using other bases might seem a bit odd:
intval ('077', 8); // returns 63
intval (077, 8); // returns 51
This would be because 077 is converted to 63, then the argument is converted to a
string.
Or we could add a warning if the first arg is not a string?
Any thoughts??
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7878edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7959 Updated: ld: 0711-317 ERROR: Undefined symbol: .alloca
ID: 7959 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: *Install and Config Operating system: PHP Version: 4.0.3pl1 Assigned To: Comments: Can you try this with PHP 4.0.5 and see if the problem still exists? Previous Comments: --- [2001-01-03 06:14:20] [EMAIL PROTECTED] I tried with php-4.0.4, but this new release do not fix the problem. --- [2000-11-24 05:52:55] [EMAIL PROTECTED] I have tried to install automake and autoconf (the last version) and the problem is still here. --- [2000-11-24 03:55:27] [EMAIL PROTECTED] I have the same problem as reported in the messsage #7809. (same configuration line, same error message). I use php-4.0.3pl1 on AIX 4.3.2 with IBM C compiler v. 4.4. I tried the fix from message #4630 but the problem remains. Automake and autoconf are not installed on the system. Thanks for the help. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7959edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10685 Updated: empty var in array_sum let php crash
ID: 10685 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: Arrays related Operating system: Windows 5.0 Build 2195 (win2k) PHP Version: 4.0.4pl1 Description: empty var in array_sum let php crash The problem has been solved in 4.0.5. Sorry for the inconvenience... Quinten Niens Previous Comments: --- [2001-05-05 17:27:59] [EMAIL PROTECTED] Works fine for me on Linux. Can you try the new 4.0.5 release and see if the problem is still there? --- [2001-05-05 16:55:09] [EMAIL PROTECTED] The output in my browser(IE 5.00.2920) is: CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: ERROR: could not get the task list --- [2001-05-05 16:51:14] [EMAIL PROTECTED] ? $array = ; $x = array_sum ($array); ? With this script , Windows will create an error: 'unknown has generated errors and will be closed by Windows. You will need to restart the program. An error log is being created.' The error log contains the folowing data: Access to performance data was denied to IUSR_WPWERKERS as attempted from C:WINNTSystem32drwtsn32.exe And Dr.Watson report: iexplore.exe c005 nosymbols (75B49454) c005 zend_hash_internal_pointer_reset_ex(1008C436) I'm sorry I don't know how to create a gdb backtrace in win2k. I hope I have giving enough information... Quinten Niens The Netherlands ps. Sorry for my bad english but I'm dutch... # Copy of php.ini # [PHP] ;;; ; About this file ; ;;; ; ; This is the 'optimized', PHP 4-style version of the php.ini-dist file. ; For general information about the php.ini file, please consult the php.ini-dist ; file, included in your PHP distribution. ; ; This file is different from the php.ini-dist file in the fact that it features ; different values for several directives, in order to improve performance, while ; possibly breaking compatibility with the standard out-of-the-box behavior of ; PHP 3. Please make sure you read what's different, and modify your scripts ; accordingly, if you decide to use this file instead. ; ; - allow_call_time_pass_reference = Off ; It's not possible to decide to force a variable to be passed by reference ; when calling a function. The PHP 4 style to do this is by making the ; function require the relevant argument by reference. ; - register_globals = Off ; Global variables are no longer registered for input data (POST, GET, cookies, ; environment and other server variables). Instead of using $foo, you must use ; $HTTP_POST_VARS[foo], $HTTP_GET_VARS[foo], $HTTP_COOKIE_VARS[foo], ; $HTTP_ENV_VARS[foo] or $HTTP_SERVER_VARS[foo], depending on which kind ; of input source you're expecting 'foo' to come from. ; - register_argc_argv = Off ; Disables registration of the somewhat redundant $argv and $argc global ; variables. ; - magic_quotes_gpc = Off ; Input data is no longer escaped with slashes so that it can be sent into ; SQL databases without further manipulation. Instead, you should use the ; function addslashes() on each input element you wish to send to a database. ; - variables_order = GPCS ; The environment variables are not hashed into the $HTTP_ENV_VARS[]. To access ; environment variables, you can use getenv() instead. ; Language Options ; engine = On ; Enable the PHP scripting language engine under Apache short_open_tag = On ; allow the ? tag. otherwise, only ?php and script tags are recognized. asp_tags= Off ; allow ASP-style % % tags precision = 14 ; number of significant digits displayed in floating point numbers y2k_compliance = Off ; whether to be year 2000 compliant (will cause problems with non y2k compliant browsers) output_buffering= Off ; Output buffering allows you to send header lines (including cookies) ; even after you send body content, in the price of slowing PHP's ; output layer a bit. ; You can enable output buffering by in runtime by calling the output ; buffering functions, or enable output buffering for all files ; by setting this directive to On. output_handler = ; You can redirect all of the output of your scripts to a function,
[PHP-DEV] Bug #6662 Updated: array keys of type real not allowed?
ID: 6662
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Closed
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.2
Assigned To:
Comments:
Fixed in the CVS - thanks for your report!
Previous Comments:
---
[2000-09-16 17:00:56] [EMAIL PROTECTED]
Float keys don't work, the variable gets converted to integer. This, however, doesn't
work with array initializers - this should be fixed.
---
[2000-09-11 22:06:25] [EMAIL PROTECTED]
It seems that array keys of type real are not allowed in class declaration:
class MyClass {
var $a = array( 1.5=1, 3.5=2, 7.5=5, 99=10);
...
}
Results in only one item 99=10 in array.
Above is accepted in PHP3.
Workaround:
var $a = array( '1.5'=1, '3.5'=2, '7.5'=5, '99'=10);
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6662edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7342 Updated: Different config-op parsing in php.ini and http.conf
ID: 7342 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Analyzed Status: Closed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.3pl1 Assigned To: Comments: This is the intended behavior. The special notations that are supported in php.ini are features of the php.ini parser, and thus, are not available in other configuration options, such as ini_set() or httpd.conf. Previous Comments: --- [2001-01-09 23:35:55] [EMAIL PROTECTED] The same applies to the php function ini_set(). It looks like the onmodify entry is being not found/called from zend_alter_ini_entry and it's using the 'estrndup/value=duplicate' instead --- [2000-10-19 11:20:06] [EMAIL PROTECTED] In php.ini for setting the upload_max_filesize one can use abbrevations for certain amounts of bytes (e.g. M for 'Megabytes'). The line upload_max_filesize = 15M means 15 * 1024 * 1024 Bytes are allowed. When using the php_value upload_max_filesize 15M directive in apache httpd.conf the 'M' modifyer is *NOT* used, leading to actually setting the max. file size for uploads to only 15 Bytes, not 15 MB. One has to use 15728640 (i.e. 15 * 1024^2) to set the value to 15 MB. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7342edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #5653 Updated: with setcookie(), only the last cookie is written
Date sent: 6 May 2001 14:45:57 - To: [EMAIL PROTECTED] Subject:Bug #5653 Updated: with setcookie(), only the last cookie is written From: Bug Database [EMAIL PROTECTED] ID: 5653 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Other web server Operating system: PHP Version: 4.0 Release Candidate 2 Assigned To: Comments: is this still the case with the latest 4.0.5 release? Hi, I tried to figure out today why this behaviour occurs. I only can say this: it's not the problem of the roxen-module (php4.pike) -- this is the server-sided-module it's generally a bug in the roxen sapi; this problem is also adsend if you don't use a command like this header(set-cookie: cookie[2]=value) ... and so on.. If you try to do this, you get the same result : only the last cookie you set, you can see in your php-script. = I'm very sad i'm not the guru to debug the php-roxen-sapi- module ... Previous Comments: -- - [2000-10-30 09:40:14] [EMAIL PROTECTED] reclassified. -- - [2000-09-14 16:33:52] [EMAIL PROTECTED] This behaviour is still visible in PHP 4.0.2 with Roxen (pike 7.0.58). -- - [2000-08-17 16:19:50] [EMAIL PROTECTED] This is not a session-related issue. Reclassifying. -- - [2000-08-15 16:04:24] [EMAIL PROTECTED] seems to be another error related to roxen sapi and cookies ... PS: bug report form should have a sapi input field -- - [2000-08-15 15:57:06] [EMAIL PROTECTED] user feedback: Yes, I tried the latest snapshot from 15.Aug.2000. But the Result is still the same. Maybe you can give me a hint how to give a trace or debug a certain part of php4 -- - The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5653edit=2 mfG B. Schulte - ___ /\/ / \ / -- DELTA 7 -- / - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10681 Updated: Fix for #9698 breaks more than it fixes
ID: 10681 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Network related Operating system: PHP Version: 4.0 Latest CVS (05/05/2001) Assigned To: Comments: Sounds ok to me, are you willing to make a patch for this? Previous Comments: --- [2001-05-05 04:40:03] [EMAIL PROTECTED] ?php $ipaslong = ip2long(208.247.106.187); print long2ip($ipaslong).n; print bin2hex(pack(N, $ipaslong)).n; ? That script run with PHP 4.0.5 prints: 208.247.106.187 d0f76abb whereas with the latest CVS version it prints: 127.255.255.255 7fff That makes that function completely unusable for me (and for others probably too). I have another proposal for fixing bug #9698, and that is implementing %u as a sprintf format specifier to output unsigned longs instead of signed. This way he could use the following script for his problem (should go onto the ip2long page then): ?php $ip = gethostbyname(www.php.net); $out = sprintf(http://%u/brn, ip2long($ip)); echo $out; ? If that fix would be accepted (and the other fix rolled back), I could add %u to sprintf myself and post it here. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10681edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10643 Updated: PHP 4.0.5 linked against openldap 2.x segfaults on Apache startup
ID: 10643
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: LDAP related
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
This might be the infamous pthread lib / glibc bug.
Is your Apache linked with pthread?
If not, check the instructions how to do it on
www.php.net/oci8
(I know, it's Oracle manual page..:)
--Jani
Previous Comments:
---
[2001-05-03 14:06:27] [EMAIL PROTECTED]
My configure string:
./configure --prefix=/software/php-4 --with-apxs=/software/apache-1.3/bin/apxs
--with-gdbm --with-ldap=/software/openldap-2 --with-pgsql=/software/postgresql-7
--with-config-file-path=/software/php-4/lib
Using OpenLDAP 2.0.7 and PostgreSQL 7.1 on a SuSE 6.4 box.
# ldd libphp4.so
libpam.so.0 = /lib/libpam.so.0 (0x40144000)
libdl.so.2 = /lib/libdl.so.2 (0x4014c000)
libpq.so.2 = /software/postgresql-7/lib/libpq.so.2 (0x4015)
libldap.so.2 = /software/openldap-2/lib/libldap.so.2 (0x4015f000)
liblber.so.2 = /software/openldap-2/lib/liblber.so.2 (0x40249000)
libgdbm.so.2 = /usr/lib/libgdbm.so.2 (0x40256000)
libresolv.so.2 = /lib/libresolv.so.2 (0x4025e000)
libm.so.6 = /lib/libm.so.6 (0x4026d000)
libcrypt.so.1 = /lib/libcrypt.so.1 (0x4028a000)
libnsl.so.1 = /lib/libnsl.so.1 (0x402b7000)
libc.so.6 = /lib/libc.so.6 (0x402ce000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000)
Here is an strace of an Apache child that died. I'm using NSS_LDAP and PAM_LDAP.
open(/lib/libpthread.so.0, O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0755, st_size=289663, ...}) = 0
read(4, 177ELF111
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10617 Updated: DSO won't load
ID: 10617 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Apache related Operating system: PHP Version: 4.0.5 Assigned To: Comments: Does this happen also with the latest CVS? Try a snapshot from http://snaps.php.net/ --Jani Previous Comments: --- [2001-05-02 15:38:40] [EMAIL PROTECTED] I configured PHP with the following: ./configure --with-apxs=/www/server/apache/bin/apxs --with-yaz=/www/src/yaz-1.6 --with-sybase=/usr/local/sybase/client --with-xml --enable-ftp --with-gd=/www/src/gd1.2 --disable-pear --with-dbase --enable-libgcc --enable-freetype-4bit-antialias-hack --with-pdflib=/www/src/pdflib-3.03 --with-tiff-dir=/www/src/tiif-v3.4 --with-png-dir=/www/src/libpng-1.0.9 --enable-sockets --with-zlib-dir=/www/src/zlib-1.1.3 --enable-versioning --enable-libgcc and all goes well through the make process. However when I got to restart Apache (1.3.09) I get the following error: Syntax error on line 233 of /www/server/apache/conf/httpd.conf: Cannot load /www/server/apache/libexec/libphp4.so into server: ld.so.1: /www/server/apache /bin/httpd: fatal: relocation error: file /www/server/apache/libexec/libphp4.so: symbol hstrerror: referenced symbol not found When I do an ldd for the libphp4.so I get the following: ldd libphp4.so libpam.so.1 = /usr/lib/libpam.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libsybdb.so = /usr/lib/libsybdb.so libresolv.so.2 =/usr/lib/libresolv.so.2 libm.so.1 = /usr/lib/libm.so.1 libc.so.1 = /usr/lib/libc.so.1 libmp.so.2 =/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10617edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9436 Updated: SUN_LEN and hstrerror undefined
ID: 9436 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Sockets related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Does this happen with the latest CVS? Try a snapshot from http://snaps.php.net/ --Jani Previous Comments: --- [2001-02-24 11:09:14] [EMAIL PROTECTED] Apache with PHP module does not start with following error: root@car:/lhome/lex/src/php-4.0.4pl1 /opt/apache/bin/apachectl start /usr/lib/dld.sl: Unresolved symbol: SUN_LEN (code) from /opt/apache/libexec/libphp4.sl /usr/lib/dld.sl: Unresolved symbol: hstrerror (code) from /opt/apache/libexec/libphp4.sl Syntax error on line 238 of /opt/apache/conf/httpd.conf: Cannot load /opt/apache/libexec/libphp4.sl into server: No such file or directory /opt/apache/bin/apachectl start: httpd could not be started PHP was compiled with following parameters: CFLAGS=-O2 LDFLAGS=-lcl -lpthread ./configure --with-apxs=/opt/apache/bin/apxs --with-config-file-path=/opt/php/conf --with-exec-dir=/opt/apache/cgi-bin --enable-calendar --with-zlib-dir=/opt/zlib --enable-ftp --enable-gd-imgstrttf --with-gd=/opt/gd --with-jpeg-dir=/opt/jpeg-6 --with-xpm-dir=/opt/xpm --with-ttf=/opt/freetype --with-oci8=/d/db01/app/oracle/product/8.0.6 --with-zlib-dir=/opt/zlib --enable-sockets --enable-sysvsem --enable-sysvshm --enable-yp --with-zlib=/opt/zlib --enable-inline-optimization --enable-memory-limit --prefix=/opt/php --with-png-dir=/opt/libpng --with-gettext=/opt/gettext --without-mysql --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9436edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10608 Updated: Don't read max_execution_time value in php.ini
ID: 10608 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: PHP options/info functions Operating system: PHP Version: 4.0.5 Assigned To: Comments: Works for me just fine with latest CVS. Try a snapshot from http://snaps.php.net/ --Jani Previous Comments: --- [2001-05-02 08:56:04] [EMAIL PROTECTED] I work with php in command line : php -c php.ini dir -f filename Command script exit with message : Profiling timer expired This bug I look after migrate from 4.0.4pl1 to 4.0.5 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10608edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10602 Updated: $HTTP_POST_FILES doesn't work properly
ID: 10602 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: HTTP related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: If this doesn't work with PHP 4.0.5, reopen this bug report. This should be fixed in it so please update. --Jani Previous Comments: --- [2001-05-02 04:51:47] [EMAIL PROTECTED] for upload of 3 images from POST form it gives me nothing (even no error message): echo $HTTP_POST_FILES['name'][0]; echo $HTTP_POST_FILES['name'][1]; echo $HTTP_POST_FILES['name'][2]; echo $HTTP_POST_FILES['type'][0]; echo $HTTP_POST_FILES['type'][1]; echo $HTTP_POST_FILES['type'][2]; echo $HTTP_POST_FILES['tmp_name'][0]; echo $HTTP_POST_FILES['tmp_name'][1]; echo $HTTP_POST_FILES['tmp_name'][2]; echo $HTTP_POST_FILES['size'][0]; echo $HTTP_POST_FILES['size'][1]; echo $HTTP_POST_FILES['size'][2]; even like - echo $HTTP_POST_FILES['name'][0]; --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10602edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10241 Updated: php_flag dosn't work in httpd.conf, but it works in .htaccess files
ID: 10241 Updated by: rasmus Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: PHP options/info functions Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: I don't see a PHP fix here. It is either a user error or an Apache-1.3.14 specific bug. The php_value, etc. directives certainly work fine in httpf.conf. Previous Comments: --- [2001-05-06 11:30:06] [EMAIL PROTECTED] one to be fixed before 4.0.6 --- [2001-04-11 03:22:23] [EMAIL PROTECTED] Hi Yes, I do have the php options after the LoadModuleAddModule directives But I think it is wierd that it doesn't work in apache 1.3.14. Other modules like mod_rewrite manage to add directives that may be used in httpd.conf (RewriteEngine On is one example) I'll try to test with 1.3.19 after Easter. Best regards, vidar --- [2001-04-09 12:52:24] [EMAIL PROTECTED] This actually bit me yesterday. It seems that Apache hasn't retrived the new options from dynamically loaded modules at the time it parses the config file. Upgrading to Apache 1.3.19 solved it for me. Also make sure to place the php options after the LoadModuleAddModule directives in your config file. Please report if this solves your problem. --- [2001-04-09 08:45:06] [EMAIL PROTECTED] Hi Maybe I have missunderstud something but I thought that directives like php_value, php_flag, php_admin_value and php_admin_flag may be used in httpd.conf. This doesn't seem to be the case with php4.0.4pl1. I have tried it both in global, VirtualHost and in a directory section. It always cause this error message: # httpd -t Syntax error on line 1196 of /etc/httpd/conf/httpd.conf: Invalid command 'php_flag', perhaps mis-spelled or defined by a module not included in the server configuration I have php4 installed for sure Then I tried to put the statment in a .htaccess filephp_flag magic_quotes_gpc off Then it worked System is apache 1.3.14, php-4.0.4pl1, redhat6.2 and redhat7.0 ./configure --enable-ftp --with-xml --with-dom --enable-trans-sid --with-config-file-path=/etc/httpd --with-mysql --with-magic-quotes --with-apxs --with-ttf --with-qtdom --with-pgsql --with-gd --with-imap --includedir=/usr --with-openssl=/usr --enable-shmop --enable-sysvsem Best regards Vidar --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10241edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #5653 Updated: with setcookie(), only the last cookie is written
ID: 5653 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Other web server Operating system: Linux PHP Version: 4.0 Release Candidate 2 Description: with setcookie(), only the last cookie is written This bug is still present in 4.0.5. Previous Comments: --- [2001-05-06 12:31:46] [EMAIL PROTECTED] This bug is still present in 4.0.5. --- [2000-10-30 09:40:14] [EMAIL PROTECTED] reclassified. --- [2000-09-14 16:33:52] [EMAIL PROTECTED] This behaviour is still visible in PHP 4.0.2 with Roxen (pike 7.0.58). --- [2000-08-17 16:19:50] [EMAIL PROTECTED] This is not a session-related issue. Reclassifying. --- [2000-08-15 16:04:24] [EMAIL PROTECTED] seems to be another error related to roxen sapi and cookies ... PS: bug report form should have a sapi input field --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=5653 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] Zend API changes
On Sun, 6 May 2001, James Moore wrote: You're not wrong; It's been done and published (http://www.zend.com/apidoc/), and is the base for additional work that I invited people to improve on. Hey, are the sources for this manual available somewhere? CVS maybe? Yep, sure thing; cvs.zend.com, co ZendAPI; Released under OPL, and written in the same formats everyone in here's used to work with :) At the moment its all one big XML file, would anyone object to me splitting it up into more manageable chunks like we do with phpdoc etc? PLEASE DO! (And don't forget to subscribe to the engine-api-doc mailing list). We need discussed cleaning up the xml (yes, I have nerve, don't at all feel obligated ;), to conform to phpdoc style a while ago, but no one ever found the patience... ;) -Sterling - James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #8834 Updated: crypt() starts from not random salt
ID: 8834 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Encryption and hash functions Operating system: PHP Version: 4.0 Latest CVS (22/01/2001) Assigned To: Comments: This should be fixed in CVS now. Please try it out. Reopen if still not random.. --Jani Previous Comments: --- [2001-04-05 16:03:09] [EMAIL PROTECTED] here you are: Solaris 2.4: # grep RAND main/php_config.h #define HAVE_LRAND48 1 #define HAVE_RAND_R 1 /* #undef HAVE_RANDOM */ #define HAVE_SRAND48 1 /* #undef HAVE_SRANDOM */ # uname -a SunOS helios 5.4 Generic_101945-60 sun4d sparc # Solaris 2.6 # grep RAND main/php_config.h #define HAVE_LRAND48 1 #define HAVE_RAND_R 1 #define HAVE_RANDOM 1 #define HAVE_SRAND48 1 #define HAVE_SRANDOM 1 # uname -a SunOS uranos 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-4 # unfortunately I'm not able to discuss the solution, although I can test the one provided :-)), thank you --- [2001-04-05 15:14:41] [EMAIL PROTECTED] here you are: Solaris 2.4: # grep RAND main/php_config.h #define HAVE_LRAND48 1 #define HAVE_RAND_R 1 /* #undef HAVE_RANDOM */ #define HAVE_SRAND48 1 /* #undef HAVE_SRANDOM */ # uname -a SunOS helios 5.4 Generic_101945-60 sun4d sparc # Solaris 2.6 # grep RAND main/php_config.h #define HAVE_LRAND48 1 #define HAVE_RAND_R 1 #define HAVE_RANDOM 1 #define HAVE_SRAND48 1 #define HAVE_SRANDOM 1 # uname -a SunOS uranos 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-4 # unfortunately I'm not able to discuss the solution, although I can test the one provided :-)), thank you --- [2001-04-05 14:57:44] [EMAIL PROTECTED] This is most likely a Solaris specific issue as I can't reproduce this on Linux. Can you please include the output of this command in both Solaris 2.4 and 2.6 (in php4): # grep RAND main/php_config.h It might be that in both of those system the seed generator found is srand() which isn't so good as srandom() is. But I also found (with google :) that srandom() might not be that good either (in Solaris) so that leaves us with a problem. One solution might be that we run php_srand() in RINIT instead of MINIT when Solaris is used. --Jani --- [2001-01-22 06:05:34] [EMAIL PROTECTED] PHP compiled as Apache module. Look like crypt() starts from not random salt. In case of my Solaris 2.4, first crypt() call always generates string starting from IH. In case of Solaris 2.6 it always starts from C.. Looks like in every instantiation of new Apache process PHP starts crypt from the same salt value. In the same process next crypt() calls look like they generate random strings, though. But next process restarts with the same value. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8834edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10595 Updated: source typos in internal_functions.c
ID: 10595 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Compile Problem Operating system: PHP Version: 4.0.5 Assigned To: Comments: Should be fixed in CVS. Try latest snapshot from http://snaps.php.net/ and reopen if it still not works. --Jani Previous Comments: --- [2001-05-02 01:04:41] [EMAIL PROTECTED] in main/internal_functions.c: line32 has n's instead of line breaks between #includes /bin/sh /Users/cgclark/php-4.0.5/libtool --silent --mode=compile cc -I. -I/Users/cgclark/php-4.0.5/main -I/Users/cgclark/php-4.0.5/main -I/Users/cgclark/php-4.0.5 -I/usr/include/httpd -I/Users/cgclark/php-4.0.5/Zend -I/Users/cgclark/php-4.0.5/ext/mysql/libmysql -I/Users/cgclark/php-4.0.5/ext/xml/expat/xmltok -I/Users/cgclark/php-4.0.5/ext/xml/expat/xmlparse -I/Users/cgclark/php-4.0.5/TSRM -traditional-cpp -DDARWIN -DUSE_HSREGEX -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=21 -g -O2 -c internal_functions.c internal_functions.c:32: `#include' expects FILENAME or FILENAME make[2]: *** [internal_functions.lo] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10595edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10681 Updated: Fix for #9698 breaks more than it fixes
ID: 10681 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Network related Operating system: Linux PHP Version: 4.0 Latest CVS (05/05/2001) Description: Fix for #9698 breaks more than it fixes Sure. Here it is: http://global.team17.com/php4-unsigned.patch Works for both printf and sprintf. Is there another function I missed? Previous Comments: --- [2001-05-06 12:00:05] [EMAIL PROTECTED] Sounds ok to me, are you willing to make a patch for this? --- [2001-05-05 04:40:03] [EMAIL PROTECTED] ?php $ipaslong = ip2long(208.247.106.187); print long2ip($ipaslong).n; print bin2hex(pack(N, $ipaslong)).n; ? That script run with PHP 4.0.5 prints: 208.247.106.187 d0f76abb whereas with the latest CVS version it prints: 127.255.255.255 7fff That makes that function completely unusable for me (and for others probably too). I have another proposal for fixing bug #9698, and that is implementing %u as a sprintf format specifier to output unsigned longs instead of signed. This way he could use the following script for his problem (should go onto the ip2long page then): ?php $ip = gethostbyname(www.php.net); $out = sprintf(http://%u/brn, ip2long($ip)); echo $out; ? If that fix would be accepted (and the other fix rolled back), I could add %u to sprintf myself and post it here. --- Full Bug description available at: http://bugs.php.net/?id=10681 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10599 Updated: background attribute in the body tag causes a double insert
ID: 10599 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: MySQL related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Actually, it's a bug in your HTML (although you did confuse me for a few minutes...) The attribute you're looking for is bgcolor; background loads a background image, and expects a URL argument. When you feed it with #FF, it tries to access http://www.dukemarket.com/bug.php#FF to load it as a background image, access the page again, and causes a second insert. It was a good challenge though :) Previous Comments: --- [2001-05-02 03:45:48] [EMAIL PROTECTED] I have documented the problem at a href=http://www.dukemarket.com/bug.php;http://www.dukemarket.com/bug.php/a. If you have any questions, email me at a href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10599edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9050 Updated: strtotime function work incorrect
ID: 9050 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Assigned Bug Type: Date/time related Operating system: PHP Version: 4.0.4pl1 Assigned To: derick Comments: Previous Comments: --- [2001-02-01 10:18:45] [EMAIL PROTECTED] My script get ftp_rawlit from ftp site. For each file I parse returned string and try convert string representation of date into timestamp: Oct 13 1999 -1002991140 Oct 14 1999 -1003077540 Sep 28 1999 -1001695140 Sep 29 1999 -1001781540 Jan 19 2000 -979923600 Dec 21 12:16 -1008926160 Aug 30 12:12 -999159120 What's wrong? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9050edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9640 Updated: strtotime() cannot properly handle some ISO 8601-compliant strings
ID: 9640 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Assigned Bug Type: Date/time related Operating system: PHP Version: 4.0.4pl1 Assigned To: derick Comments: Previous Comments: --- [2001-03-08 17:26:17] [EMAIL PROTECTED] I've recently run into a problem. This problem has been addressed in bug report #9007, but I thought I would try to provide more detailed information. First, I'm pulling ISO 8601-compliant date strings from a PostgreSQL 7.0.3 database. We'll illustrate this bug with a sample date: 1999-06-24 00:01:00-05. Or June 24, 1999, 12:01 AM CDT. $timestamp = 1999-06-24 00:01:00-05; $timestamp = strtotime($timestamp); print(strftime(%A, %B %d, %Y %H:%M %Z, $timestamp)); Now, that output /should/ read Thursday, June 24, 1999 00:01 CDT, instead it reads Wednesday, June 23, 1999 19:06 CDT. Even though PHP knows the timezone of the machine to be CST6CDT, it subtracts 5 hours from the time during conversion, regardless. This is a Bad Thing(tm) because all programs should be ISO 8601-compliant. Currently PHP4 is a lil' broken. This should be fixed in the next release of PHP4, IMHO. The bug probably actually resides in the code in ext/standard/parsedate.c that is borrowed from GNU Bison 1.28. So maybe this bug should be reported to GNU's bug list as well. In any case, here's a fix in the meantime... If using PostgreSQL issue the command SET DATESTYLE TO Postgres; in all of your queries that return a timestamp. That will cause the timestamp to be returned in this style: Thu Jun 24 00:01:00 1999 CDT. This style will correctly parse, as we will illustrate with this example: $timestamp = Thu Jun 24 00:01:00 1999 CDT; $timestamp = strtotime($timestamp); print(strftime(%A, %B %d, %Y %H:%M %Z, $timestamp)); The output of this example is Thursday, June 24, 1999 00:01 CDT, which is correct. And that's all. Derek P. Moore [EMAIL PROTECTED] --- [2001-03-08 17:16:14] [EMAIL PROTECTED] I've recently run into a problem. This problem has been addressed in bug report #9007, but I thought I would try to provide more detailed information. First, I'm pulling ISO 8601-compliant date strings from a PostgreSQL 7.0.3. We'll illustrate this bug with a sample date: 1999-06-24 00:01:00-05. Or June 24, 1999, 12:01 AM CDT. $timestamp = 1999-06-24 00:01:00-05; $timestamp = strtotime($timestamp); print(strftime(%A, %B %d, %Y %H:%M %Z, $timestamp)); Now, that output /should/ read Thursday, June 24, 1999 00:01 CDT, instead it reads Wednesday, June 23, 1999 19:06 CDT. Even though PHP knows the timezone of the machine to be CST6CDT, it subtracts 5 hours from the time during conversion, regardless. This is a Bad Thing(tm) because all programs should be ISO 8601-compliant. Currently PHP4 is a lil' broken. This should be fixed in the next release of PHP4, IMHO. The bug probably actually resides in the code in ext/standard/parsedate.c that is borrowed from GNU Bison 1.28. So maybe this bug should be reported to GNU's bug list as well. In any case, here's a fix in the meantime... If using PostgreSQL issue the command SET DATESTYLE TO Postgres; in all of your queries that return a timestamp. That will cause the timestamp to be returned in this style: Thu Jun 24 00:01:00 1999 CDT. This style will correctly parse, as we will illustrate with this example: $timestamp = Thu Jun 24 00:01:00 1999 CDT; $timestamp = strtotime($timestamp); print(strftime(%A, %B %d, %Y %H:%M %Z, $timestamp)); The output of this example is Thursday, June 24, 1999 00:01 CDT, which is correct. And that's all. Derek P. Moore [EMAIL PROTECTED] --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9640edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] default location of php.ini changed?
Sorry if this has already been dealt with, but I just got bit on the ass pretty hard and there's nothing in the bug db about it... the default location for php.ini has been /usr/local/lib for as long as I can recall. An install of a snapshot from this morning puts the default location as /usr/local/etc Was this intended? Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] default location of php.ini changed?
At 20:54 6/5/2001, Mike Robinson wrote: Sorry if this has already been dealt with, but I just got bit on the ass pretty hard and there's nothing in the bug db about it... the default location for php.ini has been /usr/local/lib for as long as I can recall. An install of a snapshot from this morning puts the default location as /usr/local/etc Was this intended? No it wasn't; Guys, wasn't this changed back? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Removing 4.0.6 branch; Rebranch target: Thursday
As the subject suggests, because of the large amount of bug fixes that flowed and are still flowing in, we're canceling the 4.0.6 branch for now. The new target day is (this) Thursday, so do your best to submit all bug fixes by then. Thanks, Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend API changes
I feel like a TFI :( I apologize for my ignorance. However, with the time I do have to follow the dev list, it is not apparent to me the structure being imposed on the underlying system. - Original Message - From: Sean R. Bright [EMAIL PROTECTED] To: 'Billy Rose' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, May 04, 2001 7:26 PM Subject: RE: [PHP-DEV] Zend API changes Billy: Meet the QA team :) [EMAIL PROTECTED] -Original Message- From: Billy Rose [mailto:[EMAIL PROTECTED]] Sent: Friday, May 04, 2001 7:53 PM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Zend API changes It is obvious that this project has a tremendous amount of effort from many people. Would it make sense to have someone, or a small group of people, whose task is to handle all of the release / testing issues? They would be handed over a release candidate from the development group to test and collect reports on. They then verify and classify all bugs and send reports back to the development team on a pre-determined time schedule, i.e. every 4 hours or such. As the test person / group collects reports, the development team works on new features / already known issues. Once new issues are reported, they are fixed and marked off the report list. After the release candidate is declared stable, it is put out there. This keeps the burden of trying to maintain a bug list, and deal with release issues off of the main pipeline of the development team. What do you think? - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Billy Rose [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 04, 2001 6:33 PM Subject: Re: [PHP-DEV] Zend API changes You can always suggest... :) At 02:14 5/5/2001, Billy Rose wrote: The company I work for has a very quick bug turn over rate. I was wondering if I may make a few suggestions concerning release issues / bugtracking? - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Hartmut Holzgraefe [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 04, 2001 1:27 PM Subject: Re: [PHP-DEV] Zend API changes At 21:05 4/5/2001, Hartmut Holzgraefe wrote: PS: about the welcome thing above ... - you should know that i have put a lot of work into the manual (both english and german) and the function tables Hartmut, I wasn't trying to understate your work on the manual; I told you personally that the function reference mechanism that you build was very impressive and useful. I wasn't being sarcastic when I invited you (and anyone else) to help document the Zend API. I know I won't be getting around to doing it in the near future, so if nobody else does it, it'll simply remain undone. - afair there was someone who started to write a 'extension building manual' or something about a year ago and it was you , Zeev, who told him that this was useless effort as this was already beeing taken care off (without pointing him to this project or inviting him to join it) correct me if i'm wrong as i do not have found this posting in my archives yet You're not wrong; It's been done and published (http://www.zend.com/apidoc/), and is the base for additional work that I invited people to improve on. Zeev -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Libtool 1.4 problems..
This is what I get now: --- Making all in Zend make[1]: Entering directory `/usr/src/web/php/php4/Zend' flex -Pzend -ozend_language_scanner.c -i ./zend_language_scanner.l bison -y -p zend -v -d ./zend_language_parser.y -o zend_language_parser.c /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -DLINUX=22 -DMOD_SSL=208100 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -Wall -c zend_language_scanner.c libtool: ltconfig version `' does not match ltmain.sh version `1.3.5' Fatal configuration error. See the libtool docs for more information. make[1]: *** [zend_language_scanner.lo] Error 1 make[1]: Leaving directory `/usr/src/web/php/php4/Zend' make: *** [all-recursive] Error 1 Like I told before, the version detection is not enough.. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #9050 Updated: strtotime function work incorrect
ID: 9050 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Assigned Status: Closed Bug Type: Date/time related Operating system: PHP Version: 4.0.4pl1 Assigned To: derick Comments: The Jan 13 2000 date format is now corectly recognised. Previous Comments: --- [2001-04-29 12:04:49] [EMAIL PROTECTED] This still occurs with php 4.0.5RC6 --- [2001-02-01 10:18:45] [EMAIL PROTECTED] My script get ftp_rawlit from ftp site. For each file I parse returned string and try convert string representation of date into timestamp: Oct 13 1999 -1002991140 Oct 14 1999 -1003077540 Sep 28 1999 -1001695140 Sep 29 1999 -1001781540 Jan 19 2000 -979923600 Dec 21 12:16 -1008926160 Aug 30 12:12 -999159120 What's wrong? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9050edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7878 Updated: intval base argument useless unless first arg is a string
ID: 7878
Updated by: zak
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: Documentation problem
Operating system:
PHP Version: 4.0.3pl1
Assigned To: zak
Comments:
In hindsight, I think that the current behavior is fine and makes sense given how PHP
currently behaves.
People just need to remember that writing a number out in a different base is for
their convenience - PHP sees it as its decimal equivalent and behaves appropriately.
I have assigned it to myself so that it will bug me til I get around to documenting
the behavior.
Previous Comments:
---
[2001-05-06 11:31:04] [EMAIL PROTECTED]
I guess no-one had thoughts about this. What are we going to do with this one?
---
[2000-11-19 00:55:06] [EMAIL PROTECTED]
The base argument for intval has no effect unless the first argument is a string.
I am not sure what the best fix for this is:
We could document that you should make the first argument a string to have the base
argument used.
We could convert the first argument to a string (using convert_to_string_ex) if there
is a second argument
That would mke calls made with base 10 would work as expected:
intval (1000, 11); // Returns 1331
intval ('1000', 11); // Returns 1331
However, calls using other bases might seem a bit odd:
intval ('077', 8); // returns 63
intval (077, 8); // returns 51
This would be because 077 is converted to 63, then the argument is converted to a
string.
Or we could add a warning if the first arg is not a string?
Any thoughts??
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7878edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Win32 build broken, again
parsedate.y contains 14 shift/reduce conflicts. basic_functions.c D:\Programme\MS Visual Studio\Projekte\php\php4\ext\standard\basic_functions.c(8 41) : warning C4013: 'php_rinit_crypt' undefined; basic_functions.obj : error LNK2001: Not resolved external symbol _php_rini t_crypt -- sebastian bergmann[EMAIL PROTECTED] http://www.sebastian-bergmann.de bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Libtool 1.4 problems..
On Sun, 6 May 2001, Jani Taskinen wrote: This is what I get now: --- Making all in Zend make[1]: Entering directory `/usr/src/web/php/php4/Zend' flex -Pzend -ozend_language_scanner.c -i ./zend_language_scanner.l bison -y -p zend -v -d ./zend_language_parser.y -o zend_language_parser.c /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../main -DLINUX=22 -DMOD_SSL=208100 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -Wall -c zend_language_scanner.c libtool: ltconfig version `' does not match ltmain.sh version `1.3.5' Fatal configuration error. See the libtool docs for more information. Thanks for notifying us. I've taken appropiate steps to accomodate this special check in libtool 1.4. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Win32 build broken, again
On Sun, 6 May 2001, Sebastian Bergmann wrote: parsedate.y contains 14 shift/reduce conflicts. That is correct, forog to bumb the number up I guess :) Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10692: The function imagecreatefromwbmp() return an error: not a valid WBMP file
From: [EMAIL PROTECTED] Operating system: SUSE 7.0 PHP version: 4.0.5 PHP Bug Type: GD related Bug description: The function imagecreatefromwbmp() return an error: not a valid WBMP file ? $bmp_file = test.bmp; $im = imagecreatefromwbmp($bmp_file); $im2 = imagejpeg($im,'test.jpg','100'); echo img src=\test.jpg\; ? --- My PHP Configuration: ./configure --with-apxs --with-mysql --enable-ftp -enable-bcmath --with-gd --with-jpeg-dir=/usr/local --with-xpm-dir Installed GD Version 1.8.4 Installed jpeg-6b I hope someone can help me! I really need this function! Thanks, Haif -- Edit Bug report at: http://bugs.php.net/?id=10692edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10692 Updated: The function imagecreatefromwbmp() return an error: not a valid WBMP file
ID: 10692 Updated by: derick Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: GD related Operating system: PHP Version: 4.0.5 Assigned To: Comments: A (windows) BMP file is NOT an WBMP file. WBMP files are used for WAP site AFAIK. Previous Comments: --- [2001-05-06 20:54:23] [EMAIL PROTECTED] ? $bmp_file = test.bmp; $im = imagecreatefromwbmp($bmp_file); $im2 = imagejpeg($im,'test.jpg','100'); echo img src=test.jpg; ? --- My PHP Configuration: ./configure --with-apxs --with-mysql --enable-ftp -enable-bcmath --with-gd --with-jpeg-dir=/usr/local --with-xpm-dir Installed GD Version 1.8.4 Installed jpeg-6b I hope someone can help me! I really need this function! Thanks, Haif --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10692edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10676 Updated: sybase_connect
ID: 10676 Updated by: joey Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Sybase-ct (ctlib) related Operating system: PHP Version: 4.0.5 Assigned To: Comments: What version of the Sybase CT Libs are you using here? In Sybase Common-Library/11.1.1/P/Linux, the net_close symbol has been changed to syb_net_close. IIRC, the bug here is simply that both the IMAP lib and Sybase libs have the symbol net_close. Pretty sure it's not a PHP bug. If I'm wrong, we can reopen it. If I'm right, you simply need to obtain newer sybase-ct libs. Previous Comments: --- [2001-05-04 15:31:14] [EMAIL PROTECTED] We've been having problems with this since php 4.0.3. Here is a full backtrace of a running (not for long) httpd child that dies as soon as sybase_connect is called. You'll notice the segfault complains at mail.c. Since sybase has nothing to do with this file, I'm guessing there's a crosslink somewhere in the PHP code, or a pointer that is getting lost somewhere. --- Attaching to program: /usr/sbin/httpd, Pid 4719 Reading symbols from /lib/libpam.so.0...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /home/sybase/lib/libinsck.so...done. Reading symbols from /home/sybase/lib/libsybtcl.so...done. Reading symbols from /home/sybase/lib/libintl.so...done. Reading symbols from /home/sybase/lib/libcomn.so...done. Reading symbols from /home/sybase/lib/libct.so...done. Reading symbols from /home/sybase/lib/libcs.so...done. Reading symbols from /usr/lib/libpq.so...done. Reading symbols from /usr/lib/libmcrypt.so.4...done. Reading symbols from /usr/lib/libltdl.so.0...done. Reading symbols from /usr/lib/libttf.so.2...done. Reading symbols from /usr/lib/libpng.so.2...done. Reading symbols from /usr/lib/libz.so.1...done. Reading symbols from /usr/lib/libgd.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libdb.so.3...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /usr/X11R6/lib/libXpm.so.4...done. Reading symbols from /usr/X11R6/lib/libX11.so.6...done. Reading symbols from /lib/libnss_files.so.2...done. Reading symbols from /lib/libnss_nisplus.so.2...done. Reading symbols from /lib/libnss_nis.so.2...done. 0x402dfa02 in __libc_accept () from /lib/libc.so.6 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x819dcaf in net_close (stream=0x82d1b90) at mail.c:4857 4857mail.c: No such file or directory. (gdb) bt #0 0x819dcaf in net_close (stream=0x82d1b90) at mail.c:4857 #1 0x40093557 in np_io_close () from /home/sybase/lib/libct.so #2 0x4009c327 in ct__tds_closeconn () from /home/sybase/lib/libct.so #3 0x40063a3d in com__async_runstack () from /home/sybase/lib/libcomn.so #4 0x40063939 in com__async_poll_state () from /home/sybase/lib/libcomn.so #5 0x4006377f in com__async_do_poll () from /home/sybase/lib/libcomn.so #6 0x400631eb in com_async_poll () from /home/sybase/lib/libcomn.so #7 0x400a3ac1 in ct__api_async () from /home/sybase/lib/libct.so #8 0x400a62c2 in ct__api_close () from /home/sybase/lib/libct.so #9 0x400a63d1 in ct_close () from /home/sybase/lib/libct.so #10 0x8114034 in _close_sybase_link (rsrc=0x832aea4) at php_sybase_ct.c:158 #11 0x812dd6a in list_entry_destructor (ptr=0x832aea4) at zend_list.c:258 #12 0x812cc3e in zend_hash_del_key_or_index (ht=0x82ab1c8, arKey=0x0, nKeyLength=0, h=1, flag=1) at zend_hash.c:535 #13 0x812daaf in zend_list_delete (id=1) at zend_list.c:59 #14 0x8129457 in _zval_dtor (zvalue=0x832840c) at zend_variables.c:80 #15 0x81238c2 in _zval_ptr_dtor (zval_ptr=0x82cb5c8) at zend_execute_API.c:261 #16 0x812ccd9 in zend_hash_destroy (ht=0x82ab0ac) at zend_hash.c:564 #17 0x8123752 in shutdown_executor () at zend_execute_API.c:165 #18 0x8129e07 in zend_deactivate () at zend.c:525 #19 0x80a7422 in php_request_shutdown (dummy=0x0) at main.c:688 #20 0x80a55ba in php_apache_request_shutdown () #21 0x8155c6e in run_cleanups () #22 0x815449d in ap_clear_pool () #23 0x8154511 in ap_destroy_pool () #24 0x816c1e2 in ap_destroy_sub_req () #25 0x807ffc8 in handle_include () #26 0x8082fc5 in send_parsed_content () #27 0x808359d in send_parsed_file () #28 0x8158f53 in ap_invoke_handler () #29 0x816ca99 in process_request_internal () #30 0x816cafc in ap_process_request () #31 0x81640ce in child_main () #32 0x816430c in make_child () #33 0x8164686 in perform_idle_server_maintenance () #34 0x8164bc5 in standalone_main () #35 0x8165183 in main () #36 0x402459cb in __libc_start_main (main=0x8164e3c main, argc=3, argv=0xb954, init=0x8070c34
[PHP-DEV] Re: Bug #10599 Updated: background attribute in the body tag causes a double insert
wow :) great explanation. thanks for the reply--I'll update my page headers. Gavin Bug Database [EMAIL PROTECTED] wrote: ID: 10599 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: MySQL related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Actually, it's a bug in your HTML (although you did confuse me for a few minutes...) The attribute you're looking for is bgcolor; background loads a background image, and expects a URL argument. When you feed it with #FF, it tries to access http://www.dukemarket.com/bug.php#FF to load it as a background image, access the page again, and causes a second insert. It was a good challenge though :) Previous Comments: -- - [2001-05-02 03:45:48] [EMAIL PROTECTED] I have documented the problem at a href=http://www.dukemarket.com/bug.php;http://www.dukemarket.com/bug.p hp/a. If you have any questions, email me at a href=mailto:[EMAIL PROTECTED];[EMAIL PROTECTED]/a. -- - ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/? id=10599edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #8663 Updated: Script with incorrect syntax crashes php4ts.dll (seems similar to #8521)
ID: 8663
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproduceable crash
Operating system:
PHP Version: 4.0.4
Assigned To:
Comments:
Fixed in the CVS - thanks for the accurate and easily reproducible bug report!
Previous Comments:
---
[2001-04-26 15:08:45] [EMAIL PROTECTED]
heh trying a modified script didnt work but trying your script again crashses.
Backtrace:
_zval_ptr_dtor(_zval_struct * * 0x00e00b8c, char * 0x1022188c `string', unsigned int
236) line 259 + 5 bytes
zend_switch_free(_zend_op * 0x00dae5c0, _temp_variable * 0x00e00b88,
_zend_executor_globals * 0x00db21e0) line 236 + 38 bytes
execute(_zend_op_array * 0x00e00c28, _zend_executor_globals * 0x00db21e0) line 1831 +
17 bytes
execute(_zend_op_array * 0x00dff2f8, _zend_executor_globals * 0x00db21e0) line 2039 +
19 bytes
zend_execute_scripts(int 8, _zend_compiler_globals * 0x00db28f0,
_zend_executor_globals * 0x00db21e0, int 3) line 743 + 22 bytes
php_execute_script(_zend_file_handle * 0x0012ff48, _zend_compiler_globals *
0x00db28f0, _zend_executor_globals * 0x00db21e0, _php_core_globals * 0x00db52c0) line
1205 + 29 bytes
main(int 3, char * * 0x00db18c0) line 735 + 22 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e992a6()
---
[2001-04-26 14:53:41] [EMAIL PROTECTED]
THis has been fixed in latest CVS, and will be included in 4.0.6 thanks for your
report.
- James
---
[2001-04-26 14:25:50] [EMAIL PROTECTED]
Reproduced under Apache and ISAPI under win2k.
- James
---
[2001-01-11 16:59:07] [EMAIL PROTECTED]
I have three php files as follows:
--f1.php--
?php
include f2.php;
include f3.php;
?
--
--f2.php--
?php
# only seems to occur in a switch statement
switch ($t) {
default:
die (;# a syntax error, on purpose
}
?
--
--f3.php--
?php
$x = 0; # there needs to be some statement here for the bug to occur
?
--
When running f1.php through php.exe I get
PHP caused an invalid page fault in
module PHP4TS.DLL at 015f:1008e147.
Registers:
EAX=0001 CS=015f EIP=1008e147 EFLGS=00010206
EBX=006601ec SS=0167 ESP=0063f410 EBP=00791710
ECX= DS=0167 ESI=00791714 FS=541f
EDX=007910dc ES=0167 EDI=006601e4 GS=
Bytes at CS:EIP:
66 ff 48 0a 8b 06 66 8b 48 0a 66 85 c9 75 40 50
Stack dump:
007612f0 100a46bb 00791714 00791990 007612f0 007918e0 0065ea04 006601c4 006601c4
0001 007910dc 006601ec 81709050 0063f470
Couldn't generate a backtrace, the borland debugger refused to work on this error. It
seems to be similar to the problem described in bug #8521. In both cases a simple
syntax error crashes the DLL. In this case, however, the include directives seem to
have something to do with the bug. Simply copying the contents of f2 and f3 into f1
does not cause a crash.
PHP is 4.0.4 windows installer from your website.
Bye,
Paul
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8663edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Branching 4.0.6...
On 2001-05-05 19:02:29, Andi Gutmans [EMAIL PROTECTED] wrote: Hi, Now that the pressing problems have been fixed in the CVS I'd like to branch 4.0.6 and release an RC1. Any objections? No, but you may want to check that my commit for fsock/network related files works for you all before you branch, just in case. It works for me, and it shouldn't affect you unless you enable the streams stuff in configure. The GD config stuff is also still busted. On www.php.net, the config system detected GIF support in GD-1.8.3.. That's because the GD-1.8.3 lib on www.php.net does have GIF support. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10643 Updated: PHP 4.0.5 linked against openldap 2.x segfaults on Apache startup
ID: 10643
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: LDAP related
Operating system: Linux 2.2.14
PHP Version: 4.0.5
Description: PHP 4.0.5 linked against openldap 2.x segfaults on Apache startup
Linking to libpthread in Apache resolved the problem.
Previous Comments:
---
[2001-05-06 12:07:15] [EMAIL PROTECTED]
This might be the infamous pthread lib / glibc bug.
Is your Apache linked with pthread?
If not, check the instructions how to do it on
www.php.net/oci8
(I know, it's Oracle manual page..:)
--Jani
---
[2001-05-03 14:06:27] [EMAIL PROTECTED]
My configure string:
./configure --prefix=/software/php-4 --with-apxs=/software/apache-1.3/bin/apxs
--with-gdbm --with-ldap=/software/openldap-2 --with-pgsql=/software/postgresql-7
--with-config-file-path=/software/php-4/lib
Using OpenLDAP 2.0.7 and PostgreSQL 7.1 on a SuSE 6.4 box.
# ldd libphp4.so
libpam.so.0 = /lib/libpam.so.0 (0x40144000)
libdl.so.2 = /lib/libdl.so.2 (0x4014c000)
libpq.so.2 = /software/postgresql-7/lib/libpq.so.2 (0x4015)
libldap.so.2 = /software/openldap-2/lib/libldap.so.2 (0x4015f000)
liblber.so.2 = /software/openldap-2/lib/liblber.so.2 (0x40249000)
libgdbm.so.2 = /usr/lib/libgdbm.so.2 (0x40256000)
libresolv.so.2 = /lib/libresolv.so.2 (0x4025e000)
libm.so.6 = /lib/libm.so.6 (0x4026d000)
libcrypt.so.1 = /lib/libcrypt.so.1 (0x4028a000)
libnsl.so.1 = /lib/libnsl.so.1 (0x402b7000)
libc.so.6 = /lib/libc.so.6 (0x402ce000)
/lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000)
Here is an strace of an Apache child that died. I'm using NSS_LDAP and PAM_LDAP.
open(/lib/libpthread.so.0, O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0755, st_size=289663, ...}) = 0
read(4, 177ELF111
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Branching 4.0.6...
That's because the GD-1.8.3 lib on www.php.net does have GIF support. Well, then the mistake is in some other part, because it complained about gdImageCreateFromGifCtx not being defined in some #ifdef HAVE_GD_GIF .. #endif area. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Branching 4.0.6...
On Sun, 6 May 2001, Sascha Schumann wrote: That's because the GD-1.8.3 lib on www.php.net does have GIF support. Well, then the mistake is in some other part, because it complained about gdImageCreateFromGifCtx not being defined in some #ifdef HAVE_GD_GIF .. #endif area. I am unable to recreate this problem on that same machine. See my ~rasmus/config.nice file. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10325 Updated: Opening database connection breaks ldap
ID: 10325 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: LDAP related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Does this happen with PHP 4.0.5 ?? And if so, does it happen with the latest CVS? (snapshots: http://snaps.php.net/ ) --Jani Previous Comments: --- [2001-04-14 06:50:50] [EMAIL PROTECTED] Opening a database connection breaks LDAP's link index. Example code: ?php $dbcon = pg_connect(host=localhost port=5432 dbname=testdb user=testuser password=testpass); $ds = ldap_connect(localhost); $ldapcon = ldap_bind($ds); // This always returns 1 echo $ldapcon; // This errors out ldap_search($ldapcon, dc=test,dc=com, cn=*); ? This generates the error: PHP Warning: 1 is not a LDAP link index If you comment out the pg_connect() line, LDAP works fine. If you pg_close($dbcon) right after the pg_connect(), you still get the PHP error. This is a definite show stopper considering some people use a database for sessions, which means you can't use LDAP after you start your session. I'm using the latest openldap 2.0.7 postgres 7.0.3, php compiled into apache: ./configure --enable-memory-limit --enable-track-vars --enable-sysvsem --enable-sysvshm --with-gd --with-pgsql --with-freetype --with-ldap=/usr/local/openldap --with-xml --with-mhash --enable-trans-sid --with-kerberos --with-mcrypt --with-apache=../apache_1.3.19 --enable-bcmath --with-zlib --with-sockets --enable-inline-optimizations Please fix soon :) --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10325edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10609 Updated: comments made with # or // in included files cause visible output
ID: 10609 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.5 Assigned To: Comments: I tried this with PHP NUke etc with 4.0.6 dev. Cant reproduce neither could about 10 other people, please tell us the version of flex you are using and email the file that causes the problem specifically to [EMAIL PROTECTED] or to [EMAIL PROTECTED] - James Previous Comments: --- [2001-05-02 16:48:54] [EMAIL PROTECTED] I just can't reproduce this :) Can you please post the output of flex --version. Also maybe you can send the file that doesn't work as an attachement to [EMAIL PROTECTED] --- [2001-05-02 16:41:18] [EMAIL PROTECTED] Amazingly (i cant believe what i see) i was able to shorten the code that generates the bug (on my system, plainvalinnal redhat 6.1 running php 4.0.5 as a apache mod) to this code, note that the same code executes fine (of course) under 4.0.4; - example bug code ?php $YouCantSeeThisOne; // After a // comment the source code gets dumped to the output.. look: $YouCanSeeThis; ? - end example bug code the ourput I get is : // After a // comment the source code gets dumped to the output.. look: $YouCanSeeThis; --- [2001-05-02 16:05:50] [EMAIL PROTECTED] Please post as short as possible reproducing scripts. (First update didn't get mailed out) --- [2001-05-02 15:58:59] [EMAIL PROTECTED] Please post as short as possible reproducing scripts. --- [2001-05-02 09:31:32] [EMAIL PROTECTED] using PHPnuke files are are often included inside others that are included as well. I had to change all the comments of my THEME.php file (the most internal include) otherwise they would produce output to the page! changing // and # to the /* */ syntax solve the problem! note that this only happens in included files I can easily reproduce it if needed. Only relevalnt to 4.0.5 was warking fine with 4.0.4 --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10609edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10662 Updated: --with-iconv compilation and installation
ID: 10662 Updated by: sterling Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Sablotron XSL Operating system: PHP Version: 4.0.5 Assigned To: Comments: fixed in cvs thanks, Previous Comments: --- [2001-05-04 06:48:49] [EMAIL PROTECTED] (This is not actually Sablotron extension bug, but I need to use --with-iconv option for my system to build in Sablotron and have a problem in this case) 1. The error message during Apache restart: Cannot load /usr/libexec/apache/libphp4.so into server: /usr/libexec/apache/libphp4.so: undefined symbol: iconv_module_entry 2. Configure line: --with-apxs --prefix=/usr --with-gd --with-gettext --with-yp --with-system-regex --with-mysql=/usr --enable-safe-mode --enable-sysvsem --enable-sysvshm --with-exec-dir=/home/httpd/php/bin --with-zlib --with-config-file-path=/etc/httpd --disable-debug --enable-magic-quotes --enable-bcmath --with-mod_charset --enable-calendar --with-iconv --with-sablot 3. Short description The configure script and compilation go smoothly without errors. ldd libphp4.so shows the following: libpam.so.0 = /lib/libpam.so.0 (0x2abda000) libdl.so.2 = /lib/libdl.so.2 (0x2abe1000) libz.so.1 = /usr/lib/libz.so.1 (0x2abe5000) libexpat.so.0 = /usr/lib/libexpat.so.0 (0x2abf3000) libsablot.so.0 = /usr/lib/libsablot.so.0 (0x2ac12000) libmysqlclient.so.6 = /usr/lib/libmysqlclient.so.6 (0x2ac8e000) libiconv.so.2 = /usr/lib/libiconv.so.2 (0x2aca) libttf.so.2 = /usr/lib/libttf.so.2 (0x2ad39000) libgd.so.1 = /usr/lib/libgd.so.1 (0x2ad4e000) libresolv.so.2 = /lib/libresolv.so.2 (0x2ad85000) libm.so.6 = /lib/libm.so.6 (0x2ad94000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x2adad000) libnsl.so.1 = /lib/libnsl.so.1 (0x2addb000) libc.so.6 = /lib/libc.so.6 (0x2ade2000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x2aaab000) ,so all libraries are in place. But the error message occurs during apache start/restart (see item 1.) Looking through main/php_config.h I found that there is no line #define HAVE_ICONV 1 ,but if I install it manually I have the following errors during compilation: make[3]: Entering directory `/mnt/files/linux/www/php/php-4.0.5/ext/iconv' /bin/sh /mnt/files/linux/www/php/php-4.0.5/libtool --silent --mode=compile gcc -I. -I/mnt/files/linux/www/php/php-4.0.5/ext/iconv -I/mnt/files/linux/www/php/php-4.0.5/main -I/mnt/files/linux/www/php/php-4.0.5 -I/usr/include/apache -I/mnt/files/linux/www/php/php-4.0.5/Zend -I/usr/include/mysql -I/mnt/files/linux/www/php/php-4.0.5/ext/xml/expat/xmltok -I/mnt/files/linux/www/php/php-4.0.5/ext/xml/expat/xmlparse -I/mnt/files/linux/www/php/php-4.0.5/TSRM -DLINUX=2 -DEAPI -DKEAPI -DUSE_PERL_SSI -D_REENTRANT -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -c iconv.c iconv.c:59: `php_minit_iconv' undeclared here (not in a function) iconv.c:59: initializer element for `iconv_module_entry.module_startup_func' is not constant iconv.c:60: `php_mshutdown_iconv' undeclared here (not in a function) iconv.c:60: initializer element for `iconv_module_entry.module_shutdown_func' is not constant iconv.c:63: `php_info_iconv' undeclared here (not in a function) iconv.c:63: initializer element for `iconv_module_entry.info_func' is not constant make[3]: *** [iconv.lo] Error 1 So, there is no way to build working PHP4.0.5 with support of external libiconv (outside of glibc, glibc-2.0.7 doesn't have iconv functions). PHP4.0.4pl1 was built and run successfully on the same system with the same configuration options. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10662edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Branching 4.0.6...
On Sun, 6 May 2001, Rasmus Lerdorf wrote: On Sun, 6 May 2001, Sascha Schumann wrote: That's because the GD-1.8.3 lib on www.php.net does have GIF support. Well, actually it does not have GIF support. $ nm /home/rasmus/gd-1.8.3/libgd.a|grep -i gif|wc -l 0 However, the gd lib in /usr/lib has GIF support. I initially configured PHP using --with-jpeg-dir=/usr and therefore -L/usr/lib was erroneously in LDFLAGS (or LIBS) during the gdCreateImageFromGif test. This actually should not happen.. During the build, /home/rasmus/gd-1.8.3 was included before /usr/include and hence a mismatch between the expected features and the contents of the header file occured, leading to various error messages. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] connection_timeout() and PHP 3
[Jani Taskinen [EMAIL PROTECTED]] On Fri, 4 May 2001, Hartmut Holzgraefe wrote: Jani Taskinen wrote: On Thu, 3 May 2001, Zak Greant wrote: Does anyone know if connection_timeout will be disappearing from PHP 3? Put it this way: Does anyone know when PHP 3 will disappear? :) IMHO it will die together with the FAT filesystem ? So it's dead already? :) Anyway, why do we still give it out? On downloads page that is.. IMNSHO, it should disappear. If not, gimme some reasons why not. Some people who are fanatic about the GPL and the issues RMS has with the PHP 4 license still use PHP 3. IMHO we should offer it for download, but be less active in supporting it. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] extension/module versioning
[[EMAIL PROTECTED]]
dev team,
what are the chances of having a function call for every extension that
returns the version? this would be extremely useful for determining
whether the correct version is installed, rather than checking to see
if the function_exists().
eg.
$version_id = xml_version();
or
$version_id = ibase_version();
thanks for your attention,
I second this, although I really think a constant or maybe _one_
function for checking any extension's version would be best.
Also, I think we need some guidelines for version numbering, so
different extensions don't have vastly different ideas of what it
means when the major version changes.
Here's a suggestion from PEAR:
-- snip --
We encourage maintainers to use one of the following version numbering
schemes:
MMDD( = year, MM = month, DD = day)
V[{a,b}N] (V = version) [ alpha or beta release N ]
V.R[{a,b}N] (R = release)
V.R.P[{a,b}N] (P = patchlevel)
PEAR tools follow these rules to compare versions:
For MMDD, V, R, P and N, a higher number indicates a more recent
release. Any beta of a release is considered newer than an alpha of
the same release.
When comparing V with V.N, V.N is considered newer if the version part
of V.N is greather than or equal to the version part of V. The same
logic applies to V.N.P vs. V.N.
Releases with lots of known bugs, potential API changes etc. are
typically alpha releases. Beta releases are when the risk of API
changes is minimal and you believe most bugs are found.
Between patchlevels, there should be no or very limited, and
compatible, API changes. Between releases, API changes should be
compatible. Between versions it's ok to break the API.
An API consists of names of classes, functions, documented globals,
which parameters are accepted by functions/methods and their
semantics/behaviour.
-- snip --
IMHO it's a simple scheme that should be easy to understand for
extension developers and users.
- Stig
--
Stig Sæther Bakken [EMAIL PROTECTED]
Fast Search Transfer ASA, Trondheim, Norway
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] default location of php.ini changed?
[Zeev Suraski [EMAIL PROTECTED]] At 20:54 6/5/2001, Mike Robinson wrote: Sorry if this has already been dealt with, but I just got bit on the ass pretty hard and there's nothing in the bug db about it... the default location for php.ini has been /usr/local/lib for as long as I can recall. An install of a snapshot from this morning puts the default location as /usr/local/etc Was this intended? No it wasn't; Guys, wasn't this changed back? Uhm, I'm still testing this patch on my laptop (I added a --with-layout option that is PHP by default, but you can set it to GNU to get the new defaults). Sorry for being a bit slow, I'm spending most of my spare time transforming the jungle outside my house to something more lawn-ish these days. :-) - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] default location of php.ini changed?
At 01:35 7/5/2001, Stig Sæther Bakken wrote: Uhm, I'm still testing this patch on my laptop (I added a --with-layout option that is PHP by default, but you can set it to GNU to get the new defaults). Sorry for being a bit slow, I'm spending most of my spare time transforming the jungle outside my house to something more lawn-ish these days. :-) Ok :) We need to be well aware of this though, to make sure it doesn't stay that way in 4.0.6. The feedback will be merciless :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10325 Updated: Opening database connection breaks ldap
ID: 10325 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: LDAP related Operating system: Linux 2.4.3 PHP Version: 4.0.4pl1 Description: Opening database connection breaks ldap User error :) I was using the integer result from the ldap_bind() operation as the link index. ldap_bind() always returned 1 for true, which just happened to be the link index zend assigned to the ldap_connect(). The reason it broke when I connected to postgres was because zend apparantly keeps only 1 link index pool, assigns 1 to the postgres connection, then the ldap connection got 2. Also of interest was that the ldap connection always got a link index of 2 even after executing a pg_close(), which I would of assumed would clear the first link index of 1 for ldap to use. Dan- Previous Comments: --- [2001-05-06 23:32:19] [EMAIL PROTECTED] Does this happen with PHP 4.0.5 ?? And if so, does it happen with the latest CVS? (snapshots: http://snaps.php.net/ ) --Jani --- [2001-04-14 06:50:50] [EMAIL PROTECTED] Opening a database connection breaks LDAP's link index. Example code: ?php $dbcon = pg_connect(host=localhost port=5432 dbname=testdb user=testuser password=testpass); $ds = ldap_connect(localhost); $ldapcon = ldap_bind($ds); // This always returns 1 echo $ldapcon; // This errors out ldap_search($ldapcon, dc=test,dc=com, cn=*); ? This generates the error: PHP Warning: 1 is not a LDAP link index If you comment out the pg_connect() line, LDAP works fine. If you pg_close($dbcon) right after the pg_connect(), you still get the PHP error. This is a definite show stopper considering some people use a database for sessions, which means you can't use LDAP after you start your session. I'm using the latest openldap 2.0.7 postgres 7.0.3, php compiled into apache: ./configure --enable-memory-limit --enable-track-vars --enable-sysvsem --enable-sysvshm --with-gd --with-pgsql --with-freetype --with-ldap=/usr/local/openldap --with-xml --with-mhash --enable-trans-sid --with-kerberos --with-mcrypt --with-apache=../apache_1.3.19 --enable-bcmath --with-zlib --with-sockets --enable-inline-optimizations Please fix soon :) --- Full Bug description available at: http://bugs.php.net/?id=10325 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10695: Class Properties are not accepted by for each structures
From: [EMAIL PROTECTED]
Operating system: Linux Redhat 6.2
PHP version: 4.0.4pl1
PHP Bug Type: Class/Object related
Bug description: Class Properties are not accepted by for each structures
Hello.
I have got a standard install of PHP 4.0.4pl1. So there is nothing special about it.
Here is the code extract:
#$result Data is successfully retrieved from mysql database)
class auth_user {
var $md_paketnummern;
function auth_user($username,$password,$database,$auth_table,$conn_id) {
$this-md_paketnummern=explode(|,$result[pakete]);
}
}
class fetch_pakete {
function fetch_pakete(){
# Now comes the LINE!!!
foreach($newuser-md_paketnummern as $arraykey = $paketnummern){
echo $paketnummern;
}
}
}
Now I call $newuser = new auth_user;
then: netpaket = new fetch_pakete;
When I replace $newuser-md_paketnummern with an argument, it works fine. With this
version it does not.
--
Edit Bug report at: http://bugs.php.net/?id=10695edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10697: problem with httpd.conf
From: [EMAIL PROTECTED] Operating system: win 98 SE PHP version: 4.0.5 PHP Bug Type: Apache related Bug description: problem with httpd.conf hi; i couldn't add line Action application/x-httpd-php /php/php.exe in httpd.conf when working with Apache. thanks leon -- Edit Bug report at: http://bugs.php.net/?id=10697edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] intval($resource)
Hello Andi, On 27-Apr-01 19:18:12, you wrote: At 06:03 PM 4/27/2001 -0400, Joe Brown wrote: Run into a spot of trouble using Metabase(db wrapper) because of it's use of casting a $var=intval($resource) where OCIFreeCursor fails to function after it has been casted. Guessing that it fails because intval is creating a reference to the resource, in turn OCI does not release the resource because there additional reference exist. I'd like to start working on fixing this, but don't know which behaviour to attack. Does OCI need to be fixed or intval()? Suggestions anyone... Is there a good reason it needs to use intval() on the resource? To be Just to overcome a past bug in PHP 4.0.(?). It was making resource values inconsistently turn into strings when used as array indexes. A user reported a bug on Metabase because of that when it turned out to be a PHP bug. The workaround of using intval() made the bug effect go away. quite honest intval() shouldn't really return a valid value for resources and just by chance it returns the resource id which is probably not a good thing. We can try and look into fixing this problem though. Resource values should be integers to be consistent with the PHP documentation. Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED] -- E-mail: [EMAIL PROTECTED] URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10697 Updated: problem with httpd.conf
ID: 10697 Updated by: zak Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: Apache related Operating system: PHP Version: 4.0.5 Assigned To: Comments: Not a bug - you need sufficient permission to edit httpd.conf. Contact your sysadmin Previous Comments: --- [2001-05-07 04:32:22] [EMAIL PROTECTED] hi; i couldn't add line Action application/x-httpd-php /php/php.exe in httpd.conf when working with Apache. thanks leon --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10697edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] intval($resource)
On 6 May 2001, Manuel Lemos wrote: Hello Andi, On 27-Apr-01 19:18:12, you wrote: At 06:03 PM 4/27/2001 -0400, Joe Brown wrote: Run into a spot of trouble using Metabase(db wrapper) because of it's use of casting a $var=intval($resource) where OCIFreeCursor fails to function after it has been casted. Guessing that it fails because intval is creating a reference to the resource, in turn OCI does not release the resource because there additional reference exist. I'd like to start working on fixing this, but don't know which behaviour to attack. Does OCI need to be fixed or intval()? Suggestions anyone... Is there a good reason it needs to use intval() on the resource? To be Just to overcome a past bug in PHP 4.0.(?). It was making resource values inconsistently turn into strings when used as array indexes. A user reported a bug on Metabase because of that when it turned out to be a PHP bug. The workaround of using intval() made the bug effect go away. This shouldn't be happening (does it still happen for you?) The only time when a resource should be represented as a string is if you print it out, in which case that is the proper behaviour. quite honest intval() shouldn't really return a valid value for resources and just by chance it returns the resource id which is probably not a good thing. We can try and look into fixing this problem though. Resource values should be integers to be consistent with the PHP documentation. Resource values are internally integers (well, no actually they're long's but so are PHP's integers, anyyyway). They're an abstract type so they should be shown as such, and not have an integer value. And the PHP documentation should be consistent with the PHP source, not the other way around :) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] intval($resource)
Hello Sterling, On 07-May-01 00:53:37, you wrote: Is there a good reason it needs to use intval() on the resource? To be Just to overcome a past bug in PHP 4.0.(?). It was making resource values inconsistently turn into strings when used as array indexes. A user reported a bug on Metabase because of that when it turned out to be a PHP bug. The workaround of using intval() made the bug effect go away. This shouldn't be happening (does it still happen for you?) The only time when a resource should be represented as a string is if you print it out, in which case that is the proper behaviour. Yes, but until that bug was fixed I felt that I needed to add the workaround because some people were using that version and were complaining as a bug in Metabase. quite honest intval() shouldn't really return a valid value for resources and just by chance it returns the resource id which is probably not a good thing. We can try and look into fixing this problem though. Resource values should be integers to be consistent with the PHP documentation. Resource values are internally integers (well, no actually they're long's but so are PHP's integers, anyyyway). They're an abstract type so they should be shown as such, and not have an integer value. Yes, I know, but that other broke the behaviour. And the PHP documentation should be consistent with the PHP source, not the other way around :) Except when the source is buggy! :-) Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED] -- E-mail: [EMAIL PROTECTED] URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10698: nl2br produces br / instead of br
From: [EMAIL PROTECTED] Operating system: Linux RedHat 6.2 PHP version: 4.0.5 PHP Bug Type: Unknown/Other Function Bug description: nl2br produces lt;br /gt; instead of lt;brgt; $t2 = nl2br ($t1); module was compiled with: --with-apxs=/opt/apache/bin/apxs --with-mysql=/mysql php.ini was not changed from original -- Edit Bug report at: http://bugs.php.net/?id=10698edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10699: not closed client socket after request
From: [EMAIL PROTECTED] Operating system: RedHat 6.2 PHP version: 4.0.5 PHP Bug Type: Sockets related Bug description: not closed client socket after request in simple client script ? $sk=socket(...); connect($sk,...); // close($sk); ? If line close($sk); commented - socket connection not canceled. -- Edit Bug report at: http://bugs.php.net/?id=10699edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
