[PHP-DEV] Bug #14263: Don't free each allocation in cgimode
From: [EMAIL PROTECTED]
Operating system: all
PHP version: 4.0.6
PHP Bug Type: Performance problem
Bug description: Don't free each allocation in cgimode
If compiled in standalone cgi mode, when the script exits, php only needs
to free resources, not other arrays or strings or items (unless we ever
support object destructors).
It can take a LONG time to free a hundred thousand or so elements in nested
arrays, 4 or 5 times longer than it takes to create then.
See these threads in phpdev mailing list:
Re: [PHP-DEV] maybe serious error in RC3 memory manager
RE: [PHP-DEV] CGI quick cleanup
Sample code:
Note how long it takes to exit after finishing.
#! /usr/bin/php -q
?php
ini_Set(max_execution_time,0);
ini_Set(memory_limit,500M);
class thingy {
function thingy($c) {
if ($c0) $this-ref=new thingy($c-1);
}
}
$stash=array();
$max=50;
$start=time();
for($i=0;$i$max;$i++) {
$r=rand(0,300);
$stash[$r][]=new thingy(rand(0,10));
echo \rUse: .floor($i/$max*100).% ;
}
echo \n;
$mid=time();
$max=count($stash);
$c=0;
foreach(array_keys($stash) as $key) {
unset($stash[$key]);
$c++;
echo \rFree: .floor($c/$max*100).% ;
}
unset($stash);
echo \n;
$done=time();
print Use: .($mid-$start).\n;
print Free: .($done-$mid).\n;
?
--
Edit bug report at: http://bugs.php.net/?id=14263edit=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 #14263 Updated: Don't free each allocation in cgimode
ID: 14263
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Open
Old Bug Type: Performance problem
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 4.0.6
New Comment:
Making it a feature request, as it's not a bug.
Previous Comments:
[2001-11-28 04:00:08] [EMAIL PROTECTED]
If compiled in standalone cgi mode, when the script exits, php only needs to free
resources, not other arrays or strings or items (unless we ever support object
destructors).
It can take a LONG time to free a hundred thousand or so elements in nested arrays, 4
or 5 times longer than it takes to create then.
See these threads in phpdev mailing list:
Re: [PHP-DEV] maybe serious error in RC3 memory manager
RE: [PHP-DEV] CGI quick cleanup
Sample code:
Note how long it takes to exit after finishing.
#! /usr/bin/php -q
?php
ini_Set(max_execution_time,0);
ini_Set(memory_limit,500M);
class thingy {
function thingy($c) {
if ($c0) $this-ref=new thingy($c-1);
}
}
$stash=array();
$max=50;
$start=time();
for($i=0;$i$max;$i++) {
$r=rand(0,300);
$stash[$r][]=new thingy(rand(0,10));
echo \rUse: .floor($i/$max*100).% ;
}
echo \n;
$mid=time();
$max=count($stash);
$c=0;
foreach(array_keys($stash) as $key) {
unset($stash[$key]);
$c++;
echo \rFree: .floor($c/$max*100).% ;
}
unset($stash);
echo \n;
$done=time();
print Use: .($mid-$start).\n;
print Free: .($done-$mid).\n;
?
Edit this bug report at http://bugs.php.net/?id=14263edit=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] if (empty(trim('x'))) == parse error?
Hi,
why php results a parse error on this expression?
if (empty(trim('x'))) echo Hello;
the statement works fine:
$x=trim('x');
if (empty($x)) echo Hello;
it is not really logically.
Regards,
Holger
--
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 #14262 Updated: field name in select results strange characters
ID: 14262
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: ODBC related
Operating System: Linux 6.1
PHP Version: 4.0.6
Old Assigned To: derick
Assigned To:
New Comment:
The strange characters displayed were displayed due to an error in our own ODBC
client.
I still have the wish that the field name isn't limited to 32 but is allocated as
needed, but I have no idea how difficult this is to implement.
Marco
Previous Comments:
[2001-11-28 02:42:26] [EMAIL PROTECTED]
Okay, I'm on it.
Derick
[2001-11-28 02:39:44] [EMAIL PROTECTED]
Here it is:
?
$cnx = odbc_connect(unims,ecw,inter00);
$query = select 1 as '123456789 123456789 123456789 123456789 ' from
bedryf;;
$qid = odbc_exec($cnx,$query);
echo odbc_field_name($qid,1);
odbc_close($cnx);
?
[2001-11-28 02:36:15] [EMAIL PROTECTED]
Can you post a short script for me?
Derick
[2001-11-28 02:31:47] [EMAIL PROTECTED]
You probably don't know the database, as the DBMS is developed in our company (is
called UNIMS) and we have written our own ODBC driver.
I have checked what our database returns and that is ok (no strange characters).
I also looked in the php sources, and I think the problem is in the following struct
(php_odbc.h) :
typedef struct odbc_result_value {
char name[32];
char *value;
long int vallen;
SDWORD coltype;
} odbc_result_value;
But I am not a PHP-developer (yet ;-) )
Kind regards
Marco
[2001-11-28 02:24:17] [EMAIL PROTECTED]
Which database are you trying to access through ODBC?
Derick
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=14262
Edit this bug report at http://bugs.php.net/?id=14262edit=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] if (empty(trim('x'))) == parse error?
From the docs for empty():
Note that this is meaningless when used on anything which isn't a
variable; i.e. empty (addslashes ($name)) has
no meaning since it would be checking whether something which isn't a variable is a
variable with a FALSE value.
Regards,
Andrey Hristov
- Original Message -
From: Holger Schopohl [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 28, 2001 11:15 AM
Subject: [PHP-DEV] if (empty(trim('x'))) == parse error?
Hi,
why php results a parse error on this expression?
if (empty(trim('x'))) echo Hello;
the statement works fine:
$x=trim('x');
if (empty($x)) echo Hello;
it is not really logically.
Regards,
Holger
--
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] Bug #14258 Updated: Date Timezone is not correct
ID: 14258 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old Status: Suspended Status: Duplicate Bug Type: Mail related Operating System: Window 2000 PHP Version: 4.0.6 Old Assigned To: Assigned To: hholzgra New Comment: dup. of #8909 Previous Comments: [2001-11-27 16:40:09] [EMAIL PROTECTED] Already known (but I don't know which is the first bug #). This will be fixed when (and if) the windows SMTP code gets rewritten. Derick [2001-11-27 15:38:12] [EMAIL PROTECTED] I'm not able to test on windows myself, but I've got some alternate code for computing the timezone in the mail() function if anyone is interested. Rather than using the _timezone variabel, I use the diff between php_gmtime_r() and php_localtime_r(). This is pretty straightforward. Don't know it it helps. [2001-11-27 14:38:23] [EMAIL PROTECTED] PHP is reversing the timezone. Please help! This is correct Internet Mail Service Version 5.5.2653.13) id W8DSHGQW; Tue, 27 Nov 2001 11:31:20 -0800 This is wrong Date: Tue, 27 Nov 2001 11:36:25 +0800 Entire email headers -Path: [EMAIL PROTECTED] Received: from chmls21.mediaone.net ([24.147.1.164]) by lsmls04.we.mediaone.net (Netscape Messaging Server 4.15) with ESMTP id GNH4XI00.HJF for [EMAIL PROTECTED]; Tue, 27 Nov 2001 11:32:06 -0800 Received: from laxntm02.studiosusa.com (messaging.studiosusa.com [216.101.81.197]) by chmls21.mediaone.net (8.11.6/8.11.6) with ESMTP id fARJWn007330 for [EMAIL PROTECTED]; Tue, 27 Nov 2001 14:32:50 -0500 (EST) Message-Id: [EMAIL PROTECTED] Received: by LAXNTM02 with Internet Mail Service (5.5.2653.19) id W8DSHGQY; Tue, 27 Nov 2001 11:31:23 -0800 Received: from LAXNTA03 ([172.17.1.19]) by laxntm02.studiosusa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id W8DSHGQW; Tue, 27 Nov 2001 11:31:20 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Tue, 27 Nov 2001 11:36:25 +0800 Subject: test Edit this bug report at http://bugs.php.net/?id=14258edit=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] solving blocking functions
Hi, I use PHP a lot for command line applications. In one of these applications I get a hangup whenever a blocking function doesn't return. I have been looking for the usual alarm() and signal handler solution. After much digging I ran into the ext/pcntl extension which offers me the signal handling I need, but I'm stuck with setting up the SIGALRM. Is there a way to call the alarm system call? Thanks in advance Christophe VG -- 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: ODBC Patch
Hallo Marco, On Wed, 28 Nov 2001, Marco Laponder wrote: Derick, I am so ashamed of myself. We didn't handle the maximum passed to the function quite well (didn't take into consideration the '\0' :-(. :) No more strange characters are shown now, so this is definitely a better situation. Did you apply the patch I send you for this? Do you think it is possible that there is no limit for the column name but that this is allocated as needed ? (This is more a wish than a bug, I realize that) Yes, this is possible, and not even hard to do. However, I don't have the possiblity to test things here. It would also help if you could send me the detailed specifications regards the functions you mentioned (SQLColAttributes() and SQLDescribeCol() ). regards, Derick - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED] Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands - -- 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 #14264: Session variable not keeping track of increment
From: [EMAIL PROTECTED]
Operating system: RedHat LINUX 7.2
PHP version: 4.1.0
PHP Bug Type: Session related
Bug description: Session variable not keeping track of increment
With this piece of code the session variable is not keeping track of the
increment:
?php
error_reporting(63);
session_start();
$abc = '';
session_register('abc');
$abc += 1;
$_SESSION['abc'] += 2;
print pre$abc\n\n;
print_r( $_SESSION);
?
While minor alteration of above code as below the session variable works:
?php
error_reporting(63);
$abc = '';
session_start();
session_register('abc');
$abc += 1;
$_SESSION['abc'] += 2;
print pre$abc\n\n;
print_r( $_SESSION);
?
--
Edit bug report at: http://bugs.php.net/?id=14264edit=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 #14264 Updated: Session variable not keeping track of increment
ID: 14264
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Session related
Operating System: RedHat LINUX 7.2
PHP Version: 4.1.0
New Comment:
session_start();
$abc = '';
so what do you expect to happen when you overwrite
the value of a session variable immediately after
restoring it using session_start()?
PS:
error_reporting(63);
*never* use numeric constants for error reporting settings, *always* use the symbolic
constants like E_ALL and E_WARNING, unless you want to get bitten by future additions
of error classes
Previous Comments:
[2001-11-28 05:42:42] [EMAIL PROTECTED]
With this piece of code the session variable is not keeping track of the increment:
?php
error_reporting(63);
session_start();
$abc = '';
session_register('abc');
$abc += 1;
$_SESSION['abc'] += 2;
print pre$abc\n\n;
print_r( $_SESSION);
?
While minor alteration of above code as below the session variable works:
?php
error_reporting(63);
$abc = '';
session_start();
session_register('abc');
$abc += 1;
$_SESSION['abc'] += 2;
print pre$abc\n\n;
print_r( $_SESSION);
?
Edit this bug report at http://bugs.php.net/?id=14264edit=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 #14264 Updated: Session variable not keeping track of increment
ID: 14264
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Bogus
Bug Type: Session related
Operating System: RedHat LINUX 7.2
PHP Version: 4.1.0
New Comment:
(bogusified)
Previous Comments:
[2001-11-28 05:49:09] [EMAIL PROTECTED]
session_start();
$abc = '';
so what do you expect to happen when you overwrite
the value of a session variable immediately after
restoring it using session_start()?
PS:
error_reporting(63);
*never* use numeric constants for error reporting settings, *always* use the symbolic
constants like E_ALL and E_WARNING, unless you want to get bitten by future additions
of error classes
[2001-11-28 05:42:42] [EMAIL PROTECTED]
With this piece of code the session variable is not keeping track of the increment:
?php
error_reporting(63);
session_start();
$abc = '';
session_register('abc');
$abc += 1;
$_SESSION['abc'] += 2;
print pre$abc\n\n;
print_r( $_SESSION);
?
While minor alteration of above code as below the session variable works:
?php
error_reporting(63);
$abc = '';
session_start();
session_register('abc');
$abc += 1;
$_SESSION['abc'] += 2;
print pre$abc\n\n;
print_r( $_SESSION);
?
Edit this bug report at http://bugs.php.net/?id=14264edit=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 #14156 Updated: No TTF support in this PHP build
ID: 14156 Updated by: sander Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: GD related Operating System: RH 7.2 PHP Version: 4.0.6 New Comment: Now your problem is that your version of GD was not built with FreeType. You should build it yourself from the source or use a different package. Previous Comments: [2001-11-28 02:46:35] [EMAIL PROTECTED] it works fine with --with-freetype-dir=/usr/lib --enable-gd-native-ttf and i got support for TTF, but then I got libgd was not built with TrueType so I had to make change in source code that was exlained in bug #12065 # if HAVE_LIBGD20 HAVE_LIBFREETYPE = # HAVE_LIBFREETYPE now I can use TTF functions but, did someone make changes in the source code, so people won't have to do it by themselves? JF [2001-11-21 12:51:59] [EMAIL PROTECTED] Use --enable-gd-native-ttf or --enable-gd-native-tt (yes that's a typo) if the first doesn't work. [2001-11-21 04:19:24] [EMAIL PROTECTED] libgd-1.8.4 freetype-2.0.3-7 freetype-devel-2.0.3-7 freetype-utils-2.0.3-7 Although in big #9569 you've said that GD extension only works with Freetype 1.x Guys from gd are saying: If you want to use the TrueType font support, you must also install the FreeType 2.x library, including the header files. while configuring, I got this: checking whether to enable truetype string function in gd... no checking for freetype(2)... no my config line: ./configure --prefix=/usr --with-config-file-path=/etc --disable-debug --enable-shared --with-apxs=/usr/sbin/apxs --with-gd --with-jpeg-dir=/usr --with-png --with-ttf=/usr/lib --with-freetype=/usr/lib --with-zlib --enable-safe-mode --enable-track-vars --enable-ftp --with-mysql=/usr/local/mysql --with-dbase --with-gettext script: ?php $im = imagecreate (400, 30); $black = ImageColorAllocate ($im, 0, 0, 0); $white = ImageColorAllocate ($im, 255, 255, 255); ImageTTFText ($im, 20, 0, 10, 20, $white, /path/arial.ttf, Testing... Omega: #937;); ImagePNG ($im); ? error: Warning: ImageTtfText: No TTF support in this PHP build Edit this bug report at http://bugs.php.net/?id=14156edit=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 #14265: Make does not create php4lib.so. Apxs fails to copy it to apache dir
From: [EMAIL PROTECTED]
Operating system: AIX 5.1
PHP version: 4.0.6
PHP Bug Type: Apache related
Bug description: Make does not create php4lib.so. Apxs fails to copy it to apache dir
I'm tring to build php 4.0.6 from SRPM whit apache 1.3.22
under AIX 5.1 whit Toolbox GNU utilities.
(Apache is correctly running with dso support :)
httpd -l
http_core.c
mod_so.c
I cannot create a DSO module with this configuration in
my SPEC file :
./configure \
--prefix=%{prefix} \
--disable-debug \
--enable-track-vars \
--enable-magic-quotes \
--with-apxs=/httpd/sbin/apxs \
--with-mysql=/opt/freeware \
--with-config-file-path=/etc/opt/freeware/apache \
--with-zlib \
--enable-bcmath \
--with-gd=/opt/freeware \
--with-ttf=/opt/freeware \
--with-jpeg-dir=/opt/freeware \
--with-imap=/usr1/src/imap \
--with-xml \
--with-ftp \
%if %{SSL} == 1
--with-ssl
%endif
During the make install phase i get this error :
+cd -
/opt/freeware/src/packages/BUILD/php-4.0.6
+ cp -p acconfig.h php_version.h
/var/opt/freeware/tmp/php-root/opt/freeware/include/php
+ mkdir -p /var/opt/freeware/tmp/php-root/opt/freeware/apache/libexec
+ cp .libs/libphp4.so.0
/var/opt/freeware/tmp/php-root/opt/freeware/apache/libexec/libphp4.so
cp: .libs/libphp4.so.0: No such file or directory
Bad exit status from /var/opt/freeware/tmp/rpm-tmp.30732 (%install)
In effects I don't have the library
I noted that in the php directory there is a file called ltconfig that
contains :
ltconfig I found :
# See if GNU ld supports shared libraries.
case $host_os in
aix3* | aix4*)
# On AIX, the GNU linker is very broken
ld_shlibs=no
cat EOF 12
*** Warning: the GNU linker, at least up to release 2.9.1, is reported
*** to be unable to reliably create shared libraries on AIX.
*** Therefore, libtool is disabling shared libraries support. If you
*** really care for shared libraries, you may want to modify your PATH
*** so that a non-GNU linker is found, and then restart.
EOF
;;
Is this assertion true ? I use gcc 2.9-aix43-010216
from Aix Toolbox
Thanks in advance
--
Edit bug report at: http://bugs.php.net/?id=14265edit=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 #14254 Updated: SQLERROR -439
ID: 14254 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Informix related Operating System: Solaris 8 PHP Version: 4.0.6 New Comment: a short script would not reproduce the conditions for recreating the failure. It happens when we have a lot of load and this with big scripts using lots of memory and sometimes timing out. If the timeout comes from the db connection being lost or vice versa is hard to say If we could isolate where in the php ifx interface callback functions are used we would be a step further in solving this. Previous Comments: [2001-11-27 12:57:34] [EMAIL PROTECTED] Can you please add a short PHP script with which you can reproduce this ? Also, please try PHP 4.1.0 (to be released very soon now) as it has some improvements to the threading which might actually fix this problem. (it was mentioned as one possibility in that mail you pointed to in the archives) I don't have informix installed or any knowledge how to set it up either so you need to help us in this. And I don't have much time to spend on this either so please be patient. --Jani [2001-11-27 12:36:25] [EMAIL PROTECTED] Similarly to Bugs 13459 and 8267 we do get error 439. on php 3.0.18 and 4.0.6 http://marc.theaimsgroup.com/?l=php-devm=97812975300057w=2 we do have support from ifx. they are prepared to help us here qote from ifx support I have received this case and I have looked through the case history. The situation appears to be as follows. Your network traffic has increased and that in turn brought about more timeout situations where an ESQL/C callback was used by your application (or by PHP). The -439 error indicates that unauthorized calls are included in that callback function. There are two ways to avoid getting the errors. 1. Tweak the system to increase performance to the point where the timeouts do not occur. 2. Fix the callback function code. Since you have indicated that you will not attempt number 1 we are left with number 2. Number 2 is the responsibility of the person that wrote the callback function, be that you or PHP. The only way that Informix can fix the problem is if the -439 is being given in error. At this time there is no indication that the -439 error is not correct but it is still a possibility. Unfortunately we cannot know whether or not the -439 error is erroneous or not until we know exactly how the callback function is being set up. So the next thing that must happen is that I get a small test case showing setting up a correct callback function that fails with this error. If you are writing the callback functions then we need to get PHP out of the picture and you need to provide me a very small ESQL/C test case that gives the same error. If the callback functions are contained in PHP then the only other option is to pursue an answer through Apache tech support and let them contact me when and if they find that the -439 is not correct. In that case they will be providing the test case. If PHP cannot be removed from the picture then you need to open a case with Apache as soon as possible. Given the nature of Apache this might not be a viable option and you may instead want to look at the PHP source yourself. -- end quote --- begin quote Both the -439 and the -25588 errors are occuring because of timeouts. Odds are that they are simply different symptoms of the same underlying problem and which error you get depends on timing of internal events. If you want to focus on performance tuning I can pass the case back to an engines engineer. This will only be brushing the problem under the carpet, however. If your application is not doing callbacks correctly then it will give this error any time that activity gets too high. Does your application provide the callback function or is that all built into PHP? -- end quote so now we have the chance to get rid of this annoying bug. I cnnot possibly plunge into the phpsourcecode to get the info the guy from ifx needs. If your are interested to get this thing sorted out this is the chance Edit this bug report at http://bugs.php.net/?id=14254edit=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 #13338 Updated: PATH_TRANSLATED variable incorrectly set in v4.0.5
ID: 13338 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 4.0.5 New Comment: Yes, the problem still exists: URL: http://luna.int.hq.jobpilot:8000/test.phtml/bla/fasel PHP Version: 4.1.0RC3 Zend Version: 1.1.0 PATH_TRANSLATED: /JobsAdverts/OnlineServer/web/de/bla/fasel Regards, Arno Previous Comments: [2001-11-21 18:47:04] [EMAIL PROTECTED] Can you try latest RC and see if the problem still exists http://www.php.net/~zeev/php-4.1.0RC3.tar.gz Feedback. [2001-09-17 05:32:43] [EMAIL PROTECTED] Hi, between version 4.0.4 and 4.0.5 the setting of the PATH_TRANSLATED variable changed. In version 4.0.4, the following URL http://www1.jobpilot.de/test.phtml/bla/fasel resulted in the following PATH_TRANSLATED value: /JobsAdverts/OnlineServer/web/de/test.phtml (which is the correct script file name). in 4.0.5, the same URL results in the following value: /JobsAdverts/OnlineServer/web/de/bla/fasel which does not look right. According to the documentation, PATH_TRANSLATED is the Filesystem- (not document root-) based path to the current script, after the server has done any virtual-to-real mapping. BTW. the documentation should make it clear what is the difference between PATH_TRANSLATED and SCRIPT_FILENAME - from to the current explanation, I don't understand it. BTW we are using Apache 1.3.12. Best Regards, Arno Schaefer Edit this bug report at http://bugs.php.net/?id=13338edit=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 #14229 Updated: function virtual
ID: 14229 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Apache related Operating System: freebsd 4.3-stable PHP Version: 4.0.6 New Comment: The same result Previous Comments: [2001-11-26 10:33:28] [EMAIL PROTECTED] As it seems you're able to update this one, let's keep this open then. I'll bogus the other one. Now, please try the PHP 4.1.0 (not yet officially released) from: http://download.php.net/~zeev/php-4.1.0.tar.gz and let us know whether this happens with it or not. --Jani [2001-11-26 09:15:12] [EMAIL PROTECTED] I cannot update old report becaus of bug in your bugreport script. In previous report I did not suplied password so on attempts to update it I got message The password you supplied was incorrect. Something went wrong updating the database. [2001-11-26 08:50:50] [EMAIL PROTECTED] Please do not refile a bug report for a problem you already filed. Update the old report instead (which just got closed due to no feedback). Derick [2001-11-26 08:47:48] [EMAIL PROTECTED] Calling the function virtual with relative path as a parameter changes current working dirrectory for the calling script. Example follows: !--uuu.php-- ?php echo getcwd(); virtual(ssi/uuu.html); echo getcwd(); ? !--ssi/uuu.html-- h4ssi/uuu.html/h4 Output is: /usr/home/project/public_html/mb ssi/uuu.html /usr/home/project/public_html/mb/ssi Edit this bug report at http://bugs.php.net/?id=14229edit=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] [PATCH] Valid syntax for array creation from form elements
This is a re-posting. I sent this a few days ago and got no response, which wasn't exactly what I had in mind. Following is the original message: I'd like to patch PHP to allow for an XHTML-valid syntax for creating PHP arrays from HTML elements 'input' (groups of type=checkbox) and 'select' (multiple=multiple). Square brackets are not allowed in XHTML identifiers, so the current syntax name=someName[] or name=someName[someKey] is not valid. Square brackets are also not allowed in ECMAScript identifiers (e.g. variable names) or directly in CSS selectors. I propose a simple, valid alternative syntax, perhaps something like name=someName__ or name=someName__someKey__. I'd like to get feedback on the likelihood of that conflicting with any established practices or conventions (I know it would work fine for me), or suggestions of a better syntax. I'd also like to get a little guidance on exactly how to proceed with submitting such a patch. As far as I can see this would only require modifications to php_variables.c, rfc1867.c, and type.c. When responding to this thread, please CC me because I am not subscribed to the list. Thanks, Jesse McCarthy -- 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] C++ in extension?
Hello everyone. Can anybody tell me why I get an Call to undefined function when compiling a module using a C++ compiler (made a small test - it works fine when renaming the extension to *.c ... ). There are no make errors. The *only* error is that PHP seams unable to find the function when compiled using C++. Isn't it possible to do C++ in PHP extensions?!?!? BTW: I'm using gcc on a Linux RH7.2 -thanx 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]
Re: [PHP-DEV] C++ in extension?
LK Can anybody tell me why I get an Call to undefined function LK when compiling a module using a C++ compiler (made a small test LK - it works fine when renaming the extension to *.c ... ). There LK are no make errors. The *only* error is that PHP seams unable LK to find the function when compiled using C++. Isn't it possible LK to do C++ in PHP extensions?!?!? BTW: I'm using gcc on a Linux LK RH7.2 -thanx Yes, it's possible to do C++. I think you should use extern C on functions that should be used from PHP, since PHP is C program and doesn't know about C++ name mangling. I think wrapping all PHP macros, function defs, PHP includes, etc. in extern C would help. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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 #3248 Updated: mail function putting wrong timezone info in message header?
ID: 3248 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old Status: Analyzed Status: Duplicate Bug Type: Mail related Operating System: Windows NT PHP Version: 4.0 Beta 3 Assigned To: hholzgra New Comment: dup of #8909 Previous Comments: [2001-11-22 18:07:20] [EMAIL PROTECTED] Not sure if it helps, but I have a nearly untested patch that computes the offset using the diff between php_localtime_r() and php_gmtime_r(). I never understood where _timezone came from anyway. [2000-07-25 21:26:20] [EMAIL PROTECTED] implementation for mail on microsoft platforms is in win32/sendmail.c and in there is generation code for generating a Date: header if none was supplied by mail() function ( see function PostHeader() ) [2000-07-25 20:27:20] [EMAIL PROTECTED] As far as I can tell from the source code, PHP is not responsible for generating the email message headers. Do other messages generated by the same server have the correct timezone information? [2000-01-18 19:29:30] [EMAIL PROTECTED] Not sure if this is really a PHP problem or just Microsoft at work, but sending email using the mail function seems to give incorrect timezone info in the Date: header. eg: Received: from becks by macs.wn.bcl.co.nz; Wed, 19 Jan 2000 13:11:34 +1300 (NZDT) (in this case becks=NT, macs=Unix - +1300 NZDT is correct) Message-ID: [EMAIL PROTECTED] Date: Wed, 19 Jan 2000 13:11:35 -1200 -1200 is wrong. The NT timezone is set to +12:00 Auckland/Wellington, with Daylight saving enabled. Edit this bug report at http://bugs.php.net/?id=3248edit=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] C++ in extension?
I tried it but it still doesn't work. Do you have an example (just a small one :-)? - Lars Stanislav Malyshev [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... LK Can anybody tell me why I get an Call to undefined function LK when compiling a module using a C++ compiler (made a small test LK - it works fine when renaming the extension to *.c ... ). There LK are no make errors. The *only* error is that PHP seams unable LK to find the function when compiled using C++. Isn't it possible LK to do C++ in PHP extensions?!?!? BTW: I'm using gcc on a Linux LK RH7.2 -thanx Yes, it's possible to do C++. I think you should use extern C on functions that should be used from PHP, since PHP is C program and doesn't know about C++ name mangling. I think wrapping all PHP macros, function defs, PHP includes, etc. in extern C would help. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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 #14266: serialize() doesn't work correcty
From: [EMAIL PROTECTED] Operating system: Debian Linux PHP version: 4.1.0 PHP Bug Type: Scripting Engine problem Bug description: serialize() doesn't work correcty Consider following simple script. It's pretty obvious that serialize() does not work correctly (at least not as expected). ?php $x = new stdClass(); $x-x = $x; $s = serialize($x) . \n; echo test on original: ; // OK $x-a = str; echo $x-x-a . \n; $o = unserialize($s); echo test on unserialized object: ; // not OK $o-a = str; echo $o-x-a . \n; ? -- Edit bug report at: http://bugs.php.net/?id=14266edit=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 #13221 Updated: php_gd.dll not runnig
ID: 13221 Updated by: sander Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: GD related Operating System: Windows 98 PHP Version: 4.0.6 New Comment: The php_gd.dll of 4.0.6 uses GD 2.0.1 which is still beta. Use the php_gd.dll from PHP-4.0.5 (which uses 1.8.?) and everything should work fine. This is probably not a bug in PHP. Please wait until GD 2.0 final versoin will be released. Previous Comments: [2001-09-09 23:21:03] [EMAIL PROTECTED] Hi, php_gd.dll in 4.0.6 Win32 bin distribution is not running. PHP is normaly running. When I uncomment ;extension php_gd.dll, I get abnormal program termination. When I downgrade to 4.0.4 php_gd.dll is running OK. MB Edit this bug report at http://bugs.php.net/?id=13221edit=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] C++ in extension?
Here's the code. It would really help me a lot if anyone knows the way to
fix it.
thanx
Lars Knudsen
Stanislav Malyshev [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
LK Can anybody tell me why I get an Call to undefined function
LK when compiling a module using a C++ compiler (made a small test
LK - it works fine when renaming the extension to *.c ... ). There
LK are no make errors. The *only* error is that PHP seams unable
LK to find the function when compiled using C++. Isn't it possible
LK to do C++ in PHP extensions?!?!? BTW: I'm using gcc on a Linux
LK RH7.2 -thanx
Yes, it's possible to do C++.
I think you should use extern C on functions that should be used from
PHP, since PHP is C program and doesn't know about C++ name mangling. I
think wrapping all PHP macros, function defs, PHP includes, etc. in extern
C would help.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115
begin 666 newfunc.h
M(VEF;F1E9B!02%!?3D571E5.0U1)3TY?2 T*( C95F:6YE(%!(4%].15=
M54Y#5$E/3E](#0IE'1EFX@(D,B('L*(!02%!?1E5.0U1)3TXH;F5W9G5N
M8W1I;VXQ*3L-B @4$A07T953D-424].*'1I;65B;W@Q9V5N97)I8RD[GT*
*(V5N9EF#0H-@``
`
end
begin 666 newfunc.cpp
M(VEN8VQU94@/'-T9EO+F@^#0H*97AT97)N()#(B![B-I;F-L=61E()P
M:' N:(-B-I;F-L=61E()P:'!?:6YI+F@B#0HC:6YC;'5D92 B;F5W9G5N
M8RYH(@I]F9U;F-T:6]N7V5N=')Y(YE=V9U;F-?9G5N8W1I;VYS7V5N=')Y
M6UT@/2 -GL-@E02%!?1D4H;F5W9G5N8W1I;VXQ+ @($Y53$PI#0H)4$A0
M7T9%*'1I;65B;W@Q9V5N97)I8RP@(!.54Q,*0T*7M.54Q,+!.54Q,+!.
M54Q,?0T*?3L-@T*F5N9%]M;V1U;5?96YTGD@;F5W9G5N8U]M;V1U;5?
M96YTGD@/2 -GL-@DB;F5W9G5N8R(L( @( @( @( @( @( @( O
M*B!N86UE( @( @( @( J+PT*6YE=V9U;F-?9G5N8W1I;VYS7V5N=')Y
M+ @( @(\J(9U;F-T:6]N7V5N=')Y(HO#0H)3E5,3P@( @( @( @
M( @( @( @( @( @+RH@:6YI=EA;EZ871OB @*B\-@E.54Q,+ @
M( @( @( @( @( @( @( @( O*B!D97-TG5C=]R( @( J+PT*
M4Y53$PL( @( @( @( @( @( @( @( @(\J('-T87)T=7 @( @
M( @(HO#0H)3E5,3P@( @( @( @( @( @( @( @( @+RH@VAU
M=1O=VX@( @( @*B\-@E.54Q,+ @( @( @( @( @( @( @( @
M( O*B!I;F9O( @( @( @( J+PT*5-404Y$05)$7TU/1%5,15]04D]0
M15)42453#0I].PT*#0I$3$584$]25!Z96YD7VUO9'5L95]E;G1R2 J9V5T
M7VUO9'5L92AV;VED*2![(')E='5R;B F;F5W9G5N8U]M;V1U;5?96YTGD[
M('T-@H*97AT97)N()#(B!02%!?1E5.0U1)3TXH;F5W9G5N8W1I;VXQ*0T*
MPT*(!P=F%L(IAFQ+ J87)G,CL-@T*( O*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ+PT*( O*B!-86ME('-UF4@=AA=!W92!H879E('1W
M;R!AF=U;65N=',@( @( @( @( @( @( @( @( @( @( @( J
M+PT*( O*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ+PT*#0H@(EF(A!
M4D=?0T]53E0H:'0I($](#(I('L@5U)/3D=?4$%204U?0T]53E0[('T-@T*
M( O*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ+PT*( O*B!'970@=AE
M('1W;R!AF=U;65N=',@9G)O;2!T:4@87)G=6UE;G1S)R!L:7-T( @( @
M( @( @( @( @( @( J+PT*( O*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ+PT*#0H@(EF(AG971087)A;65T97)S*AT+#(L)F%R9S$L)F%R
M9S(I/3U04E,55)%*2![(%=23TY'7U!!4D%-7T-/54Y4.R!]#0H-B @+RHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*B\-B @+RH@36%K92!S=7)E('=E
M(AA=F4@)VQO;FG('9A;'5ER @( @( @( @( @( @( @( @( @
M( @( @( @( @*B\-B @+RHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*B\-B @( T*(!C;VYV97)T7W1O7VQO;FH87)G,2D[#0H@(-O;G9EG1?
M=]?;]N9RAAFR*3L-@T*( O*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ+PT*( O*B!#86QC=6QA=4@87)G,2 K(%R9S(@( @( @( @( @
M( @( @( @( @( @( @( @( @( @( @( @( J+PT*( O*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ+PT*#0H@(%)%5%523E],3TY'*%R
M9S$M/G9A;'5E+FQV86P@*R!AFR+3YV86QU92YL=F%L*3L-GT-@H*97AT
M97)N()#(B!02%!?1E5.0U1)3TXH=EM96)O#%G96YEFEC*0T*PT*(!C
M:%R('1E'0Q6UT@/2 B25L;\B.PH-B O*B!I9B H05)'7T-/54Y4*AT
M*2 A/2 P*2![(%=23TY'7U!!4D%-7T-/54Y4.R!]*B\-@H@(\J*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHO#0H@(\J($-A;-U;%T92!AFQ(L@
M87)G,B @( @( @( @( @( @( @( @( @( @( @( @( @( @
M( @( @(HO#0H@(\J*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ
M*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHJ*BHO#0H*
@(!215154DY?4U1224Y'*'1E'0Q+#$I.PT*?0T*#0H`
`
end
begin 666 Makefile.dat
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C#0HC($=E;F5R:6,@36%K969I;4@9F]R(%!(4!D:6YA
M;6EC86QL2!L;V%D86)L92!M;V1U;5S(,-B,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(PT*#0I#
M0R @( @( @( @( @/2!G8V,*#0HC(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,-B,@5VAEF4@
M=\@'5T(%!(4=S(1I;F%M:6-A;QY(QO861A8FQE(UO9'5L97,@( @
M( @(PT*(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
M(R,C(R,C(R,C(R,C(R,C(R,C#0H-E!(4%]-3T153$5?4$%42 ](]UW(O
M;]C86POAP-]M;V1U;5S#0H-B,C(R,C(R,C(R,C(R,C(R,C(R,C(R,C
[PHP-DEV] Bug #14266 Updated: serialize() doesn't work correcty
ID: 14266 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Scripting Engine problem Operating System: Debian Linux PHP Version: 4.1.0 New Comment: Circualar reference here: $x-x = $x; These dont work as expected at all. Bogus bug report as the lang isnt designed to support this. - James Previous Comments: [2001-11-28 08:32:48] [EMAIL PROTECTED] Consider following simple script. It's pretty obvious that serialize() does not work correctly (at least not as expected). ?php $x = new stdClass(); $x-x = $x; $s = serialize($x) . \n; echo test on original: ; // OK $x-a = str; echo $x-x-a . \n; $o = unserialize($s); echo test on unserialized object: ; // not OK $o-a = str; echo $o-x-a . \n; ? Edit this bug report at http://bugs.php.net/?id=14266edit=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 #13168 Updated: GD FONT path error
ID: 13168 Updated by: sander Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: GD related Operating System: windows PHP Version: 4.0.6 New Comment: Can you -try the PHP 4.1.0 when it's out (it will be released in a few days) -if it still doesn't work, provide a sample script? Previous Comments: [2001-09-06 04:15:05] [EMAIL PROTECTED] I found that the path could not use C: or D: to redirect the disk where the font file located. It means we can only use files on the same disk and use absolute path name to be used by GD lib. Edit this bug report at http://bugs.php.net/?id=13168edit=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 #14266 Updated: serialize() doesn't work correcty
ID: 14266 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Bogus Status: Open Bug Type: Scripting Engine problem Operating System: Debian Linux Old PHP Version: 4.1.0 PHP Version: 4.2.0-dev New Comment: Tested this with current cvs too. No better luck. Original and unserialized objects have different representation in memory. Previous Comments: [2001-11-28 08:38:01] [EMAIL PROTECTED] Circualar reference here: $x-x = $x; These dont work as expected at all. Bogus bug report as the lang isnt designed to support this. - James [2001-11-28 08:32:48] [EMAIL PROTECTED] Consider following simple script. It's pretty obvious that serialize() does not work correctly (at least not as expected). ?php $x = new stdClass(); $x-x = $x; $s = serialize($x) . \n; echo test on original: ; // OK $x-a = str; echo $x-x-a . \n; $o = unserialize($s); echo test on unserialized object: ; // not OK $o-a = str; echo $o-x-a . \n; ? Edit this bug report at http://bugs.php.net/?id=14266edit=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 #12402 Updated: Including GD support shuts down PWS
ID: 12402 Updated by: sander Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: GD related Operating System: Windows 98 SE PHP Version: 4.0.6 New Comment: PHP 4.0.6 uses GD 2.0 which is still beta. That might be the cause of this. Can you try the PHP 4.1.0 when it's out (it will be released in a few days)? Previous Comments: [2001-07-26 10:29:56] [EMAIL PROTECTED] I downloaded PHP 4.0.6 for Win32, full version (ZIP package, binary distribution), and installed it on PWS 4.0 for ISAPI invocation. Everything works fine except for GD library support: when I include the library in PHP.INI, and then an attempt is made to execute *any* PHP script under PWS (even ? phpinfo(); ?), the server process shuts down silently. No error log, no message box, no GPF fault display, not even a Blue Screen of Death. The server process (INETINFO.EXE) just disappears from the list of active processes, and any further request for HTML pages of any kind (not only PHP) fails with a Server not found error. I tried to execute PHP from the command line in order to check the problem, and the resulting HTML output shows a complaint about GD support not enabled on the build. Please note that this is a different message from a function not recognized error (I tried with and without GD invocation just to be sure). Could you please suggest what might be wrong with PHP or PWS? Or how to make PHP accept GD as a library (I thought dynamic DLLs dispensed with the need to recompile PHP). Edit this bug report at http://bugs.php.net/?id=12402edit=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 #14266 Updated: serialize() doesn't work correcty
ID: 14266 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Scripting Engine problem Operating System: Debian Linux PHP Version: 4.2.0-dev New Comment: Your creating a reference to itself this is not allowed. Therefore the bug is bogus, the behaviour is undefined. - James Previous Comments: [2001-11-28 08:38:38] [EMAIL PROTECTED] Tested this with current cvs too. No better luck. Original and unserialized objects have different representation in memory. [2001-11-28 08:38:01] [EMAIL PROTECTED] Circualar reference here: $x-x = $x; These dont work as expected at all. Bogus bug report as the lang isnt designed to support this. - James [2001-11-28 08:32:48] [EMAIL PROTECTED] Consider following simple script. It's pretty obvious that serialize() does not work correctly (at least not as expected). ?php $x = new stdClass(); $x-x = $x; $s = serialize($x) . \n; echo test on original: ; // OK $x-a = str; echo $x-x-a . \n; $o = unserialize($s); echo test on unserialized object: ; // not OK $o-a = str; echo $o-x-a . \n; ? Edit this bug report at http://bugs.php.net/?id=14266edit=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 #13617 Updated: wrong saved pictures
ID: 13617
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: GD related
Operating System: Windows 2000 Professional SP 2
PHP Version: 4.0.6
New Comment:
Have you tried the php_gd.dll from 4.0.5? If not, please do that.
And if that doesn't work, please make a SHORT sample script which reproduces your
problem and post it here.
Previous Comments:
[2001-10-10 09:54:43] [EMAIL PROTECTED]
?
#complete code
$Max_size = 100;
$unterverzeichnis = tn;
$anz_pic = 0;
$jn = file_exists($unterverzeichnis/.);
if ($jn != TRUE) {
mkdir($unterverzeichnis, 0700);
echo nicht vorhandender Ordner wurde erstellt.br;
}
if ($bild == ) {
$verzeichnis = dir();
while($imagefile = $verzeichnis-read()) {
if(strstr($imagefile,.jpg))
{
$src_img = imagecreatefromjpeg($imagefile);
if (imagesx($src_img) imagesy($src_img)) {
$new_w = 100;
$new_h = imagesy($src_img) / imagesx($src_img) * 100;
} else {
$new_h = 100;
$new_w = imagesx($src_img) / imagesy($src_img) * 100;
}
$dst_img = imagecreate($new_w,$new_h);
imagecopyresized($dst_img,$src_img,0,0,0,0,$new_w,$new_h,imagesx($src_img),imagesy($src_img));
imagejpeg($dst_img, $unterverzeichnis/$imagefile);
echo img src=$unterverzeichnis/$imagefilebr\n;
$anz_pic++;
echo Bild b$imagefile/b umgewandelt. (bereits $anz_pic
Stück)brbr\n;
}
}
$verzeichnis-close();
echo bVerzeichnis komplett umgewandelt/b;
} else {
$imagefile = $bild;
if(strstr($imagefile,.jpg))
{
$src_img = imagecreatefromjpeg($imagefile);
if (imagesx($src_img) imagesy($src_img)) {
$new_w = 100;
$new_h = imagesy($src_img) / imagesx($src_img) * 100;
} else {
$new_h = 100;
$new_w = imagesx($src_img) / imagesy($src_img) * 100;
}
$dst_img = imagecreate($new_w,$new_h);
imagecopyresized($dst_img,$src_img,0,0,0,0,$new_w,$new_h,imagesx($src_img),imagesy($src_img));
imagejpeg($dst_img, $unterverzeichnis/$imagefile);
echo img src=$unterverzeichnis/$imagefilebr\n;
echo Bild b$imagefile/b umgewandelt.brbr\n;
} else {
echo kein gültiges bild;
}
}
?
[2001-10-09 13:55:19] [EMAIL PROTECTED]
Can you post a sample script?
This might be a bug in GD 2.0 (just guessing). It's still a beta. You can try using
the php_gd.dll from the PHP-4.0.5 package (see http://www.php.net/downloads.php) with
PHP-4.0.6.
[2001-10-09 13:36:02] [EMAIL PROTECTED]
The GB-Libary has problem to save files (JPEG), i open any and make it small und some
pictures are black or driverent colors then the orginal pictures, this script has no
problems with 4.0.4PL1 only in 4.0.6
Edit this bug report at http://bugs.php.net/?id=13617edit=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 #14266 Updated: serialize() doesn't work correcty
ID: 14266
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Bogus
Status: Open
Bug Type: Scripting Engine problem
Operating System: Debian Linux
PHP Version: 4.2.0-dev
New Comment:
I dont' agree. Circular refferences can happen with
objects (using refferences). Sometimes they are
intentional. And serialize() doesn't completely ignore
this. Because it spits out:
O:8:stdClass:1:{s:1:x;O:8:stdClass:1:{s:1:x;R:2;}}
so it knows about circular refferences.
Now is there any reason why it doesn't generate instead
something like this:
O:8:stdClass:1:{s:1:x;R:1;}
I would understand if it completely ignores circular
references, but it doesn't. It just misbehaves.
Previous Comments:
[2001-11-28 08:41:04] [EMAIL PROTECTED]
Your creating a reference to itself this is not allowed.
Therefore the bug is bogus, the behaviour is undefined.
- James
[2001-11-28 08:38:38] [EMAIL PROTECTED]
Tested this with current cvs too. No better luck.
Original and unserialized objects have different
representation in memory.
[2001-11-28 08:38:01] [EMAIL PROTECTED]
Circualar reference here:
$x-x = $x;
These dont work as expected at all.
Bogus bug report as the lang isnt designed to support this.
- James
[2001-11-28 08:32:48] [EMAIL PROTECTED]
Consider following simple script. It's pretty obvious
that serialize() does not work correctly (at least not as
expected).
?php
$x = new stdClass();
$x-x = $x;
$s = serialize($x) . \n;
echo test on original: ; // OK
$x-a = str;
echo $x-x-a . \n;
$o = unserialize($s);
echo test on unserialized object: ; // not OK
$o-a = str;
echo $o-x-a . \n;
?
Edit this bug report at http://bugs.php.net/?id=14266edit=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] [PATCH] Valid syntax for array creation from form elements
Well .. there were discussion about this in the past or at leat within some bug reports and it seems its likely to getting changed really soon. Although ECMA doesn't allow it it works fine aith all current (modern ;) implementations to access identfieris with '[' or ']' in the name. For more information you may wan't to search the archive at http://marc.theaimsgroup.com/ . - Markus On Wed, Nov 28, 2001 at 08:10:21AM -0500, Jesse McCarthy wrote : This is a re-posting. I sent this a few days ago and got no response, which wasn't exactly what I had in mind. Following is the original message: I'd like to patch PHP to allow for an XHTML-valid syntax for creating PHP arrays from HTML elements 'input' (groups of type=checkbox) and 'select' (multiple=multiple). Square brackets are not allowed in XHTML identifiers, so the current syntax name=someName[] or name=someName[someKey] is not valid. Square brackets are also not allowed in ECMAScript identifiers (e.g. variable names) or directly in CSS selectors. I propose a simple, valid alternative syntax, perhaps something like name=someName__ or name=someName__someKey__. I'd like to get feedback on the likelihood of that conflicting with any established practices or conventions (I know it would work fine for me), or suggestions of a better syntax. I'd also like to get a little guidance on exactly how to proceed with submitting such a patch. As far as I can see this would only require modifications to php_variables.c, rfc1867.c, and type.c. When responding to this thread, please CC me because I am not subscribed to the list. Thanks, Jesse McCarthy -- 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] -- Please always Cc to me when replying to me on the lists. -- 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 #10514 Updated: Uploaded file not stored in upload_tmp_dir
ID: 10514
Updated by: sander
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: PHP options/info functions
Operating System: Linux server27.promotion-web.net
PHP Version: 4.0.4pl1
New Comment:
This is what Cardinal said about this in bug #10386
---
[2001-05-07 18:58:31] [EMAIL PROTECTED]
If you're expecting uploaded files to stay there, that won't happen. Once the file
has
been uploaded and the script finishes running, PHP will remove the file (Hence
'upload_tmp_dir'). In order to keep the file, you need to copy it to another
location.
---
Not a bug.
Previous Comments:
[2001-04-26 13:24:37] [EMAIL PROTECTED]
On the server, and according to phpInfo(), main PHP variables are:
Apache Version = Apache/1.3.19
Apache Release = 10319100
Apache API Version = 19990320
User/Group = nobody(99)/99
Loaded Modules = mod_php4, .
Session Support = enabled
session.auto_start = Off
upload_max_filesize = 100
upload_tmp_dir = ./tmp/
I'm running the script below; it's located in a directory where has been created a
directory tmp (so the path ./tmp/ is OK) with rights set to 777 (chmod):
HTML
HEADTITLEUpload Test/TITLE/HEAD
BODY
?
// Test Upload
//
// La première fois, action n'est pas renseigné
// = le formulaire est affiché
// A l'envoi du formulaire, action est renseigné
// = le script affiche les paramètres du fichier télé chargé
//et affiche le début du fichier
if ( !$action ) {
// Affichage du formulaire
echo form enctype=multipart/form-data action=.$PHP_SELF.
method=POST\n;
echo input type=hidden name=MAX_FILE_SIZE value=10\n;
echo Send this file: ;
echo input name=userfile type=file\n;
echo input type=hidden name=action value=show_me_the_file\n;
echo input type=submit value=Send File\n;
echo /form\n;
} else {
// Affichage des paramètres du fichier téléchargé
echo h2Size: $userfile_size/h2\n;
echo h2Type: $userfile_type/h2\n;
echo h2Name: $userfile_name/h2\n;
echo h2File: $userfile /h2\n;
// Listing du répertoire ./tmp
$dir='./tmp';
$handle=opendir($dir);
echo pPointeur de dossier: $handle\n;
echo brFichiers de $dir:\n;
while ($fic = readdir($handle)) {
echo br$fic\n;
}
closedir($handle);
echo br\n;
// Suppression des doubles slash dans le nom de fichier
$file=ereg_replace(//+,/,$userfile);
// Lecture et affichage du début du fichier
$fd=fopen($file,r) or die (Unable to open uploaded file!);
$data=fread($fd, MAX_SIZE);
fclose($fd);
echo Beginning of file: .substr($data, 0, 25);
}
?
/BODY
/HTML
!
The variables displayed are the one expected (user's file name, type, size), the temp
file has a coherent name (./tmp/phpxx)... but upload directory ./tmp remains
empty.
There is no error generated in error.log during PHP recovery of uploaded file. An
error occurs when the script try to access the file.
I've double-checked everything I could think of...
The problem exposed seems to be the same as the one posted with Bug id #10386.
Edit this bug report at http://bugs.php.net/?id=10514edit=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] [PATCH] Valid syntax for array creation from form elements
Bla. this should read 'the past or at least within' and 'its NOT likely to getting changed..' Sorry :-) - Markus On Wed, Nov 28, 2001 at 02:51:03PM +0100, Markus Fischer wrote : Well .. there were discussion about this in the past or at leat within some bug reports and it seems its likely to getting changed really soon. Although ECMA doesn't allow it it works fine aith all current (modern ;) implementations to access identfieris with '[' or ']' in the name. For more information you may wan't to search the archive at http://marc.theaimsgroup.com/ . - Markus On Wed, Nov 28, 2001 at 08:10:21AM -0500, Jesse McCarthy wrote : This is a re-posting. I sent this a few days ago and got no response, which wasn't exactly what I had in mind. Following is the original message: I'd like to patch PHP to allow for an XHTML-valid syntax for creating PHP arrays from HTML elements 'input' (groups of type=checkbox) and 'select' (multiple=multiple). Square brackets are not allowed in XHTML identifiers, so the current syntax name=someName[] or name=someName[someKey] is not valid. Square brackets are also not allowed in ECMAScript identifiers (e.g. variable names) or directly in CSS selectors. I propose a simple, valid alternative syntax, perhaps something like name=someName__ or name=someName__someKey__. I'd like to get feedback on the likelihood of that conflicting with any established practices or conventions (I know it would work fine for me), or suggestions of a better syntax. I'd also like to get a little guidance on exactly how to proceed with submitting such a patch. As far as I can see this would only require modifications to php_variables.c, rfc1867.c, and type.c. When responding to this thread, please CC me because I am not subscribed to the list. Thanks, Jesse McCarthy -- 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] -- Please always Cc to me when replying to me on the lists. -- 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] -- Please always Cc to me when replying to me on the lists. -- 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 #8848 Updated: open_basedir = /dir/incl validates /dir/include and so on
ID: 8848 Updated by: sander Reported By: [EMAIL PROTECTED] Status: Open Bug Type: PHP options/info functions Operating System: Solaris 7 PHP Version: 4.0.4pl1 New Comment: What's wrong with that? You just need to use a trailing slash! Can anyone tell me wether this is expected (but undocumented) behaviour or a bug? Previous Comments: [2001-01-22 21:53:29] [EMAIL PROTECTED] Setting open_basedir = /dir/incl allows access to /dir/include or /dir/incls or similar Edit this bug report at http://bugs.php.net/?id=8848edit=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] V_OPEN and memory
What happened to V_OPEN/V_GETCWD/... I had them in 4.0.4pl1, but they are gone in 4.0.6 ??? /Thomas -- 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 #14266 Updated: serialize() doesn't work correcty
ID: 14266
Updated by: zimt
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Debian Linux
PHP Version: 4.2.0-dev
New Comment:
Behaviour of Circular / Selfreferencing objects is not defined.
you could try to do a workarround
by using defining __sleep() and __wakeup()
in your class, which are called when the object is serialized / unserialized, and
could unset those self-references.
but you realy should do those.. if you dont destroy all of those references, you will
get memory leaks!
regards, Peter Petermann
Previous Comments:
[2001-11-28 08:43:47] [EMAIL PROTECTED]
I dont' agree. Circular refferences can happen with
objects (using refferences). Sometimes they are
intentional. And serialize() doesn't completely ignore
this. Because it spits out:
O:8:stdClass:1:{s:1:x;O:8:stdClass:1:{s:1:x;R:2;}}
so it knows about circular refferences.
Now is there any reason why it doesn't generate instead
something like this:
O:8:stdClass:1:{s:1:x;R:1;}
I would understand if it completely ignores circular
references, but it doesn't. It just misbehaves.
[2001-11-28 08:41:04] [EMAIL PROTECTED]
Your creating a reference to itself this is not allowed.
Therefore the bug is bogus, the behaviour is undefined.
- James
[2001-11-28 08:38:38] [EMAIL PROTECTED]
Tested this with current cvs too. No better luck.
Original and unserialized objects have different
representation in memory.
[2001-11-28 08:38:01] [EMAIL PROTECTED]
Circualar reference here:
$x-x = $x;
These dont work as expected at all.
Bogus bug report as the lang isnt designed to support this.
- James
[2001-11-28 08:32:48] [EMAIL PROTECTED]
Consider following simple script. It's pretty obvious
that serialize() does not work correctly (at least not as
expected).
?php
$x = new stdClass();
$x-x = $x;
$s = serialize($x) . \n;
echo test on original: ; // OK
$x-a = str;
echo $x-x-a . \n;
$o = unserialize($s);
echo test on unserialized object: ; // not OK
$o-a = str;
echo $o-x-a . \n;
?
Edit this bug report at http://bugs.php.net/?id=14266edit=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 #14266 Updated: serialize() doesn't work correcty
ID: 14266
Updated by: zimt
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Debian Linux
PHP Version: 4.2.0-dev
New Comment:
sorry, i wanted to write:
you realy should *NOT*...
Previous Comments:
[2001-11-28 08:59:04] [EMAIL PROTECTED]
Behaviour of Circular / Selfreferencing objects is not defined.
you could try to do a workarround
by using defining __sleep() and __wakeup()
in your class, which are called when the object is serialized / unserialized, and
could unset those self-references.
but you realy should do those.. if you dont destroy all of those references, you will
get memory leaks!
regards, Peter Petermann
[2001-11-28 08:43:47] [EMAIL PROTECTED]
I dont' agree. Circular refferences can happen with
objects (using refferences). Sometimes they are
intentional. And serialize() doesn't completely ignore
this. Because it spits out:
O:8:stdClass:1:{s:1:x;O:8:stdClass:1:{s:1:x;R:2;}}
so it knows about circular refferences.
Now is there any reason why it doesn't generate instead
something like this:
O:8:stdClass:1:{s:1:x;R:1;}
I would understand if it completely ignores circular
references, but it doesn't. It just misbehaves.
[2001-11-28 08:41:04] [EMAIL PROTECTED]
Your creating a reference to itself this is not allowed.
Therefore the bug is bogus, the behaviour is undefined.
- James
[2001-11-28 08:38:38] [EMAIL PROTECTED]
Tested this with current cvs too. No better luck.
Original and unserialized objects have different
representation in memory.
[2001-11-28 08:38:01] [EMAIL PROTECTED]
Circualar reference here:
$x-x = $x;
These dont work as expected at all.
Bogus bug report as the lang isnt designed to support this.
- James
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=14266
Edit this bug report at http://bugs.php.net/?id=14266edit=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 #14266 Updated: serialize() doesn't work correcty
ID: 14266
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Debian Linux
PHP Version: 4.2.0-dev
New Comment:
Ok, I tested a little bit more
and found that when calling serialize() like serialize($x)
it works.
I know about leaks, but those leaks don't kill me (yet).
And btw. Circular references work as expected. There is
nothing so undefined about them in php. They work quite
logically.
Previous Comments:
[2001-11-28 09:01:05] [EMAIL PROTECTED]
sorry, i wanted to write:
you realy should *NOT*...
[2001-11-28 08:59:04] [EMAIL PROTECTED]
Behaviour of Circular / Selfreferencing objects is not defined.
you could try to do a workarround
by using defining __sleep() and __wakeup()
in your class, which are called when the object is serialized / unserialized, and
could unset those self-references.
but you realy should do those.. if you dont destroy all of those references, you will
get memory leaks!
regards, Peter Petermann
[2001-11-28 08:43:47] [EMAIL PROTECTED]
I dont' agree. Circular refferences can happen with
objects (using refferences). Sometimes they are
intentional. And serialize() doesn't completely ignore
this. Because it spits out:
O:8:stdClass:1:{s:1:x;O:8:stdClass:1:{s:1:x;R:2;}}
so it knows about circular refferences.
Now is there any reason why it doesn't generate instead
something like this:
O:8:stdClass:1:{s:1:x;R:1;}
I would understand if it completely ignores circular
references, but it doesn't. It just misbehaves.
[2001-11-28 08:41:04] [EMAIL PROTECTED]
Your creating a reference to itself this is not allowed.
Therefore the bug is bogus, the behaviour is undefined.
- James
[2001-11-28 08:38:38] [EMAIL PROTECTED]
Tested this with current cvs too. No better luck.
Original and unserialized objects have different
representation in memory.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=14266
Edit this bug report at http://bugs.php.net/?id=14266edit=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] V_OPEN and memory
At 02:57 PM 11/28/2001 +0100, Thomas Wentzel wrote: What happened to V_OPEN/V_GETCWD/... I had them in 4.0.4pl1, but they are gone in 4.0.6 ??? They are now VCWD_OPEN() and VCWD_GETCWD(). The previous ones clashed with third party libraries. Andi -- 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] C++ in extension?
correction: it seams that using the 'string' from stdlib makes the difference. If I: #include string using namespace std; ... it doesnt work - but only if I *use* the string class strange. anyone got any Idea why? - Lars Stanislav Malyshev [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... LK Can anybody tell me why I get an Call to undefined function LK when compiling a module using a C++ compiler (made a small test LK - it works fine when renaming the extension to *.c ... ). There LK are no make errors. The *only* error is that PHP seams unable LK to find the function when compiled using C++. Isn't it possible LK to do C++ in PHP extensions?!?!? BTW: I'm using gcc on a Linux LK RH7.2 -thanx Yes, it's possible to do C++. I think you should use extern C on functions that should be used from PHP, since PHP is C program and doesn't know about C++ name mangling. I think wrapping all PHP macros, function defs, PHP includes, etc. in extern C would help. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] C++ in extension?
At 03:48 PM 11/28/2001 +0100, Lars Knudsen wrote: correction: it seams that using the 'string' from stdlib makes the difference. If I: #include string using namespace std; ... it doesnt work - but only if I *use* the string class strange. anyone got any Idea why? Possibly because you're not linking PHP with the C++ library? If you're using plain C++ you don't need to but if you're using C++ library functions including stuff from namespace std I think you're supposed to link with it. A good idea would also to do an nm on your extension and see if it has C++ stuff. Any function which is mangled weirdly is C++. Andi -- 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 #14252 Updated: build fails using AIX C 4.4 on AIX 4.3.3 box
ID: 14252
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Compile Failure
Operating System: AIX 4.3.3
PHP Version: 4.0CVS-2001-11-27
Old Assigned To: sniper
Assigned To:
New Comment:
the correct name of the compiler is IBM C for AIX version 4.4.
sorry if it makes any diference..
Previous Comments:
[2001-11-27 12:51:14] [EMAIL PROTECTED]
I will try with a AIX 4.3.3 account I got.
[2001-11-27 12:06:15] [EMAIL PROTECTED]
Hi i am having trouble compiling the latest CVS with AIX C 4.4 on AIX 4.3.3. The same
problem have occured with 4.0.6 and a few snapshots i've downloaded. Have seen this
problem related in some lists but no solution was provided.
Initiali i've used the --with-ingres directive too, but i'm trying the simplest
configuration possible first :
Thats my .configure line :
/paulera/downloads/php4-200111270600 ./configure
--with-apxs=/usr/local/apache/bin/apxs
checking for a BSD compatible install... ./install-sh -c
checking whether build environment is sane... yes
checking for mawk... no
checking for gawk... no
checking for nawk... nawk
checking whether make sets ${MAKE}... yes
Updated php_version.h
checking whether to enable maintainer-specific portions of Makefiles... no
checking build system type... powerpc-ibm-aix4.3.3.0
checking host system type... powerpc-ibm-aix4.3.3.0
checking for mawk... (cached) nawk
checking for bison... no
checking for byacc... no
configure: WARNING: You will need bison if you want to regenerate the PHP parsers.
(that's the only warning i have during configure)
checking for gcc... no
( ... no more errors or warnings til the end ...)
during make, it's going fine until :
/bin/sh ../libtool --silent --mode=compile cc -DHAVE_CONFIG_H -I. -I.
-I../main-DAIX=43 -DUSE_PTHREAD_SERIALIZED_ACCEPT -DAIX_BIND_PROCESSOR
-DMOD_SSL=208105 -DUSE_HSREGEX -DEAPI -DEAPI_MM -DUSE_EXPAT -I../TSRM -g -prefer-pic
-c -o zend_qsort.lo `test -f zend_qsort.c || echo './'`zend_qsort.c
zend_qsort.c, line 33.18: 1506-025 (S) Operand must be a modifiable lvalue.
zend_qsort.c, line 34.18: 1506-025 (S) Operand must be a modifiable lvalue.
zend_qsort.c, line 39.18: 1506-025 (S) Operand must be a modifiable lvalue.
zend_qsort.c, line 40.18: 1506-025 (S) Operand must be a modifiable lvalue.
make: 1254-004 O código de erro do último comando é 1.
Pare.
make: 1254-004 O código de erro do último comando é 1.
If you need more information please ask. I'm fighting this problem for a week, reading
everything i find on the net, bu couldn't find a solution.
Thanks for your attention
Paulo
Edit this bug report at http://bugs.php.net/?id=14252edit=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 #14267: Ereg doesn't work on following
From: [EMAIL PROTECTED]
Operating system: Linux Redhat 7.1
PHP version: 4.0CVS-2001-11-28
PHP Bug Type: *Regular Expressions
Bug description: Ereg doesn't work on following
Dear PHP.net,
i have this part of script:
if (Ereg(^[a-zA-Z0-9_]{1,8}$, $login)) {
.
.
And this doesn't work correctly on any string containing character
'c'.
P.S. I am using PHP Version 4.0.4pl1
System: Linux porky.devel.redhat.com 2.2.17-8smp #1 SMP Fri Nov 17 16:12:17
--
Edit bug report at: http://bugs.php.net/?id=14267edit=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 #14267 Updated: Ereg doesn't work on following
ID: 14267
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: *Regular Expressions
Operating System: Linux Redhat 7.1
PHP Version: 4.0CVS-2001-11-28
New Comment:
This works for me (on both 4.1.0RC3 and 4.2.0dev):
?php
$login = blact;
if (Ereg(^[a-zA-Z0-9_]{1,8}$, $login)) {
echo OK;
}
?
output:
OK
Please try the latest RC from www.php.net/~zeev/ and reopen if you still have the
problem. However, I don't think this is a bug in PHP, but rather in your code.
Derick
Previous Comments:
[2001-11-28 10:14:15] [EMAIL PROTECTED]
Dear PHP.net,
i have this part of script:
if (Ereg(^[a-zA-Z0-9_]{1,8}$, $login)) {
.
.
And this doesn't work correctly on any string containing character 'c'.
P.S. I am using PHP Version 4.0.4pl1
System: Linux porky.devel.redhat.com 2.2.17-8smp #1 SMP Fri Nov 17 16:12:17
Edit this bug report at http://bugs.php.net/?id=14267edit=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] XML and PHP in same document: Config suggestions?
I've come up with a two-part setup in Apache to enable special file
extensions for processing PHP in XML documents. I'm wondering what you
guys think, and what I can do to improve the setup. (This is based on
the PHPDEV development server from www.firepages.com.au .)
Here's the first part, lines for a .htaccess file in c:/phpdev/www :
[CODE]
AddType application/x-httpd-php .pxml .pxsl .pxhtml .pmml .psvg
php_value auto_prepend_file c:/phpdev/www/mimeOverride.php
# Added to force the document to allow for multiple mimetypes.
#Alex Vincent added 11-26-01
php_value short_open_tag off
# Added to force ?php...? instead of ?...?; assists with XML
documents and XML processing instructions.
[/CODE]
The second part is the mimeOverride.php file I referenced earlier:
[CODE]
?php
$extension = strrchr($SCRIPT_NAME, .);
switch ($extension) {
case .pxml:
header(Content-type: text/xml);
break;
case .pxsl:
header(Content-type: text/xsl);
break;
case .pmml:
header(Content-type: application/mathml+xml);
break;
case .psvg:
header(Content-type: image/svg+xml);
break;
case .pxhtml:
switch ($mimeType) {
case text/xml:
case application/xml:
case application/xhtml+xml:
header(Content-type: $mimeType);
break;
}
break;
}
?
[/CODE]
Anyone care to suggest additional mime-types and file extensions, fix
bugs in the code, or streamline it?
--
[i]The first step to confirming there is a bug in someone else's work
is confirming there are no bugs in your own.[/i]
-- Alexander J. Vincent, June 30, 2001
http://www.jslab.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] Re: C++ in extension?
I've written up a small howto on the subject and I can send it along if you
like. The process described in the document works fine for PHP 4.0.6,
although it's a little bit different for the 4.1.0RCs and the final. (There
seemed to have been problems with the build process in 4.0.6 that made
using C++ tricky.)
Basically, when I'm using C++ with PHP, I write the C++ classes and such
and make an interface to PHP in C. Works pretty well for what I've done so
far.
Here's the basic idea (at least for 4.0.6):
0. Use ext_skel to set things up. We'll call the new module yourmodule.
1. Open up the config.m4 file created and fix things up like the following:
PHP_ARG_ENABLE(yourmodule, whether to enable yourmodule support,
[ --enable-yourmodule Enable yourmodule support]
)
if test $PHP_YOURMODULE == yes; then
PHP_EXTENSION(yourmodule, $ext_shared)
PHP_REQUIRE_CXX()
fi
2. Open up the Makefile.in file and set it up something like this:
LTLIBRARY_NAME= libyourmodule.la
LTLIBRARY_SOURCES = yourmodule.c
LTLIBRARY_SOURCES_CPP = yourmodulecpp.cpp
LTLIBRARY_SHARED_NAME = yourmodule.la
LTLIBRARY_SHARED_LIBADD = $(YOURMODULE_SHARED_LIBADD)
LTLIBRARY_OBJECTS_X = yourmodulecpp.lo
include $(top_srcdir)/build/dynlib.mk
yourmodule.c will have the stuff that talks to PHP, like the PHP_FUNCTION()
calls an such.
yourmodulecpp.cpp will have all of the C++ stuff. It doesn't talk to PHP
directly, it goes through yourmodule.c. (From what I can tell, you can't
name them both yourmodule.c/cpp. Thinks break.)
3. Set up your C++ header file something like this:
#ifndef __YOURMODULECPP_H__
#define __YOURMODULECPP_H__
#ifdef __cplusplus
extern C {
#endif
#include string
#ifdef __cplusplus
}
#endif
class MyClass
{
private:
string itsString;
public:
MyClass(string);
~MyClass();
const string getString();
void setString(const string);
};
extern C const char* useClass(const char* incoming);
#endif
So basically, wrap C++ stuff in extern C. useClass() is just a simple
function you can access from C. This example is of course extremely
simplistic, but just as an example, it'll do. Plus, it'll show off the
standard C++ string library, and if it works for you, then it'll prove that
you've got C++ working with PHP.
4. Next, yourmodulecpp.cpp:
#include yourmodulecpp.h
MyClass::MyClass(string incoming)
{
itsString = incoming;
}
MyClass::~MyClass()
{
/* not much here, just a default destructor */
}
const string MyClass::getString()
{
return itsString;
}
void MyClass::setString(const string incoming)
{
itsString = incoming;
}
extern C const char* useClass(const char* incoming)
{
MyClass blah(incoming);
return blah.getString().c_str();
}
Again, very simple: useClass just takes in a C-like string, instantiates a
MyClass object, calls the MyString::getString() function from the object
and returns a C-like string.
5. php_yourmodule.h shouldn't have to be changed too much, if at all.
yourmodule.c should include a PHP_FUNCTION() call something like this:
PHP_FUNCTION(yourmodule)
{
pval **arg;
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, arg) ==
FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_string_ex(arg);
RETURN_STRING(useClass((*arg)-value.str.val), 1);
}
So basically, take a string from PHP, convert it to a C-like string, pass
it to the useClass() function where it will go through the MyClass object
back in yourmodulecpp.cpp and go through the standard C++ string class, get
returned to C as a C string, then get returned to PHP. Nothing much really
happens, but if it all works, it'll prove C++ is working with C and PHP.
6. Run buildconf in the root PHP directory. When running configure, add a
--enable-yourmodule argument. Run make clean and make.
Now, in PHP 4.0.6, I had problems with the actual build process.
Eventually, make could die and start spitting errors about not being able
to find references to the functions in the standard C++ string library.
This was to be expected, as the linking was being done by the linker using
C semantics, not C++.
To fix this, run the make until it dies. When it does, open up
config_vars.mk in the PHP root directory and change the line that reads
CC=gcc
to
CC=g++
and run make again. Everything should link now and you should be left with
a useable php binary. PHP 4.1.0 doesn't seem to have this problem.
By running a script like:
?php print yourmodule(hello world); ?
you should come up with the output
hello world
Of course, if this works, then the C++ extension worked and all is well.
Getting things to work with apache takes a bit more
[PHP-DEV] Bug #14268: HEADER keyword does not work in imap_search()
From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.4-STABLE
PHP version: 4.0.6
PHP Bug Type: IMAP related
Bug description: HEADER keyword does not work in imap_search()
PHP 4.0.6
'./configure' '--with-apxs=/usr/local/sbin/apxs'
'--with-config-file-path=/usr/local/etc' '--enable-versioning'
'--with-system-regex' '--disable-debug' '--enable-track-vars'
'--without-gd' '--without-mysql' '--with-gd=/usr/local'
'--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local'
'--with-png-dir=/usr/local' '--with-zlib' '--with-mcrypt=/usr/local'
'--with-mhash=/usr/local' '--with-imap=/usr/local'
'--with-mysql=/usr/local' '--with-sybase=/usr/local'
'--with-ldap=/usr/local' '--with-xml' '--with-expat-dir=/usr/local'
'--with-sablot=/usr/local' '--with-expat-dir=/usr/local' '--enable-ftp'
'--with-curl=/usr/local' '--with-gettext=/usr/local'
'--with-iconv=/usr/local' '--with-pspell=/usr/local'
'--with-ming=/usr/local' '--enable-sockets' '--enable-trans-sid'
'--with-iconv=/usr/local' '--prefix=/usr/local' 'i386--freebsd4.4'
imap c-client: version 2001 release candidate 1 (from FreeBSD ports
current)
imap server: Courier-IMAP 1.3.12
1. I login using telnet client on port 143 of my IMAP server:
me: a001 LOGIN username password
server: a001 OK LOGIN Ok.
me: a001 SELECT INBOX
sv: a001 (bla lba bla)
sv: ...
sv: a001 OK [READ-WRITE] Ok.
me: a001 SEARCH HEADER Message-Id
[EMAIL PROTECTED]
sv: * SEARCH 1
sv: a001 OK SEARCH done.
As we can see server has found the message (msgno=1)
2. I use PHP script to do exactly the same:
?php
$imap=imap_open({localhost:143}INBOX, username, password, 0); // this
works beacause other imap_ things works (not included)
$a=imap_search($imap, 'HEADER Message-Id
[EMAIL PROTECTED]', SE_UID);
(...)
?
It does not find the message, however:
$a=imap_search($imap, 'TEXT
[EMAIL PROTECTED]', SE_UID);
Finds one.
The other search key that did not worked properly from PHP, (but in telnet
session worked) is UID
--
Edit bug report at: http://bugs.php.net/?id=14268edit=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] BC problem
A small example which shows that BC seems to be broken for a
certain (but not uncommon) case:
cat include_me.php
?
if (!defined('I_AM_INCLUDED')) {
define('I_AM_INCLUDED', 1);
} else {
echo returningbr\n;
return;
}
function cant_be_redefined() {
}
?
cat include_it.php
?
echo 1br\n;
include 'include_me.php';
echo 2br\n;
include 'include_me.php';
echo 3br\n;
?
Now run include_it.php (it doesn't matter if its CGI or
module):
On PHP 4.0.4pl1 up to 4.0.6 this gives:
1br
2br
returningbr
3br
But now I get:
1br
2br
br /
Fatal error - Cannot redeclare cant_be_redefined()
(previously declared in include_me.php:9)
[I shortened the error message to be more readable]
If this is 'now the way it is' this should be mentioned
somewhere very clearly I think. Doesn't seem to be fixable in
some way? Couldn't find a reference to it e.g. in the NEWS
file.
I know that there should be used include_once() but
I'm talking about existing code writing that way which
definitely won't work without modifications.
- Markus
ps: thanks to Jan for verifying this!
--
Please always Cc to me when replying to me on the lists.
--
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 #14269: doesn't compile, reporting: mod_mm.c:35: #error mm is not thread-safe
From: [EMAIL PROTECTED]
Operating system: SuSE linux 7.2 kernel 2.4.4
PHP version: 4.0CVS-2001-11-28
PHP Bug Type: Compile Failure
Bug description: doesn't compile, reporting: mod_mm.c:35: #error mm is not thread-safe
downloaded latest cvs, using apache2, latest cvs, (that one compiled
without any problems). configure is no problem, but doing make fails:
gcc -I. -I/src_dl/php4/ext/session -I/src_dl/php4/main -I/src_dl/php4
-I/usr/local/httpd2/include -I/src_dl/php4/Zend
-I/usr/include/freetype2/freetype/include/freetype2/freetype
-I/usr/include/imap -I/src_dl/php4/ext/mysql/libmysql
-I/src_dl/php4/ext/xml/expat -D_REENTRANT -I/src_dl/php4/TSRM -DTHREAD=1 -g
-O2 -pthread -Wall -DZTS -c mod_mm.c -fPIC -DPIC -o mod_mm.lo
mod_mm.c:35: #error mm is not thread-safe
make[3]: *** [mod_mm.lo] Error 1
make[3]: Leaving directory `/src_dl/php4/ext/session'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/src_dl/php4/ext/session'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/src_dl/php4/ext'
make: *** [all-recursive] Error 1
my configure line:
./configure --prefix=/usr --bindir=/usr/bin --libdir=/usr/lib
--with-config-file-path=/etc --with-exec-dir=%{libdir}/php/bin --with-mysql
--with-gd=/usr/lib --with-tiff-dir=/usr --with-jpeg-dir=/usr/lib
--with-png-dir=/usr/lib --with-imap --with-zlib --with-bz2 --with-xml
--with-ttf --with-t1lib-dir=/usr/share/t1lib --with-ftp --with-ndbm
--with-gdbm --with-mm --with-gd=yes --with-qtdom=/usr/lib/qt-2.2.1/
--enable-versioning --enable-yp --enable-bcmath --enable-trans-sid
--enable-inline-optimization --enable-track-vars --enable-magic-quotes
--enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm
--enable-shmop --enable-calendar --enable-exif --enable-ftp
--enable-memory-limit --enable-wddx --enable-filepro --enable-dbase
--enable-ctype --enable-debug --enable-force-cgi-redirect
--enable-discard-path --enable-sigchild --enable-gd-imgstrttf
--with-apxs2=/usr/local/httpd2/bin/apxs
--with-freetype-dir=/usr/include/freetype2/freetype --with-imap-ssl
i can't figure out what the problem is :(
--
Edit bug report at: http://bugs.php.net/?id=14269edit=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 #14269 Updated: doesn't compile, reporting: mod_mm.c:35: #error mm is not thread-safe
ID: 14269
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Operating System: SuSE linux 7.2 kernel 2.4.4
PHP Version: 4.0CVS-2001-11-28
New Comment:
well, actually, the problem is quite easy: it won't compile
i can't figure out why the problem occurs and how to fix it ;)
Previous Comments:
[2001-11-28 12:05:53] [EMAIL PROTECTED]
downloaded latest cvs, using apache2, latest cvs, (that one compiled without any
problems). configure is no problem, but doing make fails:
gcc -I. -I/src_dl/php4/ext/session -I/src_dl/php4/main -I/src_dl/php4
-I/usr/local/httpd2/include -I/src_dl/php4/Zend
-I/usr/include/freetype2/freetype/include/freetype2/freetype -I/usr/include/imap
-I/src_dl/php4/ext/mysql/libmysql -I/src_dl/php4/ext/xml/expat -D_REENTRANT
-I/src_dl/php4/TSRM -DTHREAD=1 -g -O2 -pthread -Wall -DZTS -c mod_mm.c -fPIC -DPIC -o
mod_mm.lo
mod_mm.c:35: #error mm is not thread-safe
make[3]: *** [mod_mm.lo] Error 1
make[3]: Leaving directory `/src_dl/php4/ext/session'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/src_dl/php4/ext/session'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/src_dl/php4/ext'
make: *** [all-recursive] Error 1
my configure line:
./configure --prefix=/usr --bindir=/usr/bin --libdir=/usr/lib
--with-config-file-path=/etc --with-exec-dir=%{libdir}/php/bin --with-mysql
--with-gd=/usr/lib --with-tiff-dir=/usr --with-jpeg-dir=/usr/lib
--with-png-dir=/usr/lib --with-imap --with-zlib --with-bz2 --with-xml --with-ttf
--with-t1lib-dir=/usr/share/t1lib --with-ftp --with-ndbm --with-gdbm --with-mm
--with-gd=yes --with-qtdom=/usr/lib/qt-2.2.1/ --enable-versioning --enable-yp
--enable-bcmath --enable-trans-sid --enable-inline-optimization --enable-track-vars
--enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem
--enable-sysvshm --enable-shmop --enable-calendar --enable-exif --enable-ftp
--enable-memory-limit --enable-wddx --enable-filepro --enable-dbase --enable-ctype
--enable-debug --enable-force-cgi-redirect --enable-discard-path --enable-sigchild
--enable-gd-imgstrttf --with-apxs2=/usr/local/httpd2/bin/apxs
--with-freetype-dir=/usr/include/freetype2/freetype --with-imap-ssl
i can't figure out what the problem is :(
Edit this bug report at http://bugs.php.net/?id=14269edit=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 #14270: Cannot Successfully map soname
From: [EMAIL PROTECTED] Operating system: SGI IRIX 6.3 PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: Cannot Successfully map soname When I run the command 'apachectl start' after compile and install php, apache tells me: Cannot load /usr/local/apache/libexec/libphp4.so into server: 4116:/usr/local/apache/bin/httpd: rld: Fatal Error: Cannot Successfully map soname '/usr/local/apache/libexec/libphp4.so' under any of the filenames /usr/local/apache/libexec/libphp4.so The apache version is 1.3.20 and its configuration is ./configure --enable-module=so --enable-module=most --enable-shared=max --with-layout=Apache --enable-module=ssl The php configuration is ./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs -- Edit bug report at: http://bugs.php.net/?id=14270edit=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 #14269 Updated: doesn't compile, reporting: mod_mm.c:35: #error mm is not thread-safe
ID: 14269
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Old Bug Type: Compile Failure
Bug Type: Feature/Change Request
Operating System: SuSE linux 7.2 kernel 2.4.4
PHP Version: 4.0CVS-2001-11-28
New Comment:
Not a bug, the MM module can't be used in a threading webserver, including Apache 2.
I'm closing this.
Derick
Previous Comments:
[2001-11-28 12:07:47] [EMAIL PROTECTED]
well, actually, the problem is quite easy: it won't compile
i can't figure out why the problem occurs and how to fix it ;)
[2001-11-28 12:05:53] [EMAIL PROTECTED]
downloaded latest cvs, using apache2, latest cvs, (that one compiled without any
problems). configure is no problem, but doing make fails:
gcc -I. -I/src_dl/php4/ext/session -I/src_dl/php4/main -I/src_dl/php4
-I/usr/local/httpd2/include -I/src_dl/php4/Zend
-I/usr/include/freetype2/freetype/include/freetype2/freetype -I/usr/include/imap
-I/src_dl/php4/ext/mysql/libmysql -I/src_dl/php4/ext/xml/expat -D_REENTRANT
-I/src_dl/php4/TSRM -DTHREAD=1 -g -O2 -pthread -Wall -DZTS -c mod_mm.c -fPIC -DPIC -o
mod_mm.lo
mod_mm.c:35: #error mm is not thread-safe
make[3]: *** [mod_mm.lo] Error 1
make[3]: Leaving directory `/src_dl/php4/ext/session'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/src_dl/php4/ext/session'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/src_dl/php4/ext'
make: *** [all-recursive] Error 1
my configure line:
./configure --prefix=/usr --bindir=/usr/bin --libdir=/usr/lib
--with-config-file-path=/etc --with-exec-dir=%{libdir}/php/bin --with-mysql
--with-gd=/usr/lib --with-tiff-dir=/usr --with-jpeg-dir=/usr/lib
--with-png-dir=/usr/lib --with-imap --with-zlib --with-bz2 --with-xml --with-ttf
--with-t1lib-dir=/usr/share/t1lib --with-ftp --with-ndbm --with-gdbm --with-mm
--with-gd=yes --with-qtdom=/usr/lib/qt-2.2.1/ --enable-versioning --enable-yp
--enable-bcmath --enable-trans-sid --enable-inline-optimization --enable-track-vars
--enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem
--enable-sysvshm --enable-shmop --enable-calendar --enable-exif --enable-ftp
--enable-memory-limit --enable-wddx --enable-filepro --enable-dbase --enable-ctype
--enable-debug --enable-force-cgi-redirect --enable-discard-path --enable-sigchild
--enable-gd-imgstrttf --with-apxs2=/usr/local/httpd2/bin/apxs
--with-freetype-dir=/usr/include/freetype2/freetype --with-imap-ssl
i can't figure out what the problem is :(
Edit this bug report at http://bugs.php.net/?id=14269edit=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]
[no subject]
Title: °Ù´óǧÀïÂí ÏàÖªÔÚ°Ù´ó ;;; ;;; ;;; ;;; ;;; ;;; ;;; ;;; ;;;
[PHP-DEV] Bug #14269 Updated: doesn't compile, reporting: mod_mm.c:35: #error mm is not thread-safe
ID: 14269
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Feature/Change Request
Operating System: SuSE linux 7.2 kernel 2.4.4
PHP Version: 4.0CVS-2001-11-28
New Comment:
Sorry, didn't realise that.
Thanx anyway.
Previous Comments:
[2001-11-28 12:47:10] [EMAIL PROTECTED]
Not a bug, the MM module can't be used in a threading webserver, including Apache 2.
I'm closing this.
Derick
[2001-11-28 12:07:47] [EMAIL PROTECTED]
well, actually, the problem is quite easy: it won't compile
i can't figure out why the problem occurs and how to fix it ;)
[2001-11-28 12:05:53] [EMAIL PROTECTED]
downloaded latest cvs, using apache2, latest cvs, (that one compiled without any
problems). configure is no problem, but doing make fails:
gcc -I. -I/src_dl/php4/ext/session -I/src_dl/php4/main -I/src_dl/php4
-I/usr/local/httpd2/include -I/src_dl/php4/Zend
-I/usr/include/freetype2/freetype/include/freetype2/freetype -I/usr/include/imap
-I/src_dl/php4/ext/mysql/libmysql -I/src_dl/php4/ext/xml/expat -D_REENTRANT
-I/src_dl/php4/TSRM -DTHREAD=1 -g -O2 -pthread -Wall -DZTS -c mod_mm.c -fPIC -DPIC -o
mod_mm.lo
mod_mm.c:35: #error mm is not thread-safe
make[3]: *** [mod_mm.lo] Error 1
make[3]: Leaving directory `/src_dl/php4/ext/session'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/src_dl/php4/ext/session'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/src_dl/php4/ext'
make: *** [all-recursive] Error 1
my configure line:
./configure --prefix=/usr --bindir=/usr/bin --libdir=/usr/lib
--with-config-file-path=/etc --with-exec-dir=%{libdir}/php/bin --with-mysql
--with-gd=/usr/lib --with-tiff-dir=/usr --with-jpeg-dir=/usr/lib
--with-png-dir=/usr/lib --with-imap --with-zlib --with-bz2 --with-xml --with-ttf
--with-t1lib-dir=/usr/share/t1lib --with-ftp --with-ndbm --with-gdbm --with-mm
--with-gd=yes --with-qtdom=/usr/lib/qt-2.2.1/ --enable-versioning --enable-yp
--enable-bcmath --enable-trans-sid --enable-inline-optimization --enable-track-vars
--enable-magic-quotes --enable-safe-mode --enable-sockets --enable-sysvsem
--enable-sysvshm --enable-shmop --enable-calendar --enable-exif --enable-ftp
--enable-memory-limit --enable-wddx --enable-filepro --enable-dbase --enable-ctype
--enable-debug --enable-force-cgi-redirect --enable-discard-path --enable-sigchild
--enable-gd-imgstrttf --with-apxs2=/usr/local/httpd2/bin/apxs
--with-freetype-dir=/usr/include/freetype2/freetype --with-imap-ssl
i can't figure out what the problem is :(
Edit this bug report at http://bugs.php.net/?id=14269edit=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 #14245 Updated: make install fails on apxs
ID: 14245 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Operating System: AIX 4.3.3 PHP Version: 4.1.0 New Comment: I've found a workaround for this problem. If I manually copy .libs/libphp4.so.0 to libs/libphp4.so, it seems to continue okay: # make install ... cp: libs/libphp4.so: A file or directory in the path name does not exist. apxs:Break: Command failed with rc=65536 make: 1254-004 The error code from the last command is 1. ... Stop. # cp .libs/libphp4.so.0 libs/libphp4.so # make install ... Target install-p is up to date. Target install is up to date. Making install in . /local/www/bin/apxs -i -a -n php4 libs/libphp4.so cp libs/libphp4.so /local/www/libexec/libphp4.so chmod 755 /local/www/libexec/libphp4.so [activating module `php4' in /local/www/conf/httpd.conf] installing shared modules into /local/www/php/lib/php/20010901 Target install-p is up to date. ... Target install is up to date. # /local/www/bin/apachectl start Target install is up to date. Is there some way make install can do that copying step automatically? Previous Comments: [2001-11-27 01:12:43] [EMAIL PROTECTED] Make install fails on apxs -i i -a -n php4 libs/libphp4.so cp libs/libphp4.so /local/www/libexec/libphp4.so. The libs directory contains libphp4.a and libphp4.la, but not libphp4.so. Compiler: IBM Visual Age C $ export CC=cc_r $ export CFLAGS=-g -ma $ ./configure --prefix=/local/www/php \ --with-apxs=/local/www/bin/apxs \ --without-mysql $ make Making all in Zend ... Target all is up to date. # /local/www/bin/apachectl stop # /usr/sbin/slibclean # make install Making install in Zend ... Target install-p is up to date. Target install is up to date. Making install in . /local/www/bin/apxs -i -a -n php4 libs/libphp4.so cp libs/libphp4.so /local/www/libexec/libphp4.so cp: libs/libphp4.so: A file or directory in the path name does not exist. apxs:Break: Command failed with rc=65536 make: 1254-004 The error code from the last command is 1. Stop. make: 1254-004 The error code from the last command is 1. Stop. # ls -l libs total 16008 -rw--- 1 root system 4094311 Nov 26 23:53 libphp4.a -rw--- 1 root system 749 Nov 26 23:53 libphp4.la Edit this bug report at http://bugs.php.net/?id=14245edit=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 #14271: Failure to compile using GD 2.0.1 because of conflicting types for gdIOCtx
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.1.0 PHP Bug Type: Compile Failure Bug description: Failure to compile using GD 2.0.1 because of conflicting types for gdIOCtx When compiling w/ GD 2.0.1, I found a warning and a fatal error: In file included from gd.c:36: php_gd.h:69: warning: static declaration for `gdImageColorResolve' follows non-static gd.c:92: conflicting types for `gdIOCtx' /asd/metallo1/server/libs/gd2/include/gd_io.h:19: previous declaration of `gdIOCtx' make[3]: *** [gd.lo] Error 1 make[3]: Leaving directory `/asd/metallo1/sources/src_compile/php-4.1.0/ext/gd' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/asd/metallo1/sources/src_compile/php-4.1.0/ext/gd' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/asd/metallo1/sources/src_compile/php-4.1.0/ext' make: *** [all-recursive] Error 1 Using gcc 3.0.2, gd 2.0.1, and the following configuration line: ./configure --prefix=/export/dredox1/devel_server/php \ --with-config-file-path=/export/dredox1/devel_server/php \ --enable-track-vars --enable-magic-quotes \ --enable-inline-optimization --enable-xml --enable-wddx \ --enable-ftp --enable-calendar --enable-bcmath --enable-trans-id\ --with-zlib \ --with-gd=/asd/metallo1/server/libs/gd2 \ --enable-gd-native-ttf \ --with-xmlrpc \ --with-mysql=/export/dredox1/devel_server/mysql \ --with-apxs=/export/dredox1/devel_server/apache/bin/apxs A quick and dirty kludge is to comment out line 92 in ext/gd/gd.c, which might break something else. Had not tested the compiled libphp4.so thoroughly. -- Edit bug report at: http://bugs.php.net/?id=14271edit=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 #14261 Updated: fsockopen w/ udp responds incorrectly
ID: 14261
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Sockets related
Operating System: RedHat 7.1
Old PHP Version: 4.0.6
PHP Version: 4.0.6, 4.1.0RC3
New Comment:
#!/usr/local/bin/php -q
?
$ipaddress = udp://192.168.0.1;
$port = 7;
$test = fsockopen($ipaddress,$port,$errno,$errstr);
if (!$test) {
echo DOWN\n;
} else {
echo UP\n;
}
?
Responds UP when it should timeout and respond DOWN.
-
Tried 4.1.0 RC3 on several x86 machines, same problem.
Previous Comments:
[2001-11-28 01:27:02] [EMAIL PROTECTED]
There were some fixes related to this. Could you possibly try the latest 4.1.0 RC from
www.php.net/~zeev/php-4.1.0RC3.tar.gz ?
If it's fixed there, you can use the soon-to-be-released 4.1.0 version.
Derick
[2001-11-27 22:28:31] [EMAIL PROTECTED]
#!/usr/local/bin/php -q
?
$ipaddress = udp://192.168.0.1;
$port = 7;
$test = fsockopen($ipaddress,$port,$errno,$errstr);
if (!$test) {
echo DOWN\n;
} else {
echo UP\n;
}
?
Responds UP when it should timeout and respond DOWN.
Edit this bug report at http://bugs.php.net/?id=14261edit=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] Patch: Nested comments
Hartmut Holzgraefe wrote: Markus Fischer wrote: Although my vote doesn't count much here :-) I'm for it... ... but it would be a problem for 4.x I guess because this horribly breaks BC when/if there's a new 4.x release and people start using it. should be no problem to introduce it with 4.2 as we are breaking BC in lots of places anyway ... I do not have much against this particular proposal, but I have observed the tendency here (on this mailing list) to be something like that: Since we are breaking one thing, we might just as well let the hell break loose and break everything else, be it necessary or not. Often times the break early, break hard principle will not work all that well just because we are not breaking early anymore, and breaking things just to make a cute feature or two work might not be such a good idea. This is just an observation, don't flame me, but this attitude is starting to worry me a bit. I can see 4.2 being so different from 4.0.6 that we might not be able to call it 'php' anymore. Just something to watch out for, so we don't go overboard... Now, have a good day, everyone Vlad -- 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] IMPORTANT FOR YOU
Under Bill 1618 TITLE III passed by the 105th U.S. Congress, This letter cannot be considered Spam as long as we include: Contact information a Remove Link. If not interested in the services offered, To be removed from future mailings just reply with 'REMOVE' in the subject line. Your request to be removed will be processed within 24 hours. * *** Zeynab Marketing Division [EMAIL PROTECTED] Position: E-Mail Processor WE are currently looking for SERIOUS HOMEWORKERS. We have immediate vacancies for E-Mail Processors. Experience is NOT necessary. Part time/full time. Anywhere in the world! I do require that you have a computer and are familiar with internet/email functions. Training and other necessary Softwares are provided. About Us: We are an offshore company based on Sri Lanka since 1996, specializing in trade and support services for the international trading community. Our main business activities are International trading of high profitable goods, Import Export Agent, Commission agent, Internet marketing, Market research through Internet etc. You will be paid working for us as follows: 1. Refer others and get paid $1.00 2.Your associate commission is 5% for all direct sales and 1% on sales made by your Affiliates for one level. For example: If you refer 70 affiliate under you, get paid =$70.00 If you se11 3 product ($275 x 3), get paid =$41.25 If your afiliate sell 2 products ($200x2),get paid =$ 4.00 Your Salary = $115.25 If you are looking for a get-rich-quick scheme, please do not reply us. This is a limited time offer. Registation free: We only want SERIOUS homeworkers to work for us. For that reason we must ask for a one-time PAYMENT of US$20. This is necessary to protect both: you and us from unreliable job seekers. How to Apply: Contact us to [EMAIL PROTECTED] Applicationat the subject line. Thank you for your time. * *** -- 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] DOM XML Bugs
Hi, Could someone tell me WHEN DOM XML will be cleared out of those annoying memory leak bugs that make this great tool generally unsuable on any production server? PHP Developers - it's really important!!! -- LK. -- 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] DOM XML Bugs
Hello, On Wed, 28 Nov 2001, £ukasz Kalita wrote: Could someone tell me WHEN DOM XML will be cleared out of those annoying memory leak bugs that make this great tool generally unsuable on any production server? When sombody has enough free time to do that, or when somebody else pays a developer to do it. PHP Developers - it's really important!!! I know, but it's all on a voluntary bases. Derick -- 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] BC problem
This has already been discussed at great length in another thread. I
believe it was decided to put it all back like it was for now and decide on
a better solution later.
Brian.
- Original Message -
From: Markus Fischer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 28, 2001 11:05 AM
Subject: [PHP-DEV] BC problem
A small example which shows that BC seems to be broken for a
certain (but not uncommon) case:
cat include_me.php
?
if (!defined('I_AM_INCLUDED')) {
define('I_AM_INCLUDED', 1);
} else {
echo returningbr\n;
return;
}
function cant_be_redefined() {
}
?
cat include_it.php
?
echo 1br\n;
include 'include_me.php';
echo 2br\n;
include 'include_me.php';
echo 3br\n;
?
Now run include_it.php (it doesn't matter if its CGI or
module):
On PHP 4.0.4pl1 up to 4.0.6 this gives:
1br
2br
returningbr
3br
But now I get:
1br
2br
br /
Fatal error - Cannot redeclare cant_be_redefined()
(previously declared in include_me.php:9)
[I shortened the error message to be more readable]
If this is 'now the way it is' this should be mentioned
somewhere very clearly I think. Doesn't seem to be fixable in
some way? Couldn't find a reference to it e.g. in the NEWS
file.
I know that there should be used include_once() but
I'm talking about existing code writing that way which
definitely won't work without modifications.
- Markus
ps: thanks to Jan for verifying this!
--
Please always Cc to me when replying to me on the lists.
--
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]
Re: [PHP-DEV] Patch: Nested comments
At 11:31 AM 11/28/2001 -0800, Vlad Krupin wrote: Hartmut Holzgraefe wrote: Markus Fischer wrote: Although my vote doesn't count much here :-) I'm for it... ... but it would be a problem for 4.x I guess because this horribly breaks BC when/if there's a new 4.x release and people start using it. should be no problem to introduce it with 4.2 as we are breaking BC in lots of places anyway ... I do not have much against this particular proposal, but I have observed the tendency here (on this mailing list) to be something like that: Since we are breaking one thing, we might just as well let the hell break loose and break everything else, be it necessary or not. Often times the break early, break hard principle will not work all that well just because we are not breaking early anymore, and breaking things just to make a cute feature or two work might not be such a good idea. This is just an observation, don't flame me, but this attitude is starting to worry me a bit. I can see 4.2 being so different from 4.0.6 that we might not be able to call it 'php' anymore. Just something to watch out for, so we don't go overboard... Now, have a good day, everyone I agree. We should fix problems but people have to remember that no matter what there are lots and lots of users out there and the less we break things, even between major versions, the easier possible the transition will be for the users. Most PHP users out there aren't php-dev techies who like fixing their old code to work with new versions :) They prefer their old stuff to work. So sometimes we need to break stuff but it should always be done only if it really makes good sense and gives enough benefit. Andi -- 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] BC problem
Yep. As far as I remember it was reverted in 4.1.0
Andi
At 01:54 PM 11/28/2001 -0600, Brian Moon wrote:
This has already been discussed at great length in another thread. I
believe it was decided to put it all back like it was for now and decide on
a better solution later.
Brian.
- Original Message -
From: Markus Fischer [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, November 28, 2001 11:05 AM
Subject: [PHP-DEV] BC problem
A small example which shows that BC seems to be broken for a
certain (but not uncommon) case:
cat include_me.php
?
if (!defined('I_AM_INCLUDED')) {
define('I_AM_INCLUDED', 1);
} else {
echo returningbr\n;
return;
}
function cant_be_redefined() {
}
?
cat include_it.php
?
echo 1br\n;
include 'include_me.php';
echo 2br\n;
include 'include_me.php';
echo 3br\n;
?
Now run include_it.php (it doesn't matter if its CGI or
module):
On PHP 4.0.4pl1 up to 4.0.6 this gives:
1br
2br
returningbr
3br
But now I get:
1br
2br
br /
Fatal error - Cannot redeclare cant_be_redefined()
(previously declared in include_me.php:9)
[I shortened the error message to be more readable]
If this is 'now the way it is' this should be mentioned
somewhere very clearly I think. Doesn't seem to be fixable in
some way? Couldn't find a reference to it e.g. in the NEWS
file.
I know that there should be used include_once() but
I'm talking about existing code writing that way which
definitely won't work without modifications.
- Markus
ps: thanks to Jan for verifying this!
--
Please always Cc to me when replying to me on the lists.
--
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] [PATCH] update against Apache 2
I normally don't follow this list, so forgive me if this has already been
discussed, but here's a patch to update sapi_apache2.c against the latest
changes to the Apache 2 API. The constness change for apr_array_header_t
should be safe with prior versions of Apache 2.0 as well; the prototype
change for the post_config hook, however, didn't go in until after
2.0.28-beta, so if you're interested in having it compile cleanly with
both old and new versions, you probably need an module magic number check
around the prototype for php_apache_server_startup().
--Cliff
Index: sapi_apache2.c
===
RCS file: /repository/php4/sapi/apache2filter/sapi_apache2.c,v
retrieving revision 1.57
diff -u -d -r1.57 sapi_apache2.c
--- sapi_apache2.c 13 Nov 2001 21:40:01 - 1.57
+++ sapi_apache2.c 28 Nov 2001 20:26:40 -
@@ -145,7 +145,7 @@
php_apache_sapi_register_variables(zval *track_vars_array TSRMLS_DC)
{
php_struct *ctx = SG(server_context);
- apr_array_header_t *arr = apr_table_elts(ctx-f-r-subprocess_env);
+ const apr_array_header_t *arr = apr_table_elts(ctx-f-r-subprocess_env);
char *key, *val;
APR_ARRAY_FOREACH_OPEN(arr, key, val)
@@ -419,7 +419,7 @@
}
}
-static void
+static int
php_apache_server_startup(apr_pool_t *pconf, apr_pool_t *plog,
apr_pool_t *ptemp, server_rec *s)
{
@@ -429,6 +429,7 @@
apr_pool_cleanup_register(pconf, NULL, php_apache_server_shutdown,
apr_pool_cleanup_null);
php_apache_register_module();
php_apache_add_version(pconf);
+ return OK;
}
static void php_add_filter(request_rec *r, ap_filter_t *f)
--
Cliff Woolley
[EMAIL PROTECTED]
Charlottesville, VA
--
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 #14272: com_load doesn't work
From: [EMAIL PROTECTED] Operating system: win98 PHP version: 4.1.0 PHP Bug Type: COM related Bug description: com_load doesn't work #$objSession = com_load(MAPI.Session); #Doesn't work $objSession =new COM(MAPI.Session); #works -- Edit bug report at: http://bugs.php.net/?id=14272edit=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] BC problem
On Wed, Nov 28, 2001 at 10:23:55PM +0200, Andi Gutmans wrote : Yep. As far as I remember it was reverted in 4.1.0 No, it doesn't seem to be reverted: $ ~/php410/bin/php -v 4.1.0 $ ~/php410/bin/php -f include_it.php 1br 2br br include_me.php(10) : Fatal error - Cannot redeclare cant_be_redefined() - Markus -- 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] Patch: Nested comments
On Wed, 28 Nov 2001, Andi Gutmans wrote: I agree. We should fix problems but people have to remember that no matter what there are lots and lots of users out there and the less we break things, even between major versions, the easier possible the transition will be for the users. Sometimes you need a revolution before you can have evolution. PHP is a good language for a lot of applications, but I'm not sure I would pick it for my next big project anymore. This isn't intended as a slight, just some feedback; but the language doesn't appear to be evolving to encourage quality development the way that Python has. Following this list for a long time leads me to believe that the ideal of maintaining backwards compatibility is one of the big reasons why (concern about execution speed being the other big reason, something I've always been impressed with with the PHP developers). John -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- 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 #14273: When I use 'urlencode' in a for loop the mod_php core dumps'
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.0.6
PHP Bug Type: URL related
Bug description: When I use 'urlencode' in a for loop the mod_php core dumps'
This works!!!
$cnt = count($arrayA);
for ( $ix=0 ; $ix $cnt; $ix++ )
{
$aurl = mysql_query(select name, url from sites where
code='.$arrayA[$ix][1].');
list($name$url) = mysql_fetch_row($aurl);
mysql_free_result($aurl);
echo $url $name;
}
This Fails!!
$cnt = count($arrayA);
for ( $ix=0 ; $ix $cnt; $ix++ )
{
$aurl = mysql_query(select name, url from sites where
code='.$arrayA[$ix][1].');
list($name$url) = mysql_fetch_row($aurl);
mysql_free_result($aurl);
echo urlencode($url), $name;
}
Only change is addition of urlencode, What gives?
--
Edit bug report at: http://bugs.php.net/?id=14273edit=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] crash+backtrace... is it a known issue?
I finally got around to fixing the dbase bug I have assigned, and... when I tried to compile today's snapshot with a very simple confug line: ./configure --with-apxs=/usr/local/apache/bin/apxs --enable-dbase --enable-debug it compiled just fine, but when I tried to run apache with it, it bombed. I do not believe dbase is to blame. Apache just simply does not start. I use Linux, kernel 2.4.0-test9, glibc-2.1.3-15, compiled with egcs-2.91.66. Backtrace is below. Is this a known problem, or am I missing something obvious? Or should I file a full-blown bug report? Vlad #0 0x4012e0d6 in chunk_free (ar_ptr=0x401c2d60, p=0x8184d38) at malloc.c:3097 #1 0x4012de46 in chunk_alloc (ar_ptr=0x401c2d60, nb=24) at malloc.c:2594 #2 0x4012ee34 in __libc_calloc (n=5, elem_size=4) at malloc.c:3699 #3 0x808d2a0 in zend_hash_init (ht=0x8184d10, nSize=5, pHashFunction=0, pDestructor=0x40229b58 destroy_per_dir_entry, persistent=1) at zend_hash.c:185 #4 0x40229cc2 in php_create_dir (p=0x817c644, dummy=0x0) at mod_php4.c:669 #5 0x80e47f3 in ap_single_module_configure () #6 0x8077730 in load_module () #7 0x80e30ce in invoke_cmd () #8 0x80e39b3 in ap_handle_command () #9 0x80e3a47 in ap_srm_command_loop () #10 0x80e3e50 in ap_process_resource_config () #11 0x80e4712 in ap_read_config () #12 0x80ee729 in main () #13 0x400ec9cb in __libc_start_main (main=0x80ee49c main, argc=2, argv=0xbad4, init=0x805f3b8 _init, fini=0x812294c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xbacc) at ../sysdeps/generic/libc-start.c:92 -- Vlad Krupin Software Engineer echospace.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] Patch: Nested comments
Just for the record: I was talking about ZE2 and, er .. correct me if I'm wrong, ZE2 definitely won't be in 4.2.x? - Markus On Wed, Nov 28, 2001 at 11:31:42AM -0800, Vlad Krupin wrote : Hartmut Holzgraefe wrote: Markus Fischer wrote: Although my vote doesn't count much here :-) I'm for it... ... but it would be a problem for 4.x I guess because this horribly breaks BC when/if there's a new 4.x release and people start using it. should be no problem to introduce it with 4.2 as we are breaking BC in lots of places anyway ... I do not have much against this particular proposal, but I have observed the tendency here (on this mailing list) to be something like that: Since we are breaking one thing, we might just as well let the hell break loose and break everything else, be it necessary or not. Often times the break early, break hard principle will not work all that well just because we are not breaking early anymore, and breaking things just to make a cute feature or two work might not be such a good idea. This is just an observation, don't flame me, but this attitude is starting to worry me a bit. I can see 4.2 being so different from 4.0.6 that we might not be able to call it 'php' anymore. Just something to watch out for, so we don't go overboard... Now, have a good day, everyone Vlad -- 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] -- Please always Cc to me when replying to me on the lists. -- 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] DOM XML Bugs
On Wed, Nov 28, 2001 at 08:36:54PM +0100, Derick Rethans wrote : Hello, On Wed, 28 Nov 2001, £ukasz Kalita wrote: Could someone tell me WHEN DOM XML will be cleared out of those annoying memory leak bugs that make this great tool generally unsuable on any production server? When sombody has enough free time to do that, or when somebody else pays a developer to do it. May I jump in? :) Not that I've enough time but my current freetime is to get domxml as stable and mem-leak free as I can. A few things have to be done first (kind of infrastructure I call it). For myself, I won't give a timeframe, but don't expect it to be soon unless I get fulltime paid for it. Something which would help a *lot* would be as much testings as we can get for it. There are already a few bug reports showing reproduceable errors which can be tracked down. But any testing, and of course, volunteering, is welcome. - Markus -- 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 #14273 Updated: When I use 'urlencode' in a for loop the mod_php core dumps'
ID: 14273
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: URL related
Operating System: Linux
PHP Version: 4.0.6
New Comment:
Um ... list($name$url) looks really weird to me. You should write list($name, $url)
instead.
Can you reproduce this with latest (not official) release?
http://www.php.net/~zeev/php-4.1.0.tar.gz
Also, the actual content of '$url' would be interesting anyway (since coredump is
never ok), something like 'var_dump($url);' before passing it to urlencode().
Feedback.
Previous Comments:
[2001-11-28 17:23:08] [EMAIL PROTECTED]
This works!!!
$cnt = count($arrayA);
for ( $ix=0 ; $ix $cnt; $ix++ )
{
$aurl = mysql_query(select name, url from sites where
code='.$arrayA[$ix][1].');
list($name$url) = mysql_fetch_row($aurl);
mysql_free_result($aurl);
echo $url $name;
}
This Fails!!
$cnt = count($arrayA);
for ( $ix=0 ; $ix $cnt; $ix++ )
{
$aurl = mysql_query(select name, url from sites where
code='.$arrayA[$ix][1].');
list($name$url) = mysql_fetch_row($aurl);
mysql_free_result($aurl);
echo urlencode($url), $name;
}
Only change is addition of urlencode, What gives?
Edit this bug report at http://bugs.php.net/?id=14273edit=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] if (empty(trim('x'))) == parse error?
Andrey Hristov wrote: From the docs for empty(): Note that this is meaningless when used on anything which isn't a variable; i.e. empty (addslashes ($name)) has no meaning since it would be checking whether something which isn't a variable is a variable with a FALSE value. Maybe I am not so clever, but the document writer tried to explain that empty()'s flaw is a feature. The correct doc should contain lvalue instead of variable. -- jul -- 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] crash+backtrace... is it a known issue?
On Wed, Nov 28, 2001 at 02:40:55PM -0800, Vlad Krupin wrote : I finally got around to fixing the dbase bug I have assigned, and... when I tried to compile today's snapshot with a very simple confug line: ./configure --with-apxs=/usr/local/apache/bin/apxs --enable-dbase --enable-debug Did you test it without '--enable-dbase' ? Same problem? - Markus -- 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] references-weirdness???
why do the following two examples result in different things, even
though i would expect the same behaviour?
in words: i pass a reference of a class-property to a variable $walk,
if i overwrite $walk, the class-property has a new value too (seems
logical, since we are working with references not pointers)
BUT
if i use a class-method which returns a reference to this
class-property, to set $walk ... and then i overwrite $walk the
class-property didnt change
code-example
?php
class test
{
var $data;
function test()
{
$this-data[0] = 'level zero';
$this-data[1] = 'level one';
}
function getData( $id )
{
return $this-data[$id];
}
}
$test = new test;
print('br');
print_r($test);
// the following block overwrites $test-data[0] with $test-data[1]
$walk = $test-data[0];
$walk = $test-data[1];
print('br');
print_r($test);
$test = new test;
// but this one does NOT !!!
$walk = $test-getData(0);
$walk = $test-data[1];
print('br');
print_r($test);
?
--
Wolfram
--
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] references-weirdness???
Wolfram Kriesing writes:
why do the following two examples result in different things, even
though i would expect the same behaviour?
From the manual:
http://www.php.net/manual/en/language.references.return.php
function find_var ($param)
{
...code...
return $found_var;
}
$foo = find_var ($bar);
$foo-x = 2;
In this example, the property of the object returned by the find_var
function would be set, not the copy, as it would be without using
reference syntax.
Note: Unlike parameter passing, here you have to use in both
places - to indicate that you return by-reference, not a copy as
usual, and to indicate that reference binding, rather than usual
assignment, should be done for $foo.
...in other words, your problem is here:
$test = new test;
// but this one does NOT !!!
$walk = $test-getData(0);
^^^
...it should be:
$walk = $test-getData(0);
$walk = $test-data[1];
print('br');
print_r($test);
Cheers,
Torben
in words: i pass a reference of a class-property to a variable $walk,
if i overwrite $walk, the class-property has a new value too (seems
logical, since we are working with references not pointers)
BUT
if i use a class-method which returns a reference to this
class-property, to set $walk ... and then i overwrite $walk the
class-property didnt change
code-example
?php
class test
{
var $data;
function test()
{
$this-data[0] = 'level zero';
$this-data[1] = 'level one';
}
function getData( $id )
{
return $this-data[$id];
}
}
$test = new test;
print('br');
print_r($test);
// the following block overwrites $test-data[0] with $test-data[1]
$walk = $test-data[0];
$walk = $test-data[1];
print('br');
print_r($test);
$test = new test;
// but this one does NOT !!!
$walk = $test-getData(0);
$walk = $test-data[1];
print('br');
print_r($test);
?
--
Wolfram
--
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]
--
Torben Wilson [EMAIL PROTECTED]
http://www.thebuttlesschaps.com
http://www.hybrid17.com
http://www.inflatableeye.com
+1.604.709.0506
--
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] crash+backtrace... is it a known issue?
I am pretty sure dbase has nothing to do with it. No dbase code gets called before we crash. I do not think it would make a change. I can rebuild the while thing once again from a clean CVS checkout, and see, I guess, but I am quite sure the issue lies with something else. Vlad Markus Fischer wrote: On Wed, Nov 28, 2001 at 02:40:55PM -0800, Vlad Krupin wrote : I finally got around to fixing the dbase bug I have assigned, and... when I tried to compile today's snapshot with a very simple confug line: ./configure --with-apxs=/usr/local/apache/bin/apxs --enable-dbase --enable-debug Did you test it without '--enable-dbase' ? Same problem? - Markus -- 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] crash+backtrace... is it a known issue?
As expected, same crash, essentially the same backtrace. This time I also excluded MySQL from build. ./configure --with-apxs=/usr/local/apache/bin/apxs --without-mysql --enable-debug Fresh today's checkout, apache 1.2.12. So, is this a known issue? If no-one shouts anything legible, I'll just file a bug report and look at it sometime later. Vlad #0 0x4012e0d6 in chunk_free (ar_ptr=0x401c2d60, p=0x8184d38) at malloc.c:3097 #1 0x4012de46 in chunk_alloc (ar_ptr=0x401c2d60, nb=24) at malloc.c:2594 #2 0x4012ee34 in __libc_calloc (n=5, elem_size=4) at malloc.c:3699 #3 0x808d2a0 in zend_hash_init (ht=0x8184d10, nSize=5, pHashFunction=0, pDestructor=0x40223468 destroy_per_dir_entry, persistent=1) at zend_hash.c:185 #4 0x402235d2 in php_create_dir (p=0x817c644, dummy=0x0) at mod_php4.c:669 #5 0x80e47f3 in ap_single_module_configure () #6 0x8077730 in load_module () #7 0x80e30ce in invoke_cmd () #8 0x80e39b3 in ap_handle_command () #9 0x80e3a47 in ap_srm_command_loop () #10 0x80e3e50 in ap_process_resource_config () #11 0x80e4712 in ap_read_config () #12 0x80ee729 in main () #13 0x400ec9cb in __libc_start_main (main=0x80ee49c main, argc=2, argv=0xbad4, init=0x805f3b8 _init, fini=0x812294c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xbacc) at ../sysdeps/generic/libc-start.c:92 Vlad Krupin wrote: I am pretty sure dbase has nothing to do with it. No dbase code gets called before we crash. I do not think it would make a change. I can rebuild the while thing once again from a clean CVS checkout, and see, I guess, but I am quite sure the issue lies with something else. Vlad Markus Fischer wrote: On Wed, Nov 28, 2001 at 02:40:55PM -0800, Vlad Krupin wrote : I finally got around to fixing the dbase bug I have assigned, and... when I tried to compile today's snapshot with a very simple confug line: ./configure --with-apxs=/usr/local/apache/bin/apxs --enable-dbase --enable-debug Did you test it without '--enable-dbase' ? Same problem? - Markus -- 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 #14274: httpd process severely leaks memory for large LDAP queries
From: [EMAIL PROTECTED]
Operating system: Linux 7.2
PHP version: 4.0.6
PHP Bug Type: LDAP related
Bug description: httpd process severely leaks memory for large LDAP queries
I've installed apache-1.3.20-16 , php-4.0.6-7 and php-ldap-4.0.6-7 , all
via the Redhat 7.2 RPMs.
I've also written a simple script to do performance testing against an LDAP
server running on the same machine. The script itself runs fine, but the
memory usage of httpd quickly balloons with each iteration, decreasing the
performance. After running the script for only about 10 times or so, httpd
has used a great deal of memory and swap on the machine and stops
responding. The init script needs to run twice to stop the server, which
frees the memory.
The only thing that shows up in the httpd error.log is a few lines of:
[warn] child process x still did not exit, sending a SIGTERM
The machine has 512MB each of RAM and swap. The LDAP database ldif is
about 7M in size, with about 8k entries.
Please reply if there is any extra information that could be provided. We
had looked forward to developing our DNS application on PHP, and would
still like to make this happen if possible.
Here's the revelant portion of the script:
$queries = array(masterserver=ns2so.cg.shawcable.net,
(|(masterserver=ns2so.cg.shawcable.net)(secondaryserver=ns2so.cg.shawcable.net)),
objectclass=*);
foreach ( $queries as $key = $query ) {
echo LIStarting query \.$query.\...BR;
flush();
$start_time = posix_times();
$search_session = ldap_search($ldap_link_id,
$LDAP_ROOT_DN[$LDAP_SERVER_ID] , $query );
if ( $search_session ) {
$search_results = ldap_get_entries($ldap_link_id,$search_session);
} else {
page_severe_error(Test failed: .my_ldap_error());
}
$end_time = posix_times();
$elapsed_time = ($end_time['ticks'] - $start_time['ticks']) / 100.0;
echo Done. Elapsed time: B.$elapsed_time.s/B.
B.$search_results['count']./B results returned.BRBR/LI\n;
}
Here's the configure command, as reported by PHP:
'./configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib'
'--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-apxs=/usr/sbin/apxs' '--with-bz2'
'--with-curl' '--with-db3' '--with-dom' '--with-exec-dir=/usr/bin'
'--with-gd' '--with-gdbm' '--with-gettext' '--with-jpeg-dir=/usr'
'--with-mm' '--with-openssl' '--with-png' '--with-regex=system'
'--with-ttf' '--with-zlib' '--with-layout=GNU' '--enable-debugger'
'--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-track-vars' '--enable-yp' '--enable-wddx' '--without-mysql'
'--without-unixODBC' '--without-oracle' '--without-oci8' '--with-pspell'
'--with-xml'
--
Edit bug report at: http://bugs.php.net/?id=14274edit=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] references-weirdness???
From the manual: well, being able to read definitely is an advantage :-) i will learn it too ...in other words, your problem is here: thanks -- Wolfram -- 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] Patch: Nested comments
Title: RE: [PHP-DEV] Patch: Nested comments John Donagher writes: Sometimes you need a revolution before you can have evolution. PHP is a good language for a lot of applications, but I'm not sure I would pick it for my next big project anymore. This isn't intended as a slight, just some feedback; but the language doesn't appear to be evolving to encourage quality development the way that Python has. Following this list for a long time leads me to believe that the ideal of maintaining backwards compatibility is one of the big reasons why (concern about execution speed being the other big reason, something I've always been impressed with with the PHP developers). Off the tree, an apple will never be an orange. BC may not be of grave concern to Python developers. Perhaps thats why it hasn't hit the radar screens. You don't get to 6.5 million domains and a million ip addresses chomping big 'BC' pieces off of developers butts. Tthere is nothing wrong with evolution, nor revolution, provided it's carefully thought out, and executed for a reasonable purpose. Nested comments isn't it. Mike Robinson IT / Developer - Toronto Star TV Phone: 416.945.8786 Fax: 416.869.4566 Email: [EMAIL PROTECTED] http://www.torontostartv.com - Webcasting Production http://www.tmgtv.ca - Hometown Television http://www.thestar.com - Canadas largest daily newspaper, The Toronto Star, online -- 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] Patch: Nested comments
On Wed, 28 Nov 2001, Robinson, Mike wrote: BC may not be of grave concern to Python developers. Perhaps thats why it hasn't hit the radar screens. You don't get to 6.5 million domains and a million ip addresses chomping big 'BC' pieces off of developers butts. Two completely different user domains; you can't measure Python usage by mod_python installs. Just like you can't measure Perl usage by mod_perl installs. Tthere is nothing wrong with evolution, nor revolution, provided it's carefully thought out, and executed for a reasonable purpose. Nested comments isn't it. Oh, agreed, my comment was directed towards the general attitude as opposed to the validity of this one particular patch. John -- John Donagher Application Engineer, Intacct Corp. Public key available off http://www.keyserver.net Key fingerprint = 4024 DF50 56EE 19A3 258A D628 22DE AD56 EEBE 8DDD -- 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 #14244 Updated: A bug about integer operation /
ID: 14244 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Variables related Operating System: linux PHP Version: 4.0.6 New Comment: Ignoring my bug report *** It is my wrong. Previous Comments: [2001-11-27 04:11:08] [EMAIL PROTECTED] Yes, did you read the part in ? Obviously not. If either operand is a floating-point value, or the operation results in a non-integer value, a floating-point value is returned. The operation 13/10 will result in 1.3 which is a float, so a floating point value is returned. -Chris [2001-11-27 04:08:33] [EMAIL PROTECTED] Again: If either operand is a floating-point value, or the operation results in a non-integer value, a floating-point value is returned. The division returns a floatingpoint value. [2001-11-27 02:17:50] [EMAIL PROTECTED] Bug Database [EMAIL PROTECTED] Did you see my program?,and dir you run them? obviously, the two operands are ***integers ***. [2001-11-27 01:16:50] [EMAIL PROTECTED] RTM http://www.php.net/manual/en/language.operators.php The division operator (/) returns an integer value (the result of an integer division) if the two operands are integers (or strings that get converted to integers) and the quotient is an integer. If either operand is a floating-point value, or the operation results in a non-integer value, a floating-point value is returned. -Chris [2001-11-27 01:06:51] [EMAIL PROTECTED] Here is a short test program : ? #test.php of integer operation by / $total=13; printf (total %d type %sBR,$total,gettype($total)); $each=10; printf (each %d type %sBR,$each,gettype($each)); $page=$total/$each; print (Page is $page); ? The output is 1.3 not as the expect 1 - configure command ./configure --with-apache=/home/zlq/bin/apache_1.3.22 --with-mysql=/mysql --with-xml --with-charset=gb2312 --disable-debug --enable-ftp --- INIT_VERSION :sysinit-2.78 HOSTTYPE:i386 Edit this bug report at http://bugs.php.net/?id=14244edit=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 #14275: new GD not install
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.0 PHP Bug Type: Compile Failure Bug description: new GD not install There are days I try recompile php with gd2.0.1 and dont means. I get php4.1rc3, but the problem persist. Always I look version GD in phpinfo function, it's show old version. Please help me!! I like obtain a help wich more details. thanks! -- Edit bug report at: http://bugs.php.net/?id=14275edit=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] [PATCH] Valid syntax for array creation from form elements
Thanks for responding to my post, Markus. I did try a search before I posted originally, but didn't find anything relevent. However, on your advice I searched again, and found the thread you were talking about. QUOTE [ No, its not 'how it should work'. Image when you write the following code in php: $interests = something; $interests = new; Would you expect this ending up with $interests being an array(something, new); ? \ Certainly not. So, for you to have an array, like Jani said, append '[]' and you have what you want. - Markus ] That is really a completely different situation though. In my opinion, the most straightforward behavior would be for form elements with the same name (e.g. checkboxes and select menus) to automatically become PHP arrays in the script they are submitted to, without any special syntax. I haven't looked into it enough to know if that's feasible. If that is not feasible, then a different syntax for naming those elements must be created if developers are going to be able to use this feature with XHTML / XML. Currently I use JavaScript to compile the values of checked or selected items with the same name into comma delimited strings which I pass in a hidden field and then explode with PHP. It would be much better to be able to take advantage of this feature. In terms of it working fine with current ECMAScript implementations, of course that's true, but just because the implementation is broken, I'm not going to write broken, proprietary code. Anyway, that would be missing the main point that it is not valid in the value of a name or id attribute. Unless the PHP development community plans to bury its collective head in the sand and pretend that XML doesn't exist, or that it's not important to write valid, interoperable code, it is going to have to address this problem, preferably sooner rather than later. Markus Fischer [EMAIL PROTECTED] wrote on 11/28/01 8:51:03 AM: Well .. there were discussion about this in the past or at leat within some bug reports and it seems its likely to getting changed really soon. Although ECMA doesn't allow it it works fine aith all current (modern ;) implementations to access identfieris with '[' or ']' in the name. For more information you may wan't to search the archive at http://marc.theaimsgroup.com/ . - Markus -- 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 #14275 Updated: new GD not install
ID: 14275 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Compile Failure Operating System: Linux PHP Version: 4.1.0 New Comment: Ask support questions on the mailing lists: http://www.php.net/support.php Previous Comments: [2001-11-28 21:19:07] [EMAIL PROTECTED] There are days I try recompile php with gd2.0.1 and dont means. I get php4.1rc3, but the problem persist. Always I look version GD in phpinfo function, it's show old version. Please help me!! I like obtain a help wich more details. thanks! Edit this bug report at http://bugs.php.net/?id=14275edit=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] BC problem
This code:
$ less test.php
?php
echo phpversion();
echo br /;
include include.php;
include include.php;
test();
?
$ less include.php
?php
if(defined(INCLUDE)) return;
define(INCLUDE, 1);
function test(){
echo test;
}
?
With 4.0.6 I get:
4.0.6
test
With 4.1 RC3 I get:
4.1.0RC3br /br
bFatal error/b: Cannot redeclare test() in
b/home/brian/public_html/include.php/b on line b9/bbr
with CVS I get:
4.2.0-devbr /br /
bFatal error/b: Cannot redeclare test() (previously declared in
/home/brian/public_html/include.php:8) in
b/home/brian/public_html/include.php/b on line b9/bbr /
Andi, Zeev, I thought we were going to back out that change?
Brian.
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: Brian Moon [EMAIL PROTECTED]; Markus Fischer
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, November 28, 2001 2:23 PM
Subject: Re: [PHP-DEV] BC problem
| Yep. As far as I remember it was reverted in 4.1.0
|
| Andi
|
| At 01:54 PM 11/28/2001 -0600, Brian Moon wrote:
| This has already been discussed at great length in another thread. I
| believe it was decided to put it all back like it was for now and decide
on
| a better solution later.
|
| Brian.
|
| - Original Message -
| From: Markus Fischer [EMAIL PROTECTED]
| To: [EMAIL PROTECTED]
| Sent: Wednesday, November 28, 2001 11:05 AM
| Subject: [PHP-DEV] BC problem
|
|
| A small example which shows that BC seems to be broken for a
| certain (but not uncommon) case:
|
| cat include_me.php
| ?
| if (!defined('I_AM_INCLUDED')) {
| define('I_AM_INCLUDED', 1);
| } else {
| echo returningbr\n;
| return;
| }
|
| function cant_be_redefined() {
| }
| ?
|
| cat include_it.php
| ?
| echo 1br\n;
| include 'include_me.php';
| echo 2br\n;
| include 'include_me.php';
| echo 3br\n;
| ?
|
| Now run include_it.php (it doesn't matter if its CGI or
| module):
|
| On PHP 4.0.4pl1 up to 4.0.6 this gives:
| 1br
| 2br
| returningbr
| 3br
|
| But now I get:
| 1br
| 2br
| br /
| Fatal error - Cannot redeclare cant_be_redefined()
| (previously declared in include_me.php:9)
|
| [I shortened the error message to be more readable]
|
|
| If this is 'now the way it is' this should be mentioned
| somewhere very clearly I think. Doesn't seem to be fixable in
| some way? Couldn't find a reference to it e.g. in the NEWS
| file.
|
|
| I know that there should be used include_once() but
| I'm talking about existing code writing that way which
| definitely won't work without modifications.
|
| - Markus
|
| ps: thanks to Jan for verifying this!
|
| --
| Please always Cc to me when replying to me on the lists.
|
| --
| 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]
Re: [PHP-DEV] BC problem
At 11:04 PM 11/28/2001 -0600, Brian Moon wrote: -snip- With 4.0.6 I get: 4.0.6 test With 4.1 RC3 I get: 4.1.0RC3br /br bFatal error/b: Cannot redeclare test() in b/home/brian/public_html/include.php/b on line b9/bbr with CVS I get: 4.2.0-devbr /br / bFatal error/b: Cannot redeclare test() (previously declared in /home/brian/public_html/include.php:8) in b/home/brian/public_html/include.php/b on line b9/bbr / Andi, Zeev, I thought we were going to back out that change? Did you check the 4.1.0 Zeev packaged? It was supposed to be backed out. I don't have time to check now. Andi -- 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] BC problem
Did you check the 4.1.0 Zeev packaged? It was supposed to be backed out. I don't have time to check now. Still present in this package. Similar script as brian: F:\PHP-41~1.0\RELEAS~2php -q test.php hibr bFatal error/b: Cannot redeclare test() in bF:\PHP-41~1.0\RELEAS~2\include.php/b on line b10/bbr F:\PHP-41~1.0\RELEAS~2php -v 4.1.0 - 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] crash+backtrace... is it a known issue?
On Wed, 28 Nov 2001, Vlad Krupin wrote: As expected, same crash, essentially the same backtrace. This time I also excluded MySQL from build. ./configure --with-apxs=/usr/local/apache/bin/apxs --without-mysql --enable-debug Fresh today's checkout, apache 1.2.12. So, is this a known issue? Do you mean 1.2.12, or 1.3.22 ? If you really mean 1.2.12, I recommend you update to 1.3.22. regards, Derick -- 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 #14276: users behind proxy get gibrish on page when compression is used
From: [EMAIL PROTECTED] Operating system: RedHat PHP version: 4.0.6 PHP Bug Type: Zlib Related Bug description: users behind proxy get gibrish on page when compression is used Hi, bug # 10070 says it's closed, however this problem still exists. I will explain: When a user is behind a firewall or a proxy, a compressed page is often served to him with gibrish or broken html source code. If the page is displayed fine and you refresh it, it ALWAYS returns a broken HTML output. If you look at the page source, it appears fine. But the actual page is opened with the header/header HTML content outputted on screen and thus not working (css, javascript, etc). To reiterate: this only happens with Proxy servers. Tested and always repeated with IE 5.5, IE 6.0. Doesn't happen with Netscape 4.7 Thanks, Bira http://bugs.php.net/bug.php?id=10070 -- Edit bug report at: http://bugs.php.net/?id=14276edit=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] crash+backtrace... is it a known issue?
Errr... neither. I meant 1.3.12, of course. I run it just fine with dbase support on a few other machines though...:) I might try a newer version of Apache, but would it really make a difference? 1.3.12 seemed quite stable by itself so far... Vlad Derick Rethans wrote: On Wed, 28 Nov 2001, Vlad Krupin wrote: As expected, same crash, essentially the same backtrace. This time I also excluded MySQL from build. ./configure --with-apxs=/usr/local/apache/bin/apxs --without-mysql --enable-debug Fresh today's checkout, apache 1.2.12. So, is this a known issue? Do you mean 1.2.12, or 1.3.22 ? If you really mean 1.2.12, I recommend you update to 1.3.22. regards, Derick -- 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] Fix for CGI PHP (no more #!/php in displayed content)
As some of you are aware, PHP 4.0.6 has a small glitch on the cgi (rather
than mod) side of things that renders it utterly useless for all practical
purposes. To use a php script via a cgi-script handler (on *nix), obviously
one must include '#! /path/to/php' line as the first in the file.
Unfortunately, the way the php binary handles this line is flawed. Rather
than ignoring this first line, it prints it as the first line of html. This
happens only when running through a web server and not on the command line.
There may be a better way to submit this fix, but as I am new at this, here
it is:
Open sapi/cgi/cgi_main.c in your favorite text editor.
Jump to line 702.
Change this one line from this:
} else if (file_handle.handle.fp file_handle.handle.fp!=stdin) {
to this:
}
if (file_handle.handle.fp file_handle.handle.fp!=stdin) {
I have tested this and it works fine (i.e. it doesn't break running php via
the command line).
Since I am not familiar with the inner workings of PHP or the C proramming
language, I don't know if there is a better fix, but for now, this seems to
be the best one available.
--
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-INST] Fix for CGI PHP (no more #!/php in displayed content)
A couple of additional comments on this. This is not a complete fix as a
blank line still gets printed and generates a Warning in some cases. To
work around this, set output_buffering to On in your php.ini file.
- Original Message -
From: Michael Johnson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Wednesday, November 28, 2001 7:59 AM
Subject: [PHP-INST] Fix for CGI PHP (no more #!/php in displayed content)
As some of you are aware, PHP 4.0.6 has a small glitch on the cgi (rather
than mod) side of things that renders it utterly useless for all practical
purposes. To use a php script via a cgi-script handler (on *nix),
obviously
one must include '#! /path/to/php' line as the first in the file.
Unfortunately, the way the php binary handles this line is flawed. Rather
than ignoring this first line, it prints it as the first line of html.
This
happens only when running through a web server and not on the command
line.
There may be a better way to submit this fix, but as I am new at this,
here
it is:
Open sapi/cgi/cgi_main.c in your favorite text editor.
Jump to line 702.
Change this one line from this:
} else if (file_handle.handle.fp file_handle.handle.fp!=stdin) {
to this:
}
if (file_handle.handle.fp file_handle.handle.fp!=stdin) {
I have tested this and it works fine (i.e. it doesn't break running php
via
the command line).
Since I am not familiar with the inner workings of PHP or the C proramming
language, I don't know if there is a better fix, but for now, this seems
to
be the best one available.
--
PHP Install 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] Bug #14255 Updated: setcookie bug (Cookie is destroyed/Inaccessible)
ID: 14255
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Analyzed
Old Bug Type: HTTP related
Bug Type: Documentation problem
Operating System: Debian 2.2.19
PHP Version: 4.0.6
Old Assigned To:
Assigned To: hholzgra
New Comment:
ok, stupid me regarding the claim that a zero value
(or a string as parameter, evaluating to zero)
actualy deletes a cookie
it indeed defines the cookie to be a session cookie
which is valid until the browser is closed instead
of until a certain date/time is reached
for the time parameter itself:
the time() function returns the server time
while the browser deciedes when to delete
a cookie by the client time
if client and server are not in sync or live in
different time zones you will get exactly the
problems you experienced
you either have to use expiration times in the range of days isntead of hours (as
timezone differences can sum up to slightly more than 24 hours in the worst case) or
you have to use javascript Date.getTime() to fetch the client time and transfer it to
the server as a base for expiration dates instead of using the time() function on the
server
(will add a note to the setcookie documentation and work through the notes later, bug
type switched to documentation problem for now)
Previous Comments:
[2001-11-27 14:28:16] [EMAIL PROTECTED]
IIRC, no time (time=0) means that the cookie will not expire until the session (read:
your browser) has been closed.
Your scripts work fine for me at both Windows 2000 and Debian Linux (Potato).
[2001-11-27 13:59:12] [EMAIL PROTECTED]
array(4) { [xfxdD]= string(4) Blah [wingrep]= array(4) { [customer_cookie]=
string(10) 1150232722 [customer_id]= string(1) 1 [customer_name]= string(13)
Mr. Wilkinson [customer_province]= string(2) BC } [titancart]= array(1) {
[0]= string(72) 33a63c7718-component-1715-108.95-1-Adaptec Fireconnect 4300 3
Port-2.00* } [wingrepship]= array(7) { [ship_to]= string(18) Mr. Kris
Wilkinson [unit_type]= string(5) SUITE [unit_num]= string(3) 101
[street]= string(18) 10464 176th Street [city]= string(8) Edmonton
[province]= string(2) BC [postal]= string(7) T5R 3L6 } }
is what it returns. nothing containing the CustomerCookie
defined previously.
these other values are from original cookies which had the
around the time aspect.
so i'm assuming this means that the value was not stored in a cookie at all?
[2001-11-27 13:59:04] [EMAIL PROTECTED]
array(4) { [xfxdD]= string(4) Blah [wingrep]= array(4) { [customer_cookie]=
string(10) 1150232722 [customer_id]= string(1) 1 [customer_name]= string(13)
Mr. Wilkinson [customer_province]= string(2) BC } [titancart]= array(1) {
[0]= string(72) 33a63c7718-component-1715-108.95-1-Adaptec Fireconnect 4300 3
Port-2.00* } [wingrepship]= array(7) { [ship_to]= string(18) Mr. Kris
Wilkinson [unit_type]= string(5) SUITE [unit_num]= string(3) 101
[street]= string(18) 10464 176th Street [city]= string(8) Edmonton
[province]= string(2) BC [postal]= string(7) T5R 3L6 } }
is what it returns. nothing containing the CustomerCookie
defined previously.
these other values are from original cookies which had the
around the time aspect.
so i'm assuming this means that the value was not stored in a cookie at all?
[2001-11-27 13:48:49] [EMAIL PROTECTED]
Not to sound offensive, have you actually tried it?
I've pasted exactly what you just sent back to me, and it wont go.
There have been many comments in the newsgroups and the function page itself about
this issue ...
people are having to put quotations around the time aspect in order to get it to work
at all, and according to you, that would set the value to zero right?
- cookie.php
?php
setcookie ('CookieName', 'CookieValue', time()+7200);
header (Location: cookie2.php);
?
- cookie2.php
?php
$cookie = $HTTP_COOKIE_VARS[CookieName];
echo $cookie;
?
that's exactly the test script i'm using.
Is there anything wrong with the above?
[2001-11-27 13:43:03] [EMAIL PROTECTED]
setcookie ('CookieName', 'CookieValue', time()+7200);
works. If not you're doing something wrong.
This is NOT a bug in PHP. Ask further support-questions on the appropriate mailinglist
([EMAIL PROTECTED]).
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=14255
Edit this bug report at
