[PHP-DEV] huge memory usage in concat op, ZE2
hey there, I'm using the cvs and ZE2, there seems to be some huge memory usage when concatenating a string to a length over 262080 bytes, when the string length gets to that size the malloc call inside zend_mm_add_memory_block starts grabing memory 262168 bytes at a time, every 8th concatenation (i'm concatenating 1 byte at a time). anyone else seen this? Tom -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Latest ZE2 changes
At 00:41 08.12.2002, Marcus Börger wrote:
At 16:48 07.12.2002, Zeev Suraski wrote:
At 17:02 07/12/2002, Marcus Börger wrote:
Hi Zeev,
I have changed the test files and encountered some problems with the way
you modified my patch:
1) private_002.phpt fails with
004- Fatal error: Call to private method pass::show() from context
'fail' in %s on line %d
004+ Fatal error: Call to public method fail::show() from context 'fail'
in /usr/src/php4-HEAD/tests/classes/private_002.php on line 18
I see the problem. It should be fixed.
Fixed now, thanks.
The new error message is wrong. We are trying to access pass::show and
not fail::show().
2) private_007.phpt and private_007b.phpt both fail with the message
Fatal error: Cannot redeclare private bar::priv() as public foo::priv()
That means the children know about their parents privates what is in
contrast to
our discussion. The reason they do is because you skipped the part of
the patch
where in zend_do_inheritance() a modified version of
zend_hash_merge_ex() was
used to prevent this. But you also do not search for the private method
in the calling
scope. In other words you mainly used the first version of my patch. So
i tried to
strip down zend_hash_merge_with_argument_if() to the portion we need and
tried
to skip copying zje privates. But since privates are no longer looked up
in the
calling scope this fails.
I implement PPP in a different way altogether (it's very loosely based on
your patch, the actual implementation is very different), in order to
avoid having two hash lookups for every method call. I left a comment in
the code that says we may want to improve the error messages, but the
current implementation is quite intentional - it's much more efficient.
However this is about what i did in my first patches and gave up after
discussion with Andi.
Since he was right that the performance loss by the required checks is
outweighted by the
fact that otherwise classes know about private details of their ancestors.
And i remeber having
an agreement on this. And yes you did the execute part in another way but
until now i see
many problems in your way.
3) You left in some snippets of the 'final' patch. Does this mean we are
going to have
final? A new patch is also available.
No, we're not going to add final, at least not for now. I may have
forgotten to remove the scanner part of the patch but it's meaningless :)
Zeev
After the patches today some more things need to be revisited:
4) You allow changing the visibility. In most languages it is only allowed to
decrease the visibility or it is even disallowed. Increasing the
visibility is a
very unfamiliar feature.
5) When you look at test private_007b.phpt you will see that the wrong
method is called. This is a consequence of 2. It seems you optimized to
much.
Looking into deep reveals that we must disallow overriding privates now.
That way the test private_007.phpt is illegal and all current tests i developed
would pass (visibility tests are suspended of cause).
If you agree and the current implementation is the way to go i can comit
the private and protected tests (not including private_007 of cause which
is to be discussed).
6) zend_execute.c, line 2350 should be
if (!(EX(fbc)-op_array.fn_flags (ZEND_ACC_PROTECTED |
ZEND_ACC_PRIVATE))) {
instead of
if (EX(fbc)-op_array.fn_flags ZEND_ACC_PUBLIC) {
as we allow (fn_flags ZEND_FN_PPP_MASK) == 0 being matched to public as
well.
marcus
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Default Return-Path with mail() and qmail
hi, Somehow this is starting to annoy me -- sorry for the unnecessary noise I am causing on this list. I just thought people who are having the same problem would be looking on marc.theaimsgroup.com or google and find a possible fix. I'm not forcing anyone to use it. Setting Return-Path is useless. It's stripped by sendmail, unless it's allowed in the cf file explicetely. Same for postfix version of sendmail. This also applies to qmail-smtpd, however, I'm talking about qmail-inject. You simply need to setup your mailserver correctly and php accordingly, ie: let the webserver user be allowed to use the '-f' sendmail flag and provide this in the arguments of mail() or via ini_set. I'm not using mod_php. And the -f switch is a nice quick-fix, but it would force me to hardcode a Return-Path and how can I be sure that [EMAIL PROTECTED] really exists? It is just more intuitive that if a user supplies a From header, not only human-generated responses will get back to him, but also machine-generated bounces. In no way, should mail() by default equal the RCPT TO user to the From: header - if I would host users, And I'm sure my users don't want me to read their mails. But I HAVE to read bounces. I never touch people's personal stuff otherwise. I would like to know, if they start spammin' or have buggy scripts. That's why logfiles exist. What ever the reason - the final control of this option should remain with the mailserver administrator, not the mail user. I'm not hardcoding Return-Path. -daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Can someone provide a history of this and the problems one will see when trying to run php.exe as a cgi (i.e. follows one of the many install texts out there). This is _sorta_ documented but not really, only the apache2 docs make any mention of it thus far. Regards, Philip On Sun, 8 Dec 2002, Alexander Wagner wrote: On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
I believe the issue here is that PHP won't display the proper HTTP headers in the CLI version: C:\ Php.exe test.php X-Powered-By: PHP/4.2.2 Content-type: text/html Testing 1 2 3 C:\ C:\ Php-cli.exe test.php Testing 1 2 3 C:\ -Original Message- From: Philip Olson [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 11:07 AM To: Alexander Wagner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] php.exe - php-cgi.exe Can someone provide a history of this and the problems one will see when trying to run php.exe as a cgi (i.e. follows one of the many install texts out there). This is _sorta_ documented but not really, only the apache2 docs make any mention of it thus far. Regards, Philip On Sun, 8 Dec 2002, Alexander Wagner wrote: On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? Philip On Sun, 8 Dec 2002, John Coggeshall wrote: I believe the issue here is that PHP won't display the proper HTTP headers in the CLI version: C:\ Php.exe test.php X-Powered-By: PHP/4.2.2 Content-type: text/html Testing 1 2 3 C:\ C:\ Php-cli.exe test.php Testing 1 2 3 C:\ -Original Message- From: Philip Olson [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 11:07 AM To: Alexander Wagner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] php.exe - php-cgi.exe Can someone provide a history of this and the problems one will see when trying to run php.exe as a cgi (i.e. follows one of the many install texts out there). This is _sorta_ documented but not really, only the apache2 docs make any mention of it thus far. Regards, Philip On Sun, 8 Dec 2002, Alexander Wagner wrote: On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 17:55 08.12.2002, Philip Olson wrote: Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? Philip There was no spoon :-) ok start again: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. marcuis On Sun, 8 Dec 2002, John Coggeshall wrote: I believe the issue here is that PHP won't display the proper HTTP headers in the CLI version: C:\ Php.exe test.php X-Powered-By: PHP/4.2.2 Content-type: text/html Testing 1 2 3 C:\ C:\ Php-cli.exe test.php Testing 1 2 3 C:\ -Original Message- From: Philip Olson [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 11:07 AM To: Alexander Wagner Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] php.exe - php-cgi.exe Can someone provide a history of this and the problems one will see when trying to run php.exe as a cgi (i.e. follows one of the many install texts out there). This is _sorta_ documented but not really, only the apache2 docs make any mention of it thus far. Regards, Philip On Sun, 8 Dec 2002, Alexander Wagner wrote: On Sunday 08 December 2002 01:02, John Coggeshall wrote: I think a big ole' message at the end of ./configure will drastically reduce the number of problems. With php.exe? *g* Also, perhaps a check could be put in the CLI version of PHP that would throw an error message if it is being used as a CGI... A _meaningful_ error-message in the right place would be the right thing (tm). Too many people don't read release-notes. regards Wagner -- codito ergo sum -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Admittedly I didn't hear whatever discussion went on before, but I wonder why the need for two different executables? It seems that the presence of the CGI variables SERVER_NAME and SERVER_SOFTWARE are pretty big hints, so you could decide at runtime whether to act as CGI or CLI. For completeness add a couple command line option to force CLI or CGI behavior and you're pretty much done. -Original Message- From: Marcus Borger [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 9:50 AM At 17:55 08.12.2002, Philip Olson wrote: Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? Philip There was no spoon :-) ok start again: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. marcuis -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Sun, 8 Dec 2002, Marcus [iso-8859-1] Börger wrote: At 17:55 08.12.2002, Philip Olson wrote: Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? There was no spoon :-) ok start again: Not sure what this means. There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. Please provide version numbers so it can be documented. Like, WHEN the changes happened. Thanks, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] huge memory usage in concat op, ZE2
At 12:30 AM 12/8/2002 -0800, Tom wrote: hey there, I'm using the cvs and ZE2, there seems to be some huge memory usage when concatenating a string to a length over 262080 bytes, when the string length gets to that size the malloc call inside zend_mm_add_memory_block starts grabing memory 262168 bytes at a time, every 8th concatenation (i'm concatenating 1 byte at a time). anyone else seen this? It makes sense that this is happening to you. Reaching the point where you add to a string of such size is very bad coding practice (unless you really have no choice). This is because if the memory manager can't realloc() (it very often can't) then it'll have to allocate a new block and use a memcpy() to copy over all of the string. The current code is less than optimal in this case and I can choose various strategies to improve on it but there will always be times where the malloc()/memcpy() will be necessary. So what are you doing? Is it something you have to do? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. Well no offence, but renaming the CGI executable is just plain wrong. The CLI executable should be named php-cli.exe. This seems like such a nobrainer. Am I missing something? Clue me in. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. marcus It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 19:28 08.12.2002, Philip Olson wrote: On Sun, 8 Dec 2002, Marcus [iso-8859-1] Börger wrote: At 17:55 08.12.2002, Philip Olson wrote: Wait, so there used to be a php-cli.exe ? Add that to the history request question :) And so a user tries to install via some install tutorial on foo.com, what problems/errors will they see when accessing via the browser? There was no spoon :-) ok start again: From the film Matrix: ther is no spoon :-))) Not sure what this means. There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. Please provide version numbers so it can be documented. Like, WHEN the changes happened. Thanks, Philip -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Christoph Grottolo wrote: It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). This is the way it should stay. I'm trying to find the archive of the discussion that lead to this being changed. I'm having a huge problem getting my head around why the name of the CGI executable has to be changed at all. Any pointers or enlightenment would be welcomed. :) Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mail() problem
Hi, I'm using the mail() function to send out mails. The problem I'm having is the subject line shows up in the message body. Anybody has any ideas? TIA -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php.exe - php-cgi.exe
At 20:37 08.12.2002, Christoph Grottolo wrote: Marcus Börger wrote: There was no cli and only cgi binary called php.exe. Then we decided to have a command line executable (abbrevation CLI). And the we decided to use 'php.exe' for the new CLI and to avoid confusion we chose to rename the CGI binary from 'php.exe'. So now there will be some books and other papers and online docs out there which state that php.exe has to be installedIn other words there will be users who install CLI as CGI what will lead into errors. marcus It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). Christoph But in 4.2.x CLI sapi was experimental so there is no need to change anything because of that. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
At 22:08 08.12.2002, Mike Robinson wrote: Christoph Grottolo wrote: It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). This is the way it should stay. I'm trying to find the archive of the discussion that lead to this being changed. I'm having a huge problem getting my head around why the name of the CGI executable has to be changed at all. Any pointers or enlightenment would be welcomed. :) Regards Mike Robinson Just because you only need to type the name of the CGI sapi once: In other word one single time until we decide the name changes. But you will use a command line interface hopefully very often. I for one do and i am not going to type php-cli.exe because it is way much to long. The reason against renaming CGI and using its old name for the CLI now would have lead us to register_globals=ON for eternity. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Sun, 8 Dec 2002, Marcus Börger wrote: MBr Just because you only need to type the name of the CGI sapi once: MBr In other word one single time until we decide the name changes. MBr But you will use a command line interface hopefully very often. I MBr for one do and i am not going to type php-cli.exe because it is way MBr much to long. Sorry Marcus, but - even though I think these names are better - the same could be said for a cli: ln -s php-cli php or even: alias php /usr/local/bin/php-cli For windows - you could move php-cli.exe to C:\WINNT\system32\php.exe and it's preferred in the path (or set %PATH%). But - changing the name for the CGI, breaks server environments... I think on windows, the two executables, should be named the php.exe and the cgi stored in the standard php4 dir and the cli version in bin/. This way you have the best of both worlds - it won't break CGI - and a simple PATH adjustment takes care of the cli problem. For unices, we could provide a --with-cgi-name configure option and default to php, with --disable-cli. Just my 2c -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
As much as I understand the point of view that renaming the CGI version of PHP from php(.exe) to php-cgi(.exe) so that we don't have to type 'php-cli' perhaps isn't such a good idea, I am completely against changing it now. Changing it the first time is obviously causing problems, changing it again will really muddle the waters... (Okay, if you downloaded PHP between the months of XXX and , it's this... Otherwise, it's that... Unless...) Regards, John -Original Message- From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]] Sent: Sunday, December 08, 2002 6:28 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] php.exe - php-cgi.exe On Sun, 8 Dec 2002, Marcus Börger wrote: MBr Just because you only need to type the name of the CGI sapi once: MBr In other word one single time until we decide the name changes. MBr But you will use a command line interface hopefully very often. I MBr for one do and i am not going to type php-cli.exe because it is MBr way much to long. Sorry Marcus, but - even though I think these names are better - the same could be said for a cli: ln -s php-cli php or even: alias php /usr/local/bin/php-cli For windows - you could move php-cli.exe to C:\WINNT\system32\php.exe and it's preferred in the path (or set %PATH%). But - changing the name for the CGI, breaks server environments... I think on windows, the two executables, should be named the php.exe and the cgi stored in the standard php4 dir and the cli version in bin/. This way you have the best of both worlds - it won't break CGI - and a simple PATH adjustment takes care of the cli problem. For unices, we could provide a --with-cgi-name configure option and default to php, with --disable-cli. Just my 2c -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Pear installer and case-insensative OS's
Hi, pear won't install on cygwin, simply because the 'PEAR' dir is missing from the cvs checkout - culprit: pear/.cvsignore contains 'pear' (yes lowercase). Result: Warning: main(PEAR/Installer.php) [http://www.php.net/function.main]: failed to create stream: No such file or directory in /home/msopacua/cvs/php4/pear/install-pear.php on line 9 How about renaming that dir? -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
Marcus Börger wrote: At 22:08 08.12.2002, Mike Robinson wrote: Christoph Grottolo wrote: It's worse. At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe (CGI). This is the way it should stay. I'm trying to find the archive of the discussion that lead to this being changed. I'm having a huge problem getting my head around why the name of the CGI executable has to be changed at all. Any pointers or enlightenment would be welcomed. :) Regards Mike Robinson Just because you only need to type the name of the CGI sapi once: In other word one single time until we decide the name changes. But you will use a command line interface hopefully very often. I for one do and i am not going to type php-cli.exe because it is way much to long. Every system on the planet that uses php.exe as their CGI executable, and I suggest there are quite a few, will have a broken setup with a stock install of php-4.3.0, because typing php-cli.exe at the command line is too long. And you expect putting huge notes and warnings in the news file and installer will prevent this from happening. The reason against renaming CGI and using its old name for the CLI now would have lead us to register_globals=ON for eternity. Totally different. Apples and oranges. That was a security-related change, and IMHO, the amount of trouble _that_ change caused far outweighed the meagre benefits achieved. This change is going to break a lot of setups for the sake of cli users saving a few keystrokes. Sorry. There's just no way this should happen. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug #20807
Hi, the attached patch fixes bug #20807. It's against current HEAD. Verified to install 'php' and 'php-cli' (without the exe extension). -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? Index: sapi/cli/config.m4 === RCS file: /repository/php4/sapi/cli/config.m4,v retrieving revision 1.12 diff -u -r1.12 config.m4 --- sapi/cli/config.m4 14 Nov 2002 01:09:46 - 1.12 +++ sapi/cli/config.m4 9 Dec 2002 00:21:26 - @@ -22,6 +22,10 @@ *darwin*) BUILD_CLI=\$(CC) \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(NATIVE_RPATHS) \$(PHP_GLOBAL_OBJS:.lo=.o) \$(PHP_CLI_OBJS:.lo=.o) \$(PHP_FRAMEWORKS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH) ;; + *cygwin*) +SAPI_CLI_PATH=sapi/cli/php.exe +BUILD_CLI=\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) +\$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) +\$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH) +;; *) BUILD_CLI=\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH) ;; Index: sapi/cgi/config9.m4 === RCS file: /repository/php4/sapi/cgi/config9.m4,v retrieving revision 1.3 diff -u -r1.3 config9.m4 --- sapi/cgi/config9.m4 1 Dec 2002 21:50:35 - 1.3 +++ sapi/cgi/config9.m4 9 Dec 2002 00:21:26 - @@ -86,7 +86,14 @@ AC_MSG_RESULT(yes) PHP_ADD_MAKEFILE_FRAGMENT($abs_srcdir/sapi/cgi/Makefile.frag) -SAPI_CGI_PATH=sapi/cgi/php-cgi +case $host_alias in + *cygwin* ) +SAPI_CGI_PATH=sapi/cgi/php-cgi.exe +;; + * ) +SAPI_CGI_PATH=sapi/cgi/php-cgi +;; +esac PHP_SUBST(SAPI_CGI_PATH) PHP_TEST_WRITE_STDOUT -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] php.exe - php-cgi.exe
On Sun, 8 Dec 2002, John Coggeshall wrote: JC JC As much as I understand the point of view that renaming the CGI version JC of PHP from php(.exe) to php-cgi(.exe) so that we don't have to type JC 'php-cli' perhaps isn't such a good idea, I am completely against JC changing it now. Changing it the first time is obviously causing JC problems, changing it again will really muddle the waters... (Okay, if JC you downloaded PHP between the months of XXX and , it's this... JC Otherwise, it's that... Unless...) Ehm - the last __released__ version is php.exe vs. php-cli.exe. We shouldn't care about RC's/pre's and cvs builds. Live 'on the edge' - be prepared for a landing. JC JC Regards, JC JC John JC JC JC -Original Message- JC From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]] JC Sent: Sunday, December 08, 2002 6:28 PM JC To: [EMAIL PROTECTED] JC Cc: [EMAIL PROTECTED]; 'Christoph Grottolo'; [EMAIL PROTECTED] JC Subject: RE: [PHP-DEV] php.exe - php-cgi.exe JC JC JC On Sun, 8 Dec 2002, Marcus Börger wrote: JC JC MBr Just because you only need to type the name of the CGI JC sapi once: JC MBr In other word one single time until we decide the name changes. JC MBr But you will use a command line interface hopefully JC very often. I JC MBr for one do and i am not going to type php-cli.exe because it is JC MBr way much to long. JC JC Sorry Marcus, but - even though I think these names are better JC - the same could be said for a cli: ln -s php-cli php or even: JC alias php /usr/local/bin/php-cli JC JC For windows - you could move php-cli.exe to JC C:\WINNT\system32\php.exe and it's preferred in the path (or JC set %PATH%). JC JC But - changing the name for the CGI, breaks server environments... JC JC I think on windows, the two executables, should be named the JC php.exe and the cgi stored in the standard php4 dir and the JC cli version in bin/. This way you have the best of both worlds JC - it won't break CGI - and a simple PATH adjustment takes care JC of the cli problem. JC JC For unices, we could provide a --with-cgi-name configure JC option and default to php, with --disable-cli. JC JC Just my 2c JC -- JC With kind regards, JC JC Melvyn Sopacua JC ?php include(not_reflecting_employers_views.txt); ? JC JC JC -- JC PHP Development Mailing List http://www.php.net/ JC To unsubscribe, visit: http://www.php.net/unsub.php JC JC JC JC JC -- JC PHP Development Mailing List http://www.php.net/ JC To unsubscribe, visit: http://www.php.net/unsub.php JC JC -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mail() problem
Hi, I'm using the mail() function to send out mails. The problem I'm having is the subject line shows up in the message body. Anybody has any ideas? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mail() problem
On Sun, 8 Dec 2002, stormryder wrote: s Hi, s I'm using the mail() function to send out mails. s The problem I'm having is the subject line shows up in the message body. s s Anybody has any ideas? If you ask on the right list, like [EMAIL PROTECTED], then maybe somebody get's inspired. PS: it might help to provide some sample code... -- With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] huge memory usage in concat op, ZE2
I was reading an email from stdin. But regardless of bad coding style
:-), the script is using _way_ more memory than it should.
$s = '';
while(strlen($s) 266768) {
$s.= 'd';
}
this code uses 151Megs on my system. the same code uses about 2megs with
php4.3. php4.3 seems to realloc/memcpy when the string gets big, and
php5 just does malloc's and memcpy's (I don't see calls to free()
though). I'm thinking the problem might be in zend_mm_realloc?
Tom
Andi Gutmans [EMAIL PROTECTED] wrote:
At 12:30 AM 12/8/2002 -0800, Tom wrote:
hey there,
I'm using the cvs and ZE2, there seems to be some huge memory usage when
concatenating a string to a length over 262080 bytes, when the string
length gets to that size the malloc call inside
zend_mm_add_memory_block starts grabing memory 262168 bytes at a time,
every 8th concatenation (i'm concatenating 1 byte at a time).
anyone else seen this?
It makes sense that this is happening to you. Reaching the point where you
add to a string of such size is very bad coding practice (unless you really
have no choice). This is because if the memory manager can't realloc() (it
very often can't) then it'll have to allocate a new block and use a
memcpy() to copy over all of the string.
The current code is less than optimal in this case and I can choose various
strategies to improve on it but there will always be times where the
malloc()/memcpy() will be necessary.
So what are you doing? Is it something you have to do?
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] huge memory usage in concat op, ZE2
I'll try and see what I can do about this.
Andi
At 11:56 AM 12/8/2002 -0800, Tom Fishwick wrote:
I was reading an email from stdin. But regardless of bad coding style
:-), the script is using _way_ more memory than it should.
$s = '';
while(strlen($s) 266768) {
$s.= 'd';
}
this code uses 151Megs on my system. the same code uses about 2megs with
php4.3. php4.3 seems to realloc/memcpy when the string gets big, and
php5 just does malloc's and memcpy's (I don't see calls to free()
though). I'm thinking the problem might be in zend_mm_realloc?
Tom
Andi Gutmans [EMAIL PROTECTED] wrote:
At 12:30 AM 12/8/2002 -0800, Tom wrote:
hey there,
I'm using the cvs and ZE2, there seems to be some huge memory usage when
concatenating a string to a length over 262080 bytes, when the string
length gets to that size the malloc call inside
zend_mm_add_memory_block starts grabing memory 262168 bytes at a time,
every 8th concatenation (i'm concatenating 1 byte at a time).
anyone else seen this?
It makes sense that this is happening to you. Reaching the point where you
add to a string of such size is very bad coding practice (unless you
really
have no choice). This is because if the memory manager can't realloc() (it
very often can't) then it'll have to allocate a new block and use a
memcpy() to copy over all of the string.
The current code is less than optimal in this case and I can choose
various
strategies to improve on it but there will always be times where the
malloc()/memcpy() will be necessary.
So what are you doing? Is it something you have to do?
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
