Re: [PHP-DEV] PHP_ADD_LIBRARY
added with PHP_ADD_LIBRARY and without further checks. Also some libraries are linked more than once. That's not a problem. Should we change PHP_ADD_LIBRARY and PHP_ADD_LIBRARY_WITH_PATH to check whether the library was already added and whether at least the file exists? No. It's _ADD_ library, not CHECK_FOR library. - Sascha -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [Fwd: Bug #20858 [Dup-Bgs]: dba_open create always a lockfile]
At 00:02 11.12.2002, Marcus Börger wrote: At 15:22 10.12.2002, Christophe Sollet wrote: Marcus Börger wrote: At 14:04 10.12.2002, Christophe Sollet wrote: Please let me disagree : 20828 is about a bug of new locking scheme with nfs 20858 is not bogus nor a duplicate : letting dba_open managing lock by default BREAK current scripts : If db was meant to be opened read only (by all httpd process) and filesystem have appropiate rights for that (read only), automatic locking will fail (and dba_open too by the way) I have undestand that by adding the new - flag, it will behave as previous release. But why breaking BC ?? By enabling it you may fix existing bugged php script but you may also break working ones. I think it would be better to fix bugged scripts by adding a l or d and keep BC. Christophe. I decided to have locking as default to force users to think about locking. Ok, valuable whish. But what's about users that have already think about it and have implement their own locking system or don't need it (see below) ? Even when you can access a db file only in read mode by php locking is required if any other process may access that file in write mode. Yes, but in our case, the db file is updated by another mean from time to time with a restart of the server : never opened read-write by any process (php or others). Again, the problem can be avoided using - and having php able to manage locking is great but i can't understand why it's better to break things in first place. Further more dba is a superset of db and db was considered to always lock a db file (even though this is done wrong). And i will look at the NFS part later today or tomorrow. Great. marcus Christophe. When i open a db file on a read only nfs directory 'd' works. The modifier 'l' fails when in read mode. After last changes it succeeds even with 'l' when the .lck file already exists. The default is now locking on the database file. If you think you cannot or will not live with this defaul i guess i make it a RFC on php-dev. marcus I forgot to tell about one motivation for the default: GDBM does locking on the file always. So now all handlers behave the same way when no further modifier is used. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Placebo for bug #20539
Hi, Your patch seems to resolve the issue. I've applied it. Thanks, Edin - Original Message - From: Moriyoshi Koizumi [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 5:56 AM Subject: [PHP-DEV] Placebo for bug #20539 Hi, Attached is a patch against the PHP_4_3 branch which appears to fix the bug #20539, while I haven't expected for this to be a cure at all. I guess destruction order of constants and resources have something to do with this issue. Moriyoshi -- 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 10:28 10/12/2002, Sebastian Bergmann wrote: Zeev Suraski wrote: If we use this KISS approach, why the heck are we even considering this rename? 1.) Using 'php' to run a PHP script from the command-line sounds like the right choice of name (for the sapi/cli binary). Maybe, maybe not. I for one think it isn't, considering that PHP is a server-side language and the CLI falls outside the scope of the main project. phpsh or php-cli are much more descriptive names for me. But this discussion is beside the point, see below. 2.) Is keeping BC worth an unintuitive for the sapi/cli binary? Absolutely. No quantifyable gain (I consider phpsh equally intuitive). Does the rename of php to php-cgi for the sapi/cgi binary really cause so much trouble? It requires AFAICS the change of one line in the Apache configuration file Not sure what AFAICS translates to (lost you in the last 'S' in there), but that should already give you some indication that you're in the wrong direction. You have to THINK what the implications are, and you may or may not figure out all of them. Is it worth it? Absolutely not. Fact is, we could name the PHP-CGI phpfoo 5 years ago. People get used to it, set it up that way, and other than sounding weird in the beginning, it doesn't matter much at all. The key part is that 'people get used to it'. People are used to the PHP CGI being 'php'; People will get used to the PHP-CLI regardless of the name you call it. Deriving a conclusion from those two facts should be trivial. 3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. But either way, the fact that it was changed months ago is meaningless. It never made it to a release, and it shouldn't make it to a release, and that's the important thing in my opinion. Zeev -- 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 11:00 10/12/2002, Edin Kadribasic wrote:
The CGI sapi was first renamed to php-cgi on Feb 28, and the change was
temporarily reverted for the 4.2.x release because CLI sapi was
considered experimental.
That maybe the way you see this. A handful of php-dev programmers may see
it in the same way, but then, even not all php-dev programmers see it that
way (me, for instance). As for the hundreds of thousands of users out
there, I'm willing to bet that the vast majority of them don't see it that
way at all, and frankly, that's what matters.
The reason for the name change was discussed on php-dev back then and it
had to do with the fact that most people felt that make install should
install CLI in ${PREFIX}/bin/php.
[snip]
Look, IMHO, it all boils down to the same simple points:
- No drawbacks to naming the PHP CLI as something different than PHP (well,
unless you count the gut feeling of people who 'feel make install should
install CLI in ${PREFIX}/bin/php', without really being able to say why).
- Considerable drawbacks to changing the PHP CGI name. You may argue that
the confusion this would cause is not as bad as I may think, but you cannot
argue that it won't cause confusion. I'm a fairly competent user, and it
still took me a few minutes to understand what was going on and
why. Suffice to say I came across less competent users.
P.S. I wish people were following this list more closely so that we don't
have to discuss same issues over and over again.
Unfortunately this is not an option for all of us at any given time.
I, for one, do wish that the developers here employed a more user-oriented
approach and less 'this should be changed cause it'll be cool/neat/Right'
approach. This would do a lot of good for PHP.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $scalar{index} syntax
yes, whoosp, just found that page. the problem turns out to be
that isset($string{n}) is always false with ZE2, and empty($string{n}) is
always true. same for $string[n]. it works with ZE1, so i'll
just log the bug.
(though it does kick out an 'Uninitialized...' notice, which the same
test on an array key or object property does not. i sympathize with the
bugs that have been logged about that, which have generally been marked
Bogus. but that can be suppressed with @, at least, so not a big thing.)
On Tue, 10 Dec 2002, Rasmus Lerdorf wrote:
You mean $string{2} ? That's the more correct way to do $string[2] to
make it clear that it is a character offset. This has been supported for
years and will not go away.
-Rasmus
On Tue, 10 Dec 2002, Brad Bulger wrote:
trying to fix bugs in some PEAR code, i noticed the person used a way
of getting at the individual characters in a string:
$string{2} === substr($string,2,1)
is that old syntax or something? is there any reason to expect it to work
in future versions?
thanks
--
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
Zeev Suraski wrote: I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. I did not mean to offend you. Not sure what AFAICS translates to (lost you in the last 'S' in there) as far as I can see But either way, the fact that it was changed months ago is meaningless. I agree. What about installing the sapi/cli binary as php when a SAPI apart from sapi/cgi is chosen? Clearly someone who, let's say, builds his or her PHP --with-apxs has no need for a CGI binary. Or do I miss something? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- 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 Wed, 11 Dec 2002, Zeev Suraski wrote: Changing the name from php to php-cli will break BC: [root@saturnus php-4.2.3]# ./configure --enable-cli [root@saturnus php-4.2.3]# make [root@saturnus php-4.2.3]# sapi/cli/php -v 4.2.3 And the CGI is also called 'php' here, having two different binaries with both the name 'php' is even more confusing. So, you're actually proposing to break BC here Zeev? Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- 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 14:00 11/12/2002, Derick Rethans wrote: On Wed, 11 Dec 2002, Zeev Suraski wrote: Changing the name from php to php-cli will break BC: [root@saturnus php-4.2.3]# ./configure --enable-cli [root@saturnus php-4.2.3]# make [root@saturnus php-4.2.3]# sapi/cli/php -v 4.2.3 And the CGI is also called 'php' here, having two different binaries with both the name 'php' is even more confusing. So, you're actually proposing to break BC here Zeev? Uhm, you know it's a twisted way of putting it, but if you want a yes/no answer, then yes. Breaking BC which is a few months old and used by a fragment of users vs. breaking BC that's 5-6 years old and used by hundreds of thousands? I know my pick. Zeev -- 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
3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. But either way, the fact that it was changed months ago is meaningless. It never made it to a release, and it shouldn't make it to a release, and that's the important thing in my opinion. Zeev I on the other hand do recall complaining about this issue, into the typical php-dev vacume. My strong suggestion at the time was to move things back to one binary, which i still beleive is the best solution, exactly for the ease of use issues that Zeev brings up. Shane -- 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 13:00 11-12-2002, Derick Rethans wrote: On Wed, 11 Dec 2002, Zeev Suraski wrote: Changing the name from php to php-cli will break BC: [root@saturnus php-4.2.3]# ./configure --enable-cli [root@saturnus php-4.2.3]# make [root@saturnus php-4.2.3]# sapi/cli/php -v 4.2.3 And the CGI is also called 'php' here, having two different binaries with both the name 'php' is even more confusing. Having the cli in /usr/local/bin when a running server points there, is not very healthy. Just overwriting the cgi binary with a newer version, should not be a problem. So, you're actually proposing to break BC here Zeev? This does not have to be an issue on *nix*. This is where configure options are for - providing people are really to lazy to type 1 alias in their profile environment to alias phpsh[1]/php-cli to the right binary. This is as much a one-time operation as changing a httpd.conf. For win32 binaries - this is a whole different issue and taking into account the stability of the isapi module, this is an area where it's used much. Just leave the cgi module in the root dir and move the cli to bin/ on win32 if you really wanna have the same names. [1] phpsh is not a good name, try running it as your shell... 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
At 13:39 11/12/2002, Sebastian Bergmann wrote: Zeev Suraski wrote: I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. I did not mean to offend you. I wasn't offended (seriously). Not sure what AFAICS translates to (lost you in the last 'S' in there) as far as I can see Ah, right :) But either way, the fact that it was changed months ago is meaningless. I agree. What about installing the sapi/cli binary as php when a SAPI apart from sapi/cgi is chosen? Clearly someone who, let's say, builds his or her PHP --with-apxs has no need for a CGI binary. Or do I miss something? I don't think that having choosing different names based on build flags is a good idea. It's another kind of recipe for confusion. Guys, fact is that it doesn't matter that much what this binary is called. We can call it bhb for all practical purposes (not that I'm suggesting that). People will get used to whatever it's named. Zeev -- 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
[snip]
Look, IMHO, it all boils down to the same simple points:
- No drawbacks to naming the PHP CLI as something different than
PHP (well,
unless you count the gut feeling of people who 'feel make install
should
install CLI in ${PREFIX}/bin/php', without really being able to
say why).
- Considerable drawbacks to changing the PHP CGI name. You may
argue that
the confusion this would cause is not as bad as I may think, but
you cannot
argue that it won't cause confusion. I'm a fairly competent user,
and it
still took me a few minutes to understand what was going on and
why. Suffice to say I came across less competent users.
The big drawback for me is the BC issue of changing all the command
line scripts that contain #!/usr/bin/php in them. I still see no
sense in putting a CGI binary there. Configuring a web server for
running CGI involves manual copy of the PHP binary anyway.
P.S. I wish people were following this list more closely so that
we don't
have to discuss same issues over and over again.
Unfortunately this is not an option for all of us at any given
time.
I, for one, do wish that the developers here employed a more
user-oriented
approach and less 'this should be changed cause it'll be
cool/neat/Right'
approach. This would do a lot of good for PHP.
I don't claim to hold a monopoly on what is a user-oriented
approach. I'd sure like to think that the changes implemented are
for the good of the user. Not because they're cool/neat/Right.
I agree that most of development done in PHP is geared towards the
web. That's what I do for living as well. But in the past 3 years
and about a dozen or so rather large PHP solutions later, I see that
the command line scripting mustn't be neglected either. Why write
backend processes in language other than PHP? Once we have developed
all the classes/libraries for the web solution it is obvious that
the easiest way to implemet the rest of the system is to re-use
those in command line (often run from cron) PHP scripts. And from
what I hear from other development houses, my experiences are far
from unique.
Edin
--
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
-Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: 11 December 2002 12:15 Guys, fact is that it doesn't matter that much what this binary is called. We can call it bhb for all practical purposes (not that I'm suggesting that). People will get used to whatever it's named. If it were me (which, of course, it isn't, but...), I'd leave the cgi as php and call the command-line version phpc. (Well, actually, if it were *just* me, I'd leave them both as php -- even on Windows -- and just make sure I had them in appropriate directories, but I'm extremely aware that real-world users are often not up to that kind of subtlety.) What I absolutely would *not* do is rename the cgi version to php-cgi whilst *simultaneously* introducing a new php with a different purpose. If I were going to do this, I'd want to do it in steps: 1 - cgi to php-cgi + introduce php-cli (so any installations still looking for php get a straight file not found); 2 - php-cli to php. As I'm pretty sure this isn't going to fly, let's go back to my first para...!! Cheers! Mike - Mike Ford, Electronic Information Services Adviser, Learning Support Services, Learning Information Services, JG125, James Graham Building, Leeds Metropolitan University, Beckett Park, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211 -- 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 14:20 11/12/2002, Shane Caraveo wrote: 3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. But either way, the fact that it was changed months ago is meaningless. It never made it to a release, and it shouldn't make it to a release, and that's the important thing in my opinion. Zeev I on the other hand do recall complaining about this issue, into the typical php-dev vacume. My strong suggestion at the time was to move things back to one binary, which i still beleive is the best solution, exactly for the ease of use issues that Zeev brings up. After hashing this a bit on IRC and thinking about it, I tend to think that this is the only solution that makes sense and bug the tiniest amount of people. It may be ugly from a technical standpoint, but frankly, who cares? A dozen or so developers who know and care about what goes on in cgi_main.c. With any other solution, either we screw up the huge CGI community, or we screw up the CLI community (the size of which is subject to debate, but for the sake of the argument, let's assume it's big). I'm +1 on remerging CLI back into CGI. Zeev -- 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 14:02 11.12.2002, Zeev Suraski wrote: At 14:20 11/12/2002, Shane Caraveo wrote: 3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! I did not choose to raise the issue at this time, but I agree completely with the opinion that it's a bad thing; It is my fault that I haven't raised it a few months ago when I noticed this change, but as you might have noticed, I wasn't involved at php-dev back then. But either way, the fact that it was changed months ago is meaningless. It never made it to a release, and it shouldn't make it to a release, and that's the important thing in my opinion. Zeev I on the other hand do recall complaining about this issue, into the typical php-dev vacume. My strong suggestion at the time was to move things back to one binary, which i still beleive is the best solution, exactly for the ease of use issues that Zeev brings up. After hashing this a bit on IRC and thinking about it, I tend to think that this is the only solution that makes sense and bug the tiniest amount of people. It may be ugly from a technical standpoint, but frankly, who cares? A dozen or so developers who know and care about what goes on in cgi_main.c. With any other solution, either we screw up the huge CGI community, or we screw up the CLI community (the size of which is subject to debate, but for the sake of the argument, let's assume it's big). I'm +1 on remerging CLI back into CGI. Zeev This does not work since then you will have pcnt in cgi and such Also there are many differences in the source which would require a hughe amount of if-then-else. And isn't the fraction having problems with renaming CGI to php-cgi itself a very small group compared to the overall of user (only on win*)? And from my guesses in a short time the amount of users working with CLI will outweigh those heavily. (And as somebody mentioned already windows users are used to have problems with php until now. Only the 4.3 release will fix some trouble there.) So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] DOCUMENT_ROOT with Zend API
Hello! I'm writing a new function to PHP using the Zend API. I need to know the DOCUMENT_ROOT value of the running script. I've read through the lxr.php.net and I still have no idea how to do that. Is it possible with the Zend API, at all? Does anybody know the way? Krzysiek Socki [EMAIL PROTECTED] -- 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
So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. Edin -- 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
If we're voting now .. +1 for having CGI as PHP and renaming CLI -1 for having one exe all-in - Original Message - From: Edin Kadribasic [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: Shane Caraveo [EMAIL PROTECTED]; Sebastian Bergmann [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 1:57 PM Subject: Re: [PHP-DEV] php.exe - php-cgi.exe So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. Edin -- 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
[imagine large quantities of quoted text here] On Wed, 11 Dec 2002, Edin Kadribasic wrote: So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. aolme too/aol [imagine large quantities of quoted text here] -- 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
My opinion : Windows : CGI - php.exe CLI - php-cli.exe All other platforms : CLI - php CGI - php-cgi Why I think in this way. Many users use the cgi version under windows. Small percent of the *nix users use php as cgi. Most of the installations are libphp4.so . I know that it is not consistent but in this way it will hurt less people and satisfying those who use the CLI version (mostly if not only on *nix platforms) Andrey - Original Message - From: Wez Furlong [EMAIL PROTECTED] To: Edin Kadribasic [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Shane Caraveo [EMAIL PROTECTED]; Sebastian Bergmann [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, December 11, 2002 4:04 PM Subject: Re: [PHP-DEV] php.exe - php-cgi.exe [imagine large quantities of quoted text here] On Wed, 11 Dec 2002, Edin Kadribasic wrote: So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. aolme too/aol [imagine large quantities of quoted text here] -- 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] DOCUMENT_ROOT with Zend API
Krzysztof Socki wrote: Hello! I'm writing a new function to PHP using the Zend API. I need to know the DOCUMENT_ROOT value of the running script. I've read through the lxr.php.net and I still have no idea how to do that. Is it possible with the Zend API, at all? Does anybody know the way? it is in $_SERVER hash if the SAPI provided it, so that is the place to look for ... is this still about your include-hiding? ever considered auto-prepend files for this? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] DOCUMENT_ROOT with Zend API
Krzysztof Socki wrote: Hello! I'm writing a new function to PHP using the Zend API. I need to know the DOCUMENT_ROOT value of the running script. I've read through the lxr.php.net and I still have no idea how to do that. Is it possible with the Zend API, at all? Does anybody know the way? Krzysiek Socki [EMAIL PROTECTED] and *PLEASE* make some space in your inbox before sending further questions getting E-mail Account: imprev is over the limit of 31457280 bytes. auto-replies all the time is starting to get very annoying -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- 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 Wed, 11 Dec 2002, Edin Kadribasic wrote: So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. .o/ --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Stuffed Inbox on imprev account (phplists@imprev.com ?)
Hartmut Holzgraefe wrote: and *PLEASE* make some space in your inbox before sending further questions getting E-mail Account: imprev is over the limit of 31457280 bytes. auto-replies all the time is starting to get very annoying sorry, should learn to read mail headers more carefully so whoever is related to this account - *PLEASE* turn it off -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-77 -- 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 15:37 11/12/2002, Marcus Börger wrote: This does not work since then you will have pcnt in cgi and such I don't see how that is a problem. You can build --with-pcntl or not. Also there are many differences in the source which would require a hughe amount of if-then-else. That doesn't interest end users and isn't really a problem beyond the tiny scope of the very few php-dev developers who work on cgi_main.c. And isn't the fraction having problems with renaming CGI to php-cgi itself a very small group compared to the overall of user (only on win*)? Hmm no, it effects all CGI users, not just Windows one. There are a hell of a lot more CGI users than there are CLI users. And from my guesses in a short time the amount of users working with CLI will outweigh those heavily. (And as somebody mentioned already windows users are used to have problems with php until now. Only the 4.3 release will fix some trouble there.) I don't think this will ever happen. PHP in CLI mode is popular around php-dev, but it's tiny beyond php-dev (and maybe pear-dev). PHP CGI is huge. And no, PHP under Windows is rock solid as a CGI, so they're already used to having problems approach doesn't apply (it wouldn't have applied either way in my opinion, as having problems is not a reason to add another problem, but still). Zeev -- 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
Somehow it doesn't surprise me that the same people who wanted other BC-breaking changes (minus perhaps Wez) are in favour of this change as well. Just for the record, we never had a real vote on php-dev or any of the other forums, and I don't think we'll start now. php-dev is an open forum and we can all find people that will vote our way if we want to. We have to hash it until we reach something that everyone can live with, or stay with the way things are right now (as in the way PHP 4.2 is, where they're both 'php'). I'm having a very hard time living with the PHP-CGI change, and I find it very difficult to find any drawbacks to keeping the one integrated binary we used to have since 1998(*). Zeev (*) For the record, as a core developer who worked a lot on cgi_main.c I felt the cleanliness issue at least as much as the rest of you, and my gut feeling was that separation is a good idea too. Given the problems we're now bumping into, I changed my mind, and think I (and the rest of you) sinned in thinking about what's cool/neat/Right for us, the few, instead of what's good for the users. Luckily it's not yet too late to prevent that from happening. At 16:53 11/12/2002, Jani Taskinen wrote: On Wed, 11 Dec 2002, Edin Kadribasic wrote: So i am -1 on renaming CLI And +1 on keeing CGI as php-cgi and CLI as php marcus Just for the record: my vote is the same. .o/ --Jani -- 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
And no, PHP under Windows is rock solid as a CGI, so they're already used to having problems approach doesn't apply (it wouldn't have applied either way in my opinion, as having problems is not a reason to add another problem, but still). Just as a note to this, under windows using PHP as a CGI is actually ideal when you're not serving high traffic stuff, like for example the company intranet, or a small extranet. PHP is heavily used for such purposes, and you most likely won't run into a bottleneck from forking php in these cases. -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c php_bcmath.h
On Tue, 10 Dec 2002, Andi Gutmans wrote:
I think this is one of those exceptions where we should probably not go by
our standard and call the function bcpowmod(). It looks a bit funny that
all of the BC functions don't have underscores but only one does. It'll
probably confuse people more than it helps.
What do you guys think?
Yeah, I have to agree with that, but I also think it might be better to
change all functions then and mark the old function names as deprecated
(and make the old names aliasses). If we want to have consistent
function names we better start it right away.
Derick
At 07:04 PM 12/10/2002 +, Sara Golemon wrote:
pollita Tue Dec 10 14:04:29 2002 EDT
Modified files:
/php4/ext/bcmathbcmath.c php_bcmath.h
Log:
Added support for libbcmath's bc_raisemod function as bc_powmod()
Index: php4/ext/bcmath/bcmath.c
diff -u php4/ext/bcmath/bcmath.c:1.43 php4/ext/bcmath/bcmath.c:1.44
--- php4/ext/bcmath/bcmath.c:1.43 Thu Dec 5 16:51:45 2002
+++ php4/ext/bcmath/bcmath.cTue Dec 10 14:04:27 2002
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: bcmath.c,v 1.43 2002/12/05 21:51:45 helly Exp $ */
+/* $Id: bcmath.c,v 1.44 2002/12/10 19:04:27 pollita Exp $ */
#ifdef HAVE_CONFIG_H
#include config.h
@@ -42,6 +42,7 @@
PHP_FE(bcsqrt,
NULL)
PHP_FE(bcscale,
NULL)
PHP_FE(bccomp,
NULL)
+ PHP_FE(bc_powmod,
NULL)
{NULL, NULL, NULL}
};
@@ -324,6 +325,38 @@
}
bc_free_num(first);
bc_free_num(second);
+ bc_free_num(result);
+ return;
+}
+/* }}} */
+
+/* {{{ proto string bc_powmod(string x, string y, string mod [, int scale])
+ Returns the value of an arbitrary precision number raised to the power
of another reduced by a modulous */
+PHP_FUNCTION(bc_powmod)
+{
+ char *left, *right, *modulous;
+ int left_len, right_len, modulous_len;
+ bc_num first, second, mod, result;
+ int scale=bc_precision;
+
+ if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_C, sss|l,
left, left_len, right, right_len, modulous, modulous_len, scale) ==
FAILURE) {
+ WRONG_PARAM_COUNT;
+ }
+
+ bc_init_num(first TSRMLS_CC);
+ bc_init_num(second TSRMLS_CC);
+ bc_init_num(mod TSRMLS_CC);
+ bc_init_num(result TSRMLS_CC);
+ bc_str2num(first, left, scale TSRMLS_CC);
+ bc_str2num(second, right, scale TSRMLS_CC);
+ bc_str2num(mod, modulous, scale TSRMLS_CC);
+ bc_raisemod(first, second, mod, result, scale TSRMLS_CC);
+ Z_STRVAL_P(return_value) = bc_num2str(result);
+ Z_STRLEN_P(return_value) = strlen(Z_STRVAL_P(return_value));
+ Z_TYPE_P(return_value) = IS_STRING;
+ bc_free_num(first);
+ bc_free_num(second);
+ bc_free_num(mod);
bc_free_num(result);
return;
}
Index: php4/ext/bcmath/php_bcmath.h
diff -u php4/ext/bcmath/php_bcmath.h:1.12 php4/ext/bcmath/php_bcmath.h:1.13
--- php4/ext/bcmath/php_bcmath.h:1.12 Fri Nov 22 04:25:28 2002
+++ php4/ext/bcmath/php_bcmath.hTue Dec 10 14:04:27 2002
@@ -16,7 +16,7 @@
+--+
*/
-/* $Id: php_bcmath.h,v 1.12 2002/11/22 09:25:28 sander Exp $ */
+/* $Id: php_bcmath.h,v 1.13 2002/12/10 19:04:27 pollita Exp $ */
#ifndef PHP_BCMATH_H
#define PHP_BCMATH_H
@@ -60,6 +60,7 @@
PHP_FUNCTION(bcsqrt);
PHP_FUNCTION(bccomp);
PHP_FUNCTION(bcscale);
+PHP_FUNCTION(bc_powmod);
#else
--
PHP CVS 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
--
-
Derick Rethans http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals http://php-mag.net/
-
--
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 Wed, 11 Dec 2002, Zeev Suraski wrote: Somehow it doesn't surprise me that the same people who wanted other BC-breaking changes (minus perhaps Wez) are in favour of this change as well. Just for the record, we never had a real vote on php-dev or any of the other forums, and I don't think we'll start now. php-dev is an open forum and we can all find people that will vote our way if we want to. We have to hash it until we reach something that everyone can live with, or stay with the way things are right now (as in the way PHP 4.2 is, where they're both 'php'). I'm having a very hard time living with the PHP-CGI change, and I find it very difficult to find any drawbacks to keeping the one integrated binary we used to have since 1998(*). Zeev (*) For the record, as a core developer who worked a lot on cgi_main.c I felt the cleanliness issue at least as much as the rest of you, and my gut feeling was that separation is a good idea too. Given the problems we're now bumping into, I changed my mind, and think I (and the rest of you) sinned in thinking about what's cool/neat/Right for us, the few, instead of what's good for the users. Luckily it's not yet too late to prevent that from happening. Just for the record, not that it counts much, but I totally agree with you. Couldn't have said it any better than that. Joao -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $scalar{index} syntax
On Tue, 10 Dec 2002, Brad Bulger wrote:
trying to fix bugs in some PEAR code, i noticed the person used a way
of getting at the individual characters in a string:
$string{2} === substr($string,2,1)
is that old syntax or something? is there any reason to expect it to work
in future versions?
This is the recommended systax. (over $string[2]).
Derick
--
-
Derick Rethans http://derickrethans.nl/
PHP Magazine - PHP Magazine for Professionals http://php-mag.net/
-
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Stuffed Inbox on imprev account (phplists@imprev.com ?)
At 16:56 11/12/2002, Hartmut Holzgraefe wrote: Hartmut Holzgraefe wrote: and *PLEASE* make some space in your inbox before sending further questions getting E-mail Account: imprev is over the limit of 31457280 bytes. auto-replies all the time is starting to get very annoying sorry, should learn to read mail headers more carefully so whoever is related to this account - *PLEASE* turn it off I unsubscribed it... Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] note about 4.3.0RC3
Tagging RC3 now. -Andrei http://www.gravitonic.com/ The Heineken Uncertainty Principle: You can never be sure how many beers you had last night. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] rand() broken on dev version?
php version:php4-STABLE-200212101230
apache: 2.0.43
os/platform:solaris 9/sparc
compiler: gcc 3.2
I ran configure with
./configure \
--prefix=${ROOT} \
--with-apxs2=/${ROOT}/bin/apxs \
--with-config-file-path=${ROOT}/conf \
--with-openssl=/usr/local \
--with-xml \
--enable-wddx \
--enable-track-vars \
--enable-trans-sid \
--enable-inline-optimization \
--disable-posix-threads \
--with-mysql=${MYSQLROOT} \
--with-pdflib \
--with-jpeg-dir \
--with-tiff-dir \
--enable-libgcc
The following code spits out 5, 36 times:
for ($i = 0; $i 36; $i++) {
$xrand = rand(5, 15);
echo $xrand br;
}
If I take out the args to rand() then it spits out random numbers
between 0 and whatever (presumably what getrandmax() returns).
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PHP-QA] Test results (fwd)
./configure doesn't find libjpeg for me... but it *is* definitely on my system. This is the output during configure: checking for GD support... yes checking for the location of libjpeg... yes checking for the location of libpng... yes checking for the location of libXpm... yes checking for FreeType 1.x support... yes checking for FreeType 2... yes checking for T1lib support... yes checking whether to enable truetype string function in GD... yes checking for fabsf... yes checking for floorf... yes checking for jpeg_read_header in -ljpeg... yes checking for png_write_image in -lpng... yes If configure fails try --with-xpm-dir=DIR If configure fails try --with-freetype-dir=DIR ... checking for PDFlib support... yes checking for the location of libtiff... yes checking for jpeg_read_header in -ljpeg... (cached) yes ./configure: cd: yes: No such file or directory checking for png_create_info_struct in -lpng... yes ./configure: cd: yes: No such file or directory configure: warning: If configure fails, try --with-tiff-dir=DIR checking for the location of zlib... /usr checking for PDF_show_boxed in -lpdf... yes configure line: ./configure --disable-all --with-gd --with-pdflib --with-jpeg-dir --with-zlib -- Forwarded message -- Date: 11 Dec 2002 19:57:35 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-QA] Test results = FAILED TEST SUMMARY - jpeg -- png conversion test [ext/gd/tests/jpeg2png.phpt] = /dat/dev/php/php-4.3.0RC3/ext/gd/tests/jpeg2png.phpt EXPECTED OUTPUT PNG to JPEG conversion: ok Generated JPEG to PNG conversion: ok JPEG to PNG conversion: ok Generated PNG to JPEG conversion: ok ACTUAL OUTPUT PNG to JPEG conversion: Fatal error: Call to undefined function: imagejpeg() in /dat/dev/php/php-4.3.0RC3/ext/gd/tests/jpeg2png.php on line 5 /dat/dev/php/php-4.3.0RC3/ext/gd/tests/jpeg2png.php(5) : Fatal error - Call to undefined function: imagejpeg() FAILED 001- PNG to JPEG conversion: ok 001+ PNG to JPEG conversion: 002- Generated JPEG to PNG conversion: ok 002+ Fatal error: Call to undefined function: imagejpeg() in /dat/dev/php/php-4.3.0RC3/ext/gd/tests/jpeg2png.php on line 5 003- JPEG to PNG conversion: ok 003+ /dat/dev/php/php-4.3.0RC3/ext/gd/tests/jpeg2png.php(5) : Fatal error - Call to undefined function: imagejpeg() 004- Generated PNG to JPEG conversion: ok BUILD ENVIRONMENT OS: Linux Automake: automake (GNU automake) 1.5 Written by Tom Tromey [EMAIL PROTECTED]. Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Autoconf: Autoconf version 2.13 Libtool: ltmain.sh (GNU libtool) 1.4.2 (1.922.2.54 2001/09/11 03:33:37) Compiler: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-85) Bison: GNU Bison version 1.28 User's E-mail: derick at php dot net PHPINFO phpinfo() PHP Version = 4.3.0RC3 System = Linux kossu.office.jdimedia.nl 2.4.18 #15 Fri Jun 14 13:27:20 CEST 2002 i686 Build Date = Dec 11 2002 20:43:47 Configure Command = './configure' '--with-apache=/dat/dev/php/apache_1.3.27' '--with-gd' '--enable-dbx' '--with-ttf' '--with-mysql' '--with-pdflib=/usr' '--with-config-file-path=/etc/httpd' '--enable-track-vars' '--enable-memory-limit' '--enable-ftp' '--with-mcrypt' '--with-curl' '--enable-curl' '--with-ctype' '--with-gmp' '--with-ldap' '--with-bz2' '--enable-debug' '--with-iconv' '--with-ncurses' '--enable-exif' '--enable-shmop' '--enable-sockets' '--enable-sysvsem' '--enable-sysvsem' '--enable-sysvshm' '--enable-wddx' '--with-zlib' '--with-xmlrpc' '--with-db3' '--with-zip' '--enable-zip' '--with-dom' '--with-openssl' '--enable-mbstring' '--enable-libedit' '--with-srm=/opt/srm' '--with-ming' '--enable-bcmath' '--with-snmp' Server API = Command Line Interface Virtual Directory Support = disabled Configuration File (php.ini) Path = /etc/httpd/php.ini PHP API = 20020918 PHP Extension = 20020429 Zend Extension = 20021010 Debug
[PHP-DEV] Compiling Extensions for Thread-Safety=1 and phpize
Hello, I'm working with a real simple (test) PHP extension, however I've run into some problems when trying to build it. My situation, on a RH 7.3 box, is that of Apache 2/PHP 4 (which has run flawlessly for months, with MySQL 4, by the way) and a CVS snapshot (from last night). I have two seperate source trees (ie, one for Apache DSO, /root/build/php-4.2.3 and one local to my user, as a CLI, ie /home/me/php4/). Both build and install/work fine (DSO to /usr/local/php/ and CLI to /home/me/psh/) Using /home/me/php4/, I followed the instructions at php.net/zend for creating and building a sample extension (./ext_skel, ... etc) which successfully built and worked - no problems. However, I now want to attempt to load that into the DSO version, under Apache. Apache throws: Module compiled with module API=20020429, debug=0, thread-safety=0 PHPcompiled with module API=20020429, debug=0, thread-safety=1 Now I realize I'm in the wrong (I should build the extension against the same source tree as PHP itself is from), however I'm confused about somethings (especially since, all things apparently equal, thread-safety is the only issue here): -- From reading php.net/zend it appears that when using the ./ext_skel method, followed by a ./configure and a make, that I'm rebuilding all of PHP. Is this true, and/or is this the Best Way to development portable, production quality modules? -- So, I've come across the ./phpize method, which when given a generic config.m4 file and some source, will create streamlined ./configure and support files. Then, just a ./configure --enable-mything --with-php-config=/somehwere builds a nice loadable object. But, is this method deprecated? -- It seems, that the only reason Apache couldn't load my extension, was because of thread safety. Since I've been using the php4 CVS source tree, I had recompiled it --with-tsrm-pthreads (and as CLI - does this make sense?), in the hopes that when building my extension against it, thread-safety would be 1. No luck. -- Is it possible to explicitly tell an extension to compile thread-safe? Using either the phpize or ext_skel methods? Clarification on these seemingly different build methods, which is best going forward for portable, production quality extensions, and whether it's possible to force an extension into qualifying as thread-safe, would be appreciated. [ The fact that an extension is truely thread-safe or not, I realize is entirely different - I'm speaking of thread-safety=1 as a PHP check ] Thank you much, = Hans Zaunere New York PHP http://nyphp.org [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Bug #20936 Patch for use of public keys
Hi there, This is the patch for http://bugs.php.net/bug.php?id=20936 The file mentioned in the bug report is no longer available. I have very slightly changed the documentation also. The patch enables reading of public keys with the function openssl_pkey_get_public(). The following piece of code would fail before this patch was applied: ?php $key_string = __EOF__ -BEGIN PUBLIC KEY- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2ksziC2OJin7FhQZSWwC wJwYA43Iomrhm9Fw7+JOCwjnDGTu+kdsEVNBitzB3qrKjkMlqqTSaacuwc7EwRDe FKU0VaGHW8E1S+64juw56LIXEP/0I/r16O/feSd05mlOdNCfsNaZEXRiNQkfySDR loui+699FuXUGUyfIYBVVUmEpTWaH3+vKOmqM9H3ccndAgGC4PVVEGyDfnLMV+l2 uyc9SMAB+OH9qj9cQqI8rqYHTBB5KxjHqHfskvA9bQZEvGlwfz0+fKU/joMqiUie RV8YzKuh6G/zo5UFLgNXuYAGRt90zD+Fer9ivNJAx1yPvCp6OAvdCXMmEtgVJr1V TQIDAQAB -END PUBLIC KEY- __EOF__; $public_key = openssl_pkey_get_public( $key_string ); if ( !$public_key ) echo 'Error: ' . openssl_error_string() . \n; ? Result: Error: error:0906D06C:PEM routines:PEM_read_bio:no start line This is due to the fact that the php_openssl_evp_from_zval() function was only able to deal with certificates. Perhaps this was done on purpose, if so, could anyone explain? Applying the patch will make the above code work and also enable the resulting key resource to be used in e.g. the openssl_public_encrypt() function. Also a check was added to the php_openssl_evp_from_zval() which checks whether a key resource contains a private key if requested (because now it is possible that the key resource only contains a public key). For this a new function was introduced: static int php_openssl_is_private_key(EVP_PKEY* pkey TSRMLS_DC); TODO: perhaps a nicer solution would be to introduce another resource type: 'OpenSSL public key'? Please let me know what you think, Kind regards, Jeroen Derks -- drs. Jeroen Derks, CISSP, SCJP http://www.jeroenderks.com/ [EMAIL PROTECTED]http://www.derks.it/ Derks.IT gsm. +31 (0) 6 5577 8224 Postbus 56791 fax. +31 (0) 84 870 6519 1040 AT Amsterdam tel. +31 (0) 20 777 5488 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS 0RC2
hi guys this has caused me lots of headaches , i would like to address some
issues, first i have tried to compile sablot xslt into php , i had major
dramas with that , as the configure script seem to ignore the path i set to
sablot , and was using the predefined path, so i had to edit both the xslt
and inconv paths, i also had to comment out the version checking for sablot
as i know i have 0.96 but it kept exiting stating that it required 0.96,
further look into this and i found a statement like so
if (version = 0.96){
exit(1);
}
i commented this out
shouldnt it be the other way round ? anyway with the xslt bugs modified to
configure my next issue was with gd, i have downloaded gd 2.0.8 , boutell
had a 4.2.3 patch but he says he was informed it has been patched in the
latest cvs as his patch would not work on my version , unfortunatly that is
not the case , i had to manually string replace gd.h to change the class
functions free to gd_free, now that i got that all working and compiled fine
, i go to use my class scripts again i am now getting annoying errors
stating that the function cannot be found, the script works on another
server and it was working before, so why is it not working now ? i am
referencing the functions like so $this-_encrypt(); but i dont think it
understands this anymore , can anyone shed some light on that is this a bug
?
i would like to take part in the development team somehow i have some c
experience having to modify these files all the time , let me know how i can
take part thanks.
--
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
Just for the record, there is no fork() on Win32. I have little doubt Sterling meant the Win32 equivalent :). The only reason I felt this worth mentioning is that fork() on Unix is a relatively cheap operation, and an advantage unique to Unix. Some have posted here of service providers that host huge numbers of low volume websites using PHP in CGI mode. On Win32 you only have one choice - start a new php.exe instance on every request. This is an expensive operation - possibly even more expensive than the equivalent operation on Unix. On Unix you have another *potential* choice - load the php executable once and fork() on each request. The presence of fork() on Unix offers (at least in theory) a unique performance advantage over Win32. -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 7:50 AM Just as a note to this, under windows using PHP as a CGI is actually ideal when you're not serving high traffic stuff, like for example the company intranet, or a small extranet. PHP is heavily used for such purposes, and you most likely won't run into a bottleneck from forking php in these cases. -- 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
Please mention the name change at least in the NEWS file and maybe php-cli could even output a readable error when beeing called as cgi. that sounds like a nice idea, but how would you know? Derick Perhaps by the presence of CGI environment vars? Sorry I'm amateur. Christoph -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PHP-QA] Test results (fwd)
When you use gd and jpeg configure.m4 from gd will check first for existance of the library file and second for one of its functions. So i guess there is somethink wrong with the #ifdefs in gd.c or in generating them in config.m4. This is all i can say now but perhaps i can take a look into it tomorrow.after sleeping :-) This is you rline: checking for jpeg_read_header in -ljpeg... yes marcus At 21:20 11.12.2002, Derick Rethans wrote: ./configure doesn't find libjpeg for me... but it *is* definitely on my system. This is the output during configure: checking for GD support... yes checking for the location of libjpeg... yes checking for the location of libpng... yes checking for the location of libXpm... yes checking for FreeType 1.x support... yes checking for FreeType 2... yes checking for T1lib support... yes checking whether to enable truetype string function in GD... yes checking for fabsf... yes checking for floorf... yes checking for jpeg_read_header in -ljpeg... yes checking for png_write_image in -lpng... yes If configure fails try --with-xpm-dir=DIR If configure fails try --with-freetype-dir=DIR ... checking for PDFlib support... yes checking for the location of libtiff... yes checking for jpeg_read_header in -ljpeg... (cached) yes ./configure: cd: yes: No such file or directory checking for png_create_info_struct in -lpng... yes ./configure: cd: yes: No such file or directory configure: warning: If configure fails, try --with-tiff-dir=DIR checking for the location of zlib... /usr checking for PDF_show_boxed in -lpdf... yes configure line: ./configure --disable-all --with-gd --with-pdflib --with-jpeg-dir --with-zlib -- Forwarded message -- Date: 11 Dec 2002 19:57:35 - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP-QA] Test results = FAILED TEST SUMMARY - jpeg -- png conversion test [ext/gd/tests/jpeg2png.phpt] = /dat/dev/php/php-4.3.0RC3/ext/gd/tests/jpeg2png.phpt EXPECTED OUTPUT PNG to JPEG conversion: ok Generated JPEG to PNG conversion: ok JPEG to PNG conversion: ok Generated PNG to JPEG conversion: ok ACTUAL OUTPUT PNG to JPEG conversion: Fatal error: Call to undefined function: imagejpeg() in /dat/dev/php/php-4.3.0RC3/ext/gd/tests/jpeg2png.php on line 5 /dat/dev/php/php-4.3.0RC3/ext/gd/tests/jpeg2png.php(5) : Fatal error - Call to undefined function: imagejpeg() FAILED 001- PNG to JPEG conversion: ok 001+ PNG to JPEG conversion: 002- Generated JPEG to PNG conversion: ok 002+ Fatal error: Call to undefined function: imagejpeg() in /dat/dev/php/php-4.3.0RC3/ext/gd/tests/jpeg2png.php on line 5 003- JPEG to PNG conversion: ok 003+ /dat/dev/php/php-4.3.0RC3/ext/gd/tests/jpeg2png.php(5) : Fatal error - Call to undefined function: imagejpeg() 004- Generated PNG to JPEG conversion: ok BUILD ENVIRONMENT OS: Linux Automake: automake (GNU automake) 1.5 Written by Tom Tromey [EMAIL PROTECTED]. Copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Autoconf: Autoconf version 2.13 Libtool: ltmain.sh (GNU libtool) 1.4.2 (1.922.2.54 2001/09/11 03:33:37) Compiler: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-85) Bison: GNU Bison version 1.28 User's E-mail: derick at php dot net PHPINFO phpinfo() PHP Version = 4.3.0RC3 System = Linux kossu.office.jdimedia.nl 2.4.18 #15 Fri Jun 14 13:27:20 CEST 2002 i686 Build Date = Dec 11 2002 20:43:47 Configure Command = './configure' '--with-apache=/dat/dev/php/apache_1.3.27' '--with-gd' '--enable-dbx' '--with-ttf' '--with-mysql' '--with-pdflib=/usr' '--with-config-file-path=/etc/httpd' '--enable-track-vars' '--enable-memory-limit' '--enable-ftp' '--with-mcrypt' '--with-curl' '--enable-curl' '--with-ctype' '--with-gmp' '--with-ldap' '--with-bz2' '--enable-debug' '--with-iconv' '--with-ncurses' '--enable-exif' '--enable-shmop' '--enable-sockets' '--enable-sysvsem' '--enable-sysvsem'
[PHP-DEV] Re: #20887 [Bgs-Ctl]: /php.ini
[EMAIL PROTECTED] wrote:
ID: 20887
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Bogus
+Status: Critical
-Bug Type: Unknown/Other Function
+Bug Type: Scripting Engine problem
Operating System: Mandrqke Linux 9.0
-PHP Version: 4.3.0RC2
+PHP Version: 4.3.0-dev
New Comment:
I just got bitten by this myself too. But it doesn't happen
with CLI for me, only with the Apache module.
Here (Linux) it happens with CLI if I start php without a path and have a
directory named php with a php-cli.ini.
In main/php_ini.c, the location of the executable is used to search the
php-*.ini:
if (sapi_module.executable_location) {
binary_location = estrdup(sapi_module.executable_location);
} else {
binary_location = NULL;
}
In php_cli.c, the executable_location is guessed [1] from argv[0], which can
be almost anything (although it happens to be the executable location
sometimes):
cli_sapi_module.executable_location = argv[0];
But do we really want to search the path of the executable for an ini file?
At least on Unix, that's a rather uncommon place for ini files. Since
this feature (searching the executable path) has not been advertised
anywhere yet, I suggest that it is removed at least for the Unix
versions (I can't speak for the other versions). The builtin path to
php*.ini, the PHPRC variable and the -c switch are quite enough places
to look for ini files, IMHO.
Regards...
Michael
[1]: see the entry in the Unix FAQ about argv[0]:
http://www.erlenstar.demon.co.uk/unix/faq_2.html#SEC23
--
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
Just for the record, there is no fork() on Win32. I have little doubt Sterling meant the Win32 equivalent :). The only reason I felt this worth mentioning is that fork() on Unix is a relatively cheap operation, and an advantage unique to Unix. Some have posted here of service providers that host huge numbers of low volume websites using PHP in CGI mode. On Win32 you only have one choice - start a new php.exe instance on every request. This is an expensive operation - possibly even more expensive than the equivalent operation on Unix. On Unix you have another *potential* choice - load the php executable once and fork() on each request. The presence of fork() on Unix offers (at least in theory) a unique performance advantage over Win32. win32 supports fork in the way I was using it :), CGI semantics make your method of implementation impossible. CreateProcess() is the system call that is used. If you really wanted something similair you could call CreateThread() which would have the same effect. -Sterling -Original Message- From: Sterling Hughes [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 11, 2002 7:50 AM Just as a note to this, under windows using PHP as a CGI is actually ideal when you're not serving high traffic stuff, like for example the company intranet, or a small extranet. PHP is heavily used for such purposes, and you most likely won't run into a bottleneck from forking php in these cases. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PHP-QA] Test results (fwd)
There are other problems with gd, specifically with the xpm stuff. RC3 barfs compiling against external gd libs. Incorporating the changes found in: http://cvs.php.net/co.php/php4/ext/gd/php_gd.h?login=2r=1.49 and http://cvs.php.net/co.php/php4/ext/gd/gd.c?login=2r=1.239 fixes the problem, which didn't occur in RC2. Regards Mike Robinson Marcus Börger writes: When you use gd and jpeg configure.m4 from gd will check first for existance of the library file and second for one of its functions. So i guess there is somethink wrong with the #ifdefs in gd.c or in generating them in config.m4. This is all i can say now but perhaps i can take a look into it tomorrow.after sleeping :-) This is you rline: checking for jpeg_read_header in -ljpeg... yes -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: fong
I am good at php , I want to share my things with other people , I want to join PHP development team. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/gd gd.c php_gd.h
This patch, or at least this part:
-#ifdef HAVE_GD_XPM
+#if defined(HAVE_GD_XPM) defined(HAVE_GD_BUNDLED)
Needs to be merged into the 4.3.0. Something in the build broke my GD
support between RC2 and RC3. This fixes it.
-adam
On Wed, 11 Dec 2002, Ilia Alshanetsky wrote:
iliaa Wed Dec 11 17:25:24 2002 EDT
Modified files:
/php4/ext/gd gd.c php_gd.h
Log:
Fixed build with non-bundled GD. Hidden the anti-alias functions when
non-bundled GD is used and made imagecreatefromxpm() unavailable because
of a bug in the external GD library.
Index: php4/ext/gd/gd.c
diff -u php4/ext/gd/gd.c:1.238 php4/ext/gd/gd.c:1.239
--- php4/ext/gd/gd.c:1.238Wed Dec 11 15:44:44 2002
+++ php4/ext/gd/gd.c Wed Dec 11 17:25:22 2002
@@ -18,7 +18,7 @@
+--+
*/
-/* $Id: gd.c,v 1.238 2002/12/11 20:44:44 pajoye Exp $ */
+/* $Id: gd.c,v 1.239 2002/12/11 22:25:22 iliaa Exp $ */
/* gd 1.2 is copyright 1994, 1995, Quest Protein Database Center,
Cold Spring Harbor Labs. */
@@ -224,7 +224,7 @@
#ifdef HAVE_GD_XBM
PHP_FE(imagecreatefromxbm, NULL)
#endif
-#ifdef HAVE_GD_XPM
+#if defined(HAVE_GD_XPM) defined(HAVE_GD_BUNDLED)
PHP_FE(imagecreatefromxpm, NULL)
#endif
PHP_FE(imagecreatefromgd, NULL)
@@ -1441,7 +1441,7 @@
case PHP_GDIMG_TYPE_GD2PART:
im = (*func_p)(fp, Z_LVAL_PP(srcx), Z_LVAL_PP(srcy),
Z_LVAL_PP(width), Z_LVAL_PP(height));
break;
-#ifdef HAVE_GD_XPM
+#if defined(HAVE_GD_XPM) defined(HAVE_GD_BUNDLED)
case PHP_GDIMG_TYPE_XPM:
im = gdImageCreateFromXpm(fn);
break;
@@ -1508,7 +1508,7 @@
/* }}} */
#endif /* HAVE_GD_XBM */
-#ifdef HAVE_GD_XPM
+#if defined(HAVE_GD_XPM) defined(HAVE_GD_BUNDLED)
/* {{{ proto int imagecreatefromxpm(string filename)
Create a new image from XPM file or URL */
PHP_FUNCTION(imagecreatefromxpm)
@@ -2130,7 +2130,6 @@
{
zval **IM, **x1, **y1, **x2, **y2, **col;
gdImagePtr im;
- int antialias=0;
if (ZEND_NUM_ARGS() != 6 || zend_get_parameters_ex(6, IM, x1, y1, x2, y2,
col) == FAILURE) {
ZEND_WRONG_PARAM_COUNT();
@@ -2145,14 +2144,11 @@
convert_to_long_ex(col);
#ifdef HAVE_GD_BUNDLED
- antialias = im-antialias;
-#endif
- if (antialias) {
+ if (im-antialias)
gdImageAALine(im, Z_LVAL_PP(x1), Z_LVAL_PP(y1), Z_LVAL_PP(x2),
Z_LVAL_PP(y2), Z_LVAL_PP(col));
- } else {
+ else
+#endif
gdImageLine(im, Z_LVAL_PP(x1), Z_LVAL_PP(y1), Z_LVAL_PP(x2),
Z_LVAL_PP(y2), Z_LVAL_PP(col));
- }
-
gdImageLine(im, Z_LVAL_PP(x1), Z_LVAL_PP(y1), Z_LVAL_PP(x2), Z_LVAL_PP(y2),
Z_LVAL_PP(col));
RETURN_TRUE;
@@ -4074,7 +4070,7 @@
}
}
/* }}} */
-#endif
+/* End section: Filters */
/* {{{ proto imagesetantialias(int im, bool on)
Should antialiased functions used or not*/
@@ -4092,8 +4088,7 @@
RETURN_TRUE;
}
/* }}} */
-
-/* End section: Filters */
+#endif
/*
* Local variables:
Index: php4/ext/gd/php_gd.h
diff -u php4/ext/gd/php_gd.h:1.48 php4/ext/gd/php_gd.h:1.49
--- php4/ext/gd/php_gd.h:1.48 Wed Dec 11 15:45:47 2002
+++ php4/ext/gd/php_gd.h Wed Dec 11 17:25:23 2002
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: php_gd.h,v 1.48 2002/12/11 20:45:47 pajoye Exp $ */
+/* $Id: php_gd.h,v 1.49 2002/12/11 22:25:23 iliaa Exp $ */
#ifndef PHP_GD_H
#define PHP_GD_H
@@ -112,12 +112,14 @@
PHP_FUNCTION(imagecreatefromgif);
PHP_FUNCTION(imagecreatefromjpeg);
PHP_FUNCTION(imagecreatefromxbm);
-PHP_FUNCTION(imagecreatefromxpm);
PHP_FUNCTION(imagecreatefrompng);
PHP_FUNCTION(imagecreatefromwbmp);
PHP_FUNCTION(imagecreatefromgd);
PHP_FUNCTION(imagecreatefromgd2);
PHP_FUNCTION(imagecreatefromgd2part);
+#if defined(HAVE_GD_XPM) defined(HAVE_GD_BUNDLED)
+PHP_FUNCTION(imagecreatefromxpm);
+#endif
PHP_FUNCTION(imagegammacorrect);
PHP_FUNCTION(imagedestroy);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: pongsakorn
Developing the PHP runtime,Translating the documentation -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] loading modules
Greetings, I'm not sure if this is the right place to ask, but here it goes... We have a multihosted environment for apache/php and we try to accept all requests to add new php extensions. The problem is that each apache process is using now 20MB of memory... We compile apache with shared object (SO) support for php (and everything else). The php modules are static, but we are planning to chang this to SO as well. Since just a few users will use some of the extensions, is it an overkill to load all php extesions with the web-server startup Aparentely, the SO support for php does not load the extension libraries in runtime (as needed), but it loads them in the startup. I know one could use the function dl(), but this is out of question because too much code have to be rewritten. What could be to ease up the memory usage? I'm not a good coder, but maybe I could help to write something like a dl() for loading a library just as needed... If someone could give me a feedback if there is another way to do what I need, or which part of the code I should look at (I just never even looked into php source :)) Thanks -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 4.3.0RC3
PHP 4.3.0RC3 is out. Please download it from http://qa.php.net/ and test. This is the last release candidate before 4.3.0 final is unleashed. -Andrei http://www.gravitonic.com/ * The future is not what it used to be. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PHP 4.3.0RC3
Whenever PHP 4.3.0 is released will it officially support Apache 2? Thank you, Juan Andrei Zmievski [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... PHP 4.3.0RC3 is out. Please download it from http://qa.php.net/ and test. This is the last release candidate before 4.3.0 final is unleashed. -Andrei http://www.gravitonic.com/ * The future is not what it used to be. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 4.3.0RC3
On Wed, 11 Dec 2002, Juan Rosero wrote: JR Whenever PHP 4.3.0 is released will it officially support Apache 2? I wasn't aware Apache 2 officially supported a working mpm yet? -- 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] loading modules
Hi, You are really best off loading those dso's from your PHP INI. There is a dl() but it does have its issues (performance wise and in some cases stability wise). I think quite a lot of your memory will be shared between the processes so make sure you don't only look at the size of each process but also at how much is shared. Andi At 08:03 PM 12/11/2002 -0800, Gustavo A. Baratto wrote: Greetings, I'm not sure if this is the right place to ask, but here it goes... We have a multihosted environment for apache/php and we try to accept all requests to add new php extensions. The problem is that each apache process is using now 20MB of memory... We compile apache with shared object (SO) support for php (and everything else). The php modules are static, but we are planning to chang this to SO as well. Since just a few users will use some of the extensions, is it an overkill to load all php extesions with the web-server startup Aparentely, the SO support for php does not load the extension libraries in runtime (as needed), but it loads them in the startup. I know one could use the function dl(), but this is out of question because too much code have to be rewritten. What could be to ease up the memory usage? I'm not a good coder, but maybe I could help to write something like a dl() for loading a library just as needed... If someone could give me a feedback if there is another way to do what I need, or which part of the code I should look at (I just never even looked into php source :)) Thanks -- 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] Re: #20947 [Opn-Bgs]: imap won't configure or compile
On 11 Dec 2002 [EMAIL PROTECTED] wrote: ID: 20947 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: linux slackware 8.1 PHP Version: 4.3.0RC3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. I really think we should always mention the reason why you think it's bogus. I for example, have no idea why this bug should be bogus at all; and I also think that the user, or a lot of other developers have no clue. Derick Thank you for your interest in PHP. Previous Comments: [2002-12-11 15:56:11] [EMAIL PROTECTED] I have this problem with versions 4.2.3 and 4.30RC3, didn't try any other. I have searched the mailing lists and saw several messages with the same problem. However, no messages with the solution... My openssl version is 0.9.6h. I have installed imap (imap-2002a.DEV.SNAP-0212051126) and copied the c-client files as stated in your documentation. 1. configured php with following configure: /configure --with-apxs=/usr/local/apache/bin/apxs --with-config-file-path=/etc --with-mysql --with-mcrypt --with-openssl=/us r/local/ssl --with-imap-ssl=/usr/local/lib output: checking for IMAP support... no After running make and make install and restarting apache (DSO module) tried to use imap: Fatal error: Call to undefined function: imap_open() in /var/www/htdocs/tickets/imap_create.php on line 11 2. Tried without with-imap-ssl, but with --with-imap: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-config-file-path=/etc --with-mysql --with-mcrypt --with-openssl=/u sr/local/ssl --with-imap output: configure: error: This c-client library is built with SSL support. Add --with-imap-ssl=DIR to your configure line. Check config.log for details. So, the configure script is finding the c-client libraries. Output from config.log: /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:268: the use of `tmpnam' is dangerous, better use `mkstemp' /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:281: undefined reference to `RAND_seed' /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:286: undefined reference to `SSL_library_init' /usr/local/lib/libc-client.a(osdep.o): In function `ssl_start_work': /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:388: undefined reference to `TLSv1_client_method' /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:388: undefined reference to `SSLv23_client_method' /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:388: undefined reference to `SSL_CTX_new' /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:391: undefined reference to `SSL_CTX_ctrl' /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:395: undefined reference to `SSL_CTX_set_verify' /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:397: undefined reference to `SSL_CTX_set_default_verify_paths' /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:398: undefined reference to `SSL_new' /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:400: undefined reference to `BIO_new_socket' -- Edit this bug report at http://bugs.php.net/?id=20947edit=1 -- - Derick Rethans http://derickrethans.nl/ JDI Media Solutions http://www.jdimedia.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Critical Bug #20887
I THINK the patch below will fix critical bug #20887, but it's late and
I've had a long day so I havn't begun to make sure it'll work properly in
any circumstance, could anyone else have a look and try it out?
See my note in Bug #20887 for an explanation of what my theory about the
problem is.
-Pollita
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c 12 Nov 2002 20:56:47 - 1.106
+++ main/php_ini.c 12 Dec 2002 06:49:50 -
@@ -298,7 +298,9 @@
char *separator_location =
strrchr(binary_location, DEFAULT_SLASH);
if (separator_location) {
- *(separator_location+1) = 0;
+ separator_location[0] = '\0';
+ } else {
+ binary_location[0] = '\0';
}
if (*php_ini_search_path) {
strcat(php_ini_search_path, paths_separator);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Critical Bug #20887
+1 for applying this patch.
and attached is yet another fix as my suggestion.
(a bit dirty, and not tested enough).
Moriyoshi
Sara Golemon [EMAIL PROTECTED] wrote:
I THINK the patch below will fix critical bug #20887, but it's late and
I've had a long day so I havn't begun to make sure it'll work properly in
any circumstance, could anyone else have a look and try it out?
See my note in Bug #20887 for an explanation of what my theory about the
problem is.
-Pollita
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c 12 Nov 2002 20:56:47 - 1.106
+++ main/php_ini.c 12 Dec 2002 06:49:50 -
@@ -298,7 +298,9 @@
char *separator_location =
strrchr(binary_location, DEFAULT_SLASH);
if (separator_location) {
- *(separator_location+1) = 0;
+ separator_location[0] = '\0';
+ } else {
+ binary_location[0] = '\0';
}
if (*php_ini_search_path) {
strcat(php_ini_search_path, paths_separator);
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Index: main/php_ini.c
===
RCS file: /repository/php4/main/php_ini.c,v
retrieving revision 1.106
diff -u -r1.106 php_ini.c
--- main/php_ini.c 12 Nov 2002 20:56:47 - 1.106
+++ main/php_ini.c 12 Dec 2002 07:52:04 -
@@ -287,11 +287,21 @@
efree(binary_location);
binary_location = NULL;
}
+#elif defined(__linux__)
+ binary_location = (char *) emalloc(MAXPATHLEN);
+ binary_location = realpath(/proc/self/exe, binary_location);
+#elif defined(__svr4__)
+ binary_location = (char *) emalloc(MAXPATHLEN);
+ binary_location = realpath(/proc/self/object/a.out, binary_location);
+#elif defined(__FreeBSD__) || defined(__NetBSD__) || defined(__OpenBSD__)
+ binary_location = (char *) emalloc(MAXPATHLEN);
+ binary_location = realpath(/proc/curproc/file, binary_location);
#else
+ binary_location = NULL;
if (sapi_module.executable_location) {
- binary_location = estrdup(sapi_module.executable_location);
- } else {
- binary_location = NULL;
+ if (sapi_module.executable_location[0] == DEFAULT_SLASH) {
+ binary_location =
+estrdup(sapi_module.executable_location);
+ }
}
#endif
if (binary_location) {
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: alexws
Translating the docs into russian. It's a long process, but I'll try to make my best and to add people to this task. Need access to documentation tree. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] mail() bug??
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
