Re: [PHP-DEV] Re: Latest ZE2 changes
At 15:44 08/12/2002, Marcus Börger wrote: 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). How do you arrive in that conclusion? The algorithm was designed to fully support it. Running private_007 also appears to be working for me (there was a buglet in the parser with static+access level, but if you remove the statics and/or update to the latest CVS, you can see that it's working fine...) 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 19:50 09/12/2002, Marcus Börger wrote: At 19:46 09.12.2002, Andrei Zmievski wrote: On Mon, 09 Dec 2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I am actually in favor of CLI executable being 'php'. If it's a problem on Windows, then we could possibly compromise and have the CGI version being called php.exe, but I think that it's important we keep it 'php' on UNIX. I am strongly against having two different names for the same thing on different machine targets. And Remeber: you can use the win executable by calling 'php' without '.exe' as well. I agree with Marcus. 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 19:46 09/12/2002, Andrei Zmievski wrote: On Mon, 09 Dec 2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I am actually in favor of CLI executable being 'php'. If it's a problem on Windows, then we could possibly compromise and have the CGI version being called php.exe, but I think that it's important we keep it 'php' on UNIX. Why? PHP as a shell is going to be used by only a fragment of the amount of users who use it as a CGI. In most senses, it's much more PHP than the CLI is. Even though the old version was being used as a shell, it was still quite clear that it is the CGI version. And it is quite clear that the CLI version is the one that's new... 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 18:57 09/12/2002, John Coggeshall wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking Why when I look at phpsh I think Sushi... Is that good or bad? :) -- 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 18:27 09/12/2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I agree with Andi, except I'm a bit more decisive - I'm quite against the name change, and even more against the fact the CGI now relies in sapi/cgi instead of where it was. 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 23:11 09/12/2002, Frank M. Kromann wrote: 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. These are good points. I think that's a bit like inventing problems and then trying to fix them. Let's keep it down to things we can determine relatively easily: - Nothing bad will happen if we name the new CLI with whatever kind of name - php-cli, phpsh, whatever - There WILL be some level of confusion if we rename the CGI binary If we use this KISS approach, why the heck are we even considering this rename? 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 01:27 10/12/2002, John Coggeshall wrote: 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. As I already said, we should put this in the message created at the end of ./configure, in the release notes, in the news file, on the website, and perhaps send a mass e-mail to everyone whom has ever worked with PHP ;) Or, we could just avoid this rename which would save us all of this headache and have no drawbacks at all. 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
On Mon, 9 Dec 2002, Leon Atkinson wrote: out on a limb Would it be a tragedy to name both the CLI and CGI versions php on UNIX and php.exe on Windows? Yes, it's a support nightmare. 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
On Mon, 9 Dec 2002, Christoph Grottolo wrote: When installing a sapi for a web server i do it once and every time i update it i look if i have to change something in the setup - even file names. And before updating anything i test the stuff on a non production system. I hope (and I know) there's more evolution in php 4.3 than a senseless rename of php.exe on windows. I know you're right - but beeing right is not always the same as doing the right thing. 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 -- - 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] New function: bcpowmod()
On Mon, 9 Dec 2002, Sara Golemon wrote:
I'd like to add a new function to the bcmath module. It's very similar to
the bcpow() function except that it takes advantage of a fast
exponentiation method when used with a modulous.
Based on the function call into libbcmath to bc_raisemod() {bcpow() uses
bc_raise()}, it would seem to make the most sense to call the php version
of the function bcpowmod(), but with the change in naming conventions
I'm more inclined to call it something closer to bcmath_raisemod() or
bcmath_powmod().
Am I overcomplicating things by agonizing over the name?
I'd love to hear your thoughts
I'd go with bc_powmod().
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
On Tue, 10 Dec 2002, Zeev Suraski wrote:
I think that's a bit like inventing problems and then trying to fix them.
Let's keep it down to things we can determine relatively easily:
- Nothing bad will happen if we name the new CLI with whatever kind of name
- php-cli, phpsh, whatever
- There WILL be some level of confusion if we rename the CGI binary
If we use this KISS approach, why the heck are we even considering this rename?
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.
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. The goal was to make the php interpreter
installed on as many machines as possible. And for the reasons of keeping
BC CLI sapi was named php so that existing scripts that have
#!/usr/bin/php shebang line would not have to be modified. For the same
reason CLI silently ignores some command line options (like -q and -C).
The next logical questions was what to do with the CGI sapi. It made very
little sense to make install it under the same name in some different
folder, so a decision was reached to rename it to php-cgi. make install
and cgi make very little sense anyway since the installer has no way of
knowing what's the correct location for the binary. Configuring a server
for execution of php as a cgi requires manual configuration anyway.
Windows file rename merely mirrored that of the unix build.
I'm still of the oppinion that we should leave things as they are in PHP
4.3.0-dev for the reasons stated.
Edin
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.
--
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'm a little surprised that people from Zend is rather prefer to call php for CGI and php-cli for CLI. IMO, Zend products, such as Zend Encoder or Zend IDE, have more chance to sell if PHP is used as replacement for Perl or Python (or even Java). The name of command line interface may not affect sales of Zend products, though. Just my .02 -- Yasuo Ohgaki Zeev Suraski wrote: At 19:46 09/12/2002, Andrei Zmievski wrote: On Mon, 09 Dec 2002, Andi Gutmans wrote: ducking Maybe phpsh would be a good idea for the name of the CLI? It wouldn't confuse ppl as much as php-cli /ducking I'm really not that sure it makes sense to rename the CGI from php to php-cgi after such a long time. It's not as if we're breaking BC for the sake of adding very much needed functionality. Anyway, I'm -0 for the change and +0 to find a more suitable name for the CLI :) I am actually in favor of CLI executable being 'php'. If it's a problem on Windows, then we could possibly compromise and have the CGI version being called php.exe, but I think that it's important we keep it 'php' on UNIX. Why? PHP as a shell is going to be used by only a fragment of the amount of users who use it as a CGI. In most senses, it's much more PHP than the CLI is. Even though the old version was being used as a shell, it was still quite clear that it is the CGI version. And it is quite clear that the CLI version is the one that's new... 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
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). 2.) Is keeping BC worth an unintuitive for the sapi/cli binary? 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 Action application/x-httpd-php /php/php.exe to Action application/x-httpd-php /php/php-cgi.exe 3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! -- 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 Tue, Dec 10, 2002 at 10:28:54AM +0100, Sebastian Bergmann wrote : 3.) Why this late discussion of the issue? The name of the sapi/cgi binary was changed months ago! Because only if you start a release cycle and announce it properly people notice the NEWS which only happened now. More non-developers are getting aware of the upcommong 4.3 release and start to absorb the NEWS and question it. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Macros for global startup/shutdown functions
Hi! How come there are no macros for global startup and shutdown functions? The Zend API documentation refers to such terms and even instructs that one should use STANDARD_MODULE_PROPERTIES_EX instead of STANDARD_MODULE_PROPERTIES if global functions are to be used. I have even found references to ZEND_GINIT/GSHUTDOWN on the web, but... Admittedly, I haven't checked newer versions, but as I am using 4.1.2 and these terms have been used dating back to the 4.0 release this doesn't seem to be the issue. Regards Thomas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Macros for global startup/shutdown functions
On Tue, 10 Dec 2002, Thomas Wentzel wrote: Hi! How come there are no macros for global startup and shutdown functions? The Zend API documentation refers to such terms and even instructs that one should use STANDARD_MODULE_PROPERTIES_EX instead of STANDARD_MODULE_PROPERTIES if global functions are to be used. I have even found references to ZEND_GINIT/GSHUTDOWN on the web, but... Admittedly, I haven't checked newer versions, but as I am using 4.1.2 and these terms have been used dating back to the 4.0 release this doesn't seem to be the issue. GINIT and GSHUTDOWN where removed about a year ago because they weren't really used anyway, and had no real purpose anyway for them. *sigh* it just shows that the docs are quite outdated; I'll have a look at it now. 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
[PHP-DEV] RE: [PHP-QA] RE: Class function pain
On Tue, 10 Dec 2002, Dan Rossi wrote: its bizarre my class was working on rc01 , i'm basically getting function cannot be found error when i call a fucntion like so $this-_encrypt(); for instance Fatal error: Call to undefined function: _encrypt() in /www/servers/electroteque/web/galleries/lib/authenticate.php on line 311 Can you narrow this down a little bit, and can you try to remove Zend/zend_language_parser.y and do rm configure ./buildconf ./configure again? (and please cc php-dev@) 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] Macros for global startup/shutdown functions
Thanks, Derick! Does this also mean, that I can't hardcode this functionality? (ie. adding to functions to the zend_module_entry struct) As it is I actually have a use for this, and have succesfully compiled my extension with references to such hardcoded functions - allthough they don't seem to get called at this point! /Thomas Derick Rethans wrote: On Tue, 10 Dec 2002, Thomas Wentzel wrote: Hi! How come there are no macros for global startup and shutdown functions? The Zend API documentation refers to such terms and even instructs that one should use STANDARD_MODULE_PROPERTIES_EX instead of STANDARD_MODULE_PROPERTIES if global functions are to be used. I have even found references to ZEND_GINIT/GSHUTDOWN on the web, but... Admittedly, I haven't checked newer versions, but as I am using 4.1.2 and these terms have been used dating back to the 4.0 release this doesn't seem to be the issue. GINIT and GSHUTDOWN where removed about a year ago because they weren't really used anyway, and had no real purpose anyway for them. *sigh* it just shows that the docs are quite outdated; I'll have a look at it now. 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] Re: Latest ZE2 changes
At 10:02 10.12.2002, Zeev Suraski wrote:
At 15:44 08/12/2002, Marcus Börger wrote:
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).
How do you arrive in that conclusion? The algorithm was designed to fully
support it. Running private_007 also appears to be working for me (there
was a buglet in the parser with static+access level, but if you remove the
statics and/or update to the latest CVS, you can see that it's working fine...)
Zeev
Yes 007 is fixed now but private_007b.phpt still fails because the wrong
method is being called.
The problem i see is the following: You inherit private methods to be
slightly faster in zend_compile.
In zend_execute you fetch the fbc from the object. Doing this you fetch the
wrong method.
All above assumes we were linking privates statically as we do in case of
static methods. Or do we
link all static mehtods statically and all dynamic methods dynamic? If so
the test has to be corrected.
Maybe the latter is better since it would be hard to explain that privates
are linked statically while
public and protected are linked dynamically. I wrote the test based on my
first patches and did not
allow to change the visibility. In that case it makes no sense to
dynamically link privates. Now
increasing visibility is allowed all should be linked dynamically,
shouldn't they?
Here is the test 007b:
===ptivate_007b.php
?php
class Bar {
public function pub() {
$this-priv();
}
private function priv() {
echo Bar::priv()\n;
}
}
class Foo extends Bar {
public function priv() {
echo Foo::priv()\n;
}
}
$obj = new Foo();
$obj-pub();
$obj-priv();
echo Done\n;
?
===EOF
===ptivate_007b.log
EXPECTED OUTPUT
Bar::priv()
Foo::priv()
Done
ACTUAL OUTPUT
Foo::priv()
Foo::priv()
Done
FAILED
===EOF
marcus
Re: [PHP-DEV] Macros for global startup/shutdown functions
On Tue, 10 Dec 2002, Thomas Wentzel wrote: Does this also mean, that I can't hardcode this functionality? (ie. adding to functions to the zend_module_entry struct) As it is I actually have a use for this, and have succesfully compiled my extension with references to such hardcoded functions - allthough they don't seem to get called at this point! They are indeed not called anymore, as we just removed the functionality, but it still compiles of course. However, where did you see this documented? It's neither in phpdoc or the ZendAPI docs. Derick Derick Rethans wrote: On Tue, 10 Dec 2002, Thomas Wentzel wrote: Hi! How come there are no macros for global startup and shutdown functions? The Zend API documentation refers to such terms and even instructs that one should use STANDARD_MODULE_PROPERTIES_EX instead of STANDARD_MODULE_PROPERTIES if global functions are to be used. I have even found references to ZEND_GINIT/GSHUTDOWN on the web, but... Admittedly, I haven't checked newer versions, but as I am using 4.1.2 and these terms have been used dating back to the 4.0 release this doesn't seem to be the issue. GINIT and GSHUTDOWN where removed about a year ago because they weren't really used anyway, and had no real purpose anyway for them. *sigh* it just shows that the docs are quite outdated; I'll have a look at it now. 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 -- - 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] Macros for global startup/shutdown functions
Derick Rethans wrote: They are indeed not called anymore, as we just removed the functionality, but it still compiles of course. However, where did you see this documented? It's neither in phpdoc or the ZendAPI docs. Derick Well.. a quick glimpse revealed the following two pages (don't know if there are more) http://www.zend.com/apidoc/zend.structure.module-block.php The cell explaining Remaining structure elements clearly insinuates that the GINIT/GSHUTDOWN be present (not to mention fig. 8-4 :) http://www.zend.com/apidoc/zend.startup-and-shutdown.php The first line of the second paragraph also speaks of these... Would it be too much a pain if I were to modify the code to call my global functions? Do you recall in which version this functionality was removed? /Thomas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Macros for global startup/shutdown functions
On Tue, 10 Dec 2002, Thomas Wentzel wrote: Derick Rethans wrote: They are indeed not called anymore, as we just removed the functionality, but it still compiles of course. However, where did you see this documented? It's neither in phpdoc or the ZendAPI docs. Derick Well.. a quick glimpse revealed the following two pages (don't know if there are more) http://www.zend.com/apidoc/zend.structure.module-block.php The cell explaining Remaining structure elements clearly insinuates that the GINIT/GSHUTDOWN be present (not to mention fig. 8-4 :) http://www.zend.com/apidoc/zend.startup-and-shutdown.php The first line of the second paragraph also speaks of these... Would it be too much a pain if I were to modify the code to call my global functions? Just move them to module startup/shutdown; it doesn't make any difference anyway. Do you recall in which version this functionality was removed? no, I really dont recall, try lxr.php.net :) 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
[PHP-DEV] [Fwd: Bug #20858 [Dup-Bgs]: dba_open create always a lock file]
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. PHP Bug Database wrote: ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=20858edit=2 ID: 20858 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Bogus Bug Type: DBM/DBA related Operating System: Linux 2.2.16 PHP Version: 4.3.0RC2 Assigned To: helly New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Previous Comments: [2002-12-09 12:08:10] [EMAIL PROTECTED] I added '-' modifier for that now. And marked this one duplicate. See bug 20828 for more. [2002-12-07 09:11:03] [EMAIL PROTECTED] This was intended and the documentation is bad on this. 'l' and 'd' are only to force one of the two. Maybe i'll add a new modifier to skip locking... [2002-12-06 08:57:30] [EMAIL PROTECTED] Already reported in comment on #20828. I make a separate bug report since it's another bug. Opening a db with ? dba_open(E.db, r, db2); ? create a lock file (note that the l attribute is not used) This script will fail on a ro directory! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Macros for global startup/shutdown functions
Derick Rethans wrote: Just move them to module startup/shutdown; it doesn't make any difference anyway. That's what I have been doing so far You are probably right, guess it's a matter of rethinking my code again ;) Do you recall in which version this functionality was removed? no, I really dont recall, try lxr.php.net :) Yeah, of course! Sorry forgot about that one! :) Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - Thanks for your assitance. I would have spent a lot of time digging in to this if it weren't for you! Thomas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [Fwd: Bug #20858 [Dup-Bgs]: dba_open create always a lock file]
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. 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. 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. marcus PHP Bug Database wrote: ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=20858edit=2 ID: 20858 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Duplicate +Status: Bogus Bug Type: DBM/DBA related Operating System: Linux 2.2.16 PHP Version: 4.3.0RC2 Assigned To: helly New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Previous Comments: [2002-12-09 12:08:10] [EMAIL PROTECTED] I added '-' modifier for that now. And marked this one duplicate. See bug 20828 for more. [2002-12-07 09:11:03] [EMAIL PROTECTED] This was intended and the documentation is bad on this. 'l' and 'd' are only to force one of the two. Maybe i'll add a new modifier to skip locking... [2002-12-06 08:57:30] [EMAIL PROTECTED] Already reported in comment on #20828. I make a separate bug report since it's another bug. Opening a db with ? dba_open(E.db, r, db2); ? create a lock file (note that the l attribute is not used) This script will fail on a ro directory! -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Latest ZE2 changes
This does appear to be a problem, we'll need to think about it.
At 13:32 10/12/2002, Marcus Börger wrote:
At 10:02 10.12.2002, Zeev Suraski wrote:
At 15:44 08/12/2002, Marcus Börger wrote:
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).
How do you arrive in that conclusion? The algorithm was designed to
fully support it. Running private_007 also appears to be working for me
(there was a buglet in the parser with static+access level, but if you
remove the statics and/or update to the latest CVS, you can see that it's
working fine...)
Zeev
Yes 007 is fixed now but private_007b.phpt still fails because the wrong
method is being called.
The problem i see is the following: You inherit private methods to be
slightly faster in zend_compile.
In zend_execute you fetch the fbc from the object. Doing this you fetch
the wrong method.
All above assumes we were linking privates statically as we do in case of
static methods. Or do we
link all static mehtods statically and all dynamic methods dynamic? If so
the test has to be corrected.
Maybe the latter is better since it would be hard to explain that privates
are linked statically while
public and protected are linked dynamically. I wrote the test based on my
first patches and did not
allow to change the visibility. In that case it makes no sense to
dynamically link privates. Now
increasing visibility is allowed all should be linked dynamically,
shouldn't they?
Here is the test 007b:
===ptivate_007b.php
?php
class Bar {
public function pub() {
$this-priv();
}
private function priv() {
echo Bar::priv()\n;
}
}
class Foo extends Bar {
public function priv() {
echo Foo::priv()\n;
}
}
$obj = new Foo();
$obj-pub();
$obj-priv();
echo Done\n;
?
===EOF
===ptivate_007b.log
EXPECTED OUTPUT
Bar::priv()
Foo::priv()
Done
ACTUAL OUTPUT
Foo::priv()
Foo::priv()
Done
FAILED
===EOF
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
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 Maybe you can test the presence of CGI environment variables? I'm amateur... Christoph -- 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]
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. -- 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
Markus Fischer wrote: More non-developers are getting aware of the upcommong 4.3 release and start to absorb the NEWS and question it. I do not count Zeev as a non-developer :) -- 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 Tue, Dec 10, 2002 at 03:38:09PM +0100, Sebastian Bergmann wrote : Markus Fischer wrote: More non-developers are getting aware of the upcommong 4.3 release and start to absorb the NEWS and question it. I do not count Zeev as a non-developer :) I was talking about Mr. Grottolo who started this thread. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] how many records
After I run a query lik this, $db-query($sql); what is the quickest way to find out how many records result? Without having to loop through them all? Thank you , Diana -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] MINIT RINIT et al
Ok! My last postings were about the lack of global init/shutdown functions. Derick was kind enough to tell me, that these were deprecated and that I should use MINIT for my initalisations. Well.. this was what I had been doing until it just didn't seem adequate for my needs. I decided to give it another go but my attempts have given rise to some issues I need explained. As I'm compiling my modules into php I understand and have verified that MINIT is called whenever I start apache. (and MSHUTDOWN when I stop apache) RINIT/RSHUTDOWN continue to baffle me though. Why do RINIT get called when I start apache? (after MINIT). Shouldn't that happen only if I had compiled my extension as a dynamic extension, that required dl'ing? In fact RINIT/RSHUTDOWN only gets called once (when starting/stopping apache). As I read the documentation RINIT should be called whenever I direct my browser to a page which requires php, and RSHUTDOWN when that request has ended. Am I getting this all backwards? TIA Thomas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: mishaleg
Developing the PHP runtime. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: jellybob
Maintaining the Auth_PrefMan package in PEAR. -- 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
out on a limb Would it be a tragedy to name both the CLI and CGI versions php on UNIX and php.exe on Windows? Yes, it's a support nightmare. limb broken=yes / I defer to you. Leon -- 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
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. But it's fun to argue over the same things every six months! :P Leon -- 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/bcmath bcmath.c php_bcmath.h
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?
Andi
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
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c php_bcmath.h
At 21:47 10.12.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?
Andi
Perhaps we make all old function names an alias and have all new ones with
an underscrore.
If we do so for all modules we can add a configure setting to disallow
deprecated old function
names.
If we don't do this i agree to Andi and would favor bcpowmod().
marcus
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
--
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? I think it's fine to keep it as bcpowmod(), since we'll probably rename functions in the future anyway. -Andrei http://www.gravitonic.com/ * I don't have a solution but I admire the problem. * -- 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
Esp. when some of us would love to see PHP5 start taking form :) John -Original Message- From: Leon Atkinson [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 2:55 PM To: Edin Kadribasic Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] php.exe - php-cgi.exe 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. But it's fun to argue over the same things every six months! :P Leon -- 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] PHP_ADD_LIBRARY
I got strange results when configuring php with cpdf, dba, gd and jpeg/tiff. The problem was that cpdf requires jpeg and tiff libraries but did not check for them. Only in gd there were tests and missleeding hints: GD messages suggest that tiff/jpeg are only used there. As of current implementation both libs were added by calls to function PHP_ADD_LIBRARY in ext/cpdf/config.m4. Then in dba config tests failed because those two libs were missing. The above is fixed now in HEAD but there are other places where libraries are added with PHP_ADD_LIBRARY and without further checks. Also some libraries are linked more than once. 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? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: meebey
new PEAR package called Net_SmartIRC see http://news.php.net/group.php?group=php.pear.dev for more information -- 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 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 -- 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
I'm hearing two options here: 1) Name the new function bcpowmod() to keep it similiar to existing functions, we'll worry about renaming the functions in this module later... 2) Name the new function bc_powmod(), rename the existing functions now, and create aliases. Possibly introduce an ini option to control whether or not deprecated functions are enabled or not. #2 Sounds like The Right Way to do it, but also sounds like something which needs a strong consensus before implementing and should perhaps be put off till the next revision (4.4 or 5.0 -- whichever it winds up being) -Pollita -- 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 23:11 09/12/2002, Frank M. Kromann wrote: 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. These are good points. I think that's a bit like inventing problems and then trying to fix them. Let's keep it down to things we can determine relatively easily: - Nothing bad will happen if we name the new CLI with whatever kind of name - php-cli, phpsh, whatever - There WILL be some level of confusion if we rename the CGI binary If we use this KISS approach, why the heck are we even considering this rename? I happen to agree with Zeev here - I won't argue the potential of using PHP for GTK/command line scripting, however, currently that is not PHP's target audience, and in my opinion we should focus on our target audience first. Should PHP progress and become more popular outside the webspace (and cgi becomes less popular as well :), then it would make sense to rechange the name (perhaps for PHPv5), but at this point changing it to php-cgi just seems like solving a problem by creating a bigger one. -Sterling Zeev -- 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] 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 Index: php_cli.c === RCS file: /repository/php4/sapi/cli/php_cli.c,v retrieving revision 1.51.2.1 diff -u -r1.51.2.1 php_cli.c --- php_cli.c 14 Nov 2002 21:09:42 - 1.51.2.1 +++ php_cli.c 11 Dec 2002 03:43:01 - @@ -377,22 +377,19 @@ php_stream_to_zval(s_err, zerr); ic.value = *zin; - zval_copy_ctor(ic.value); - ic.flags = CONST_CS | CONST_PERSISTENT; + ic.flags = CONST_CS; ic.name = zend_strndup(STDIN, 6); ic.name_len = 6; zend_register_constant(ic TSRMLS_CC); oc.value = *zout; - zval_copy_ctor(oc.value); - oc.flags = CONST_CS | CONST_PERSISTENT; + oc.flags = CONST_CS; oc.name = zend_strndup(STDOUT, 7); oc.name_len = 7; zend_register_constant(oc TSRMLS_CC); ec.value = *zerr; - zval_copy_ctor(ec.value); - ec.flags = CONST_CS | CONST_PERSISTENT; + ec.flags = CONST_CS; ec.name = zend_strndup(STDERR, 7); ec.name_len = 7; zend_register_constant(ec TSRMLS_CC); -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] $scalar{index} syntax
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
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c php_bcmath.h
At 05:10 PM 12/10/2002 -0800, Sara Golemon wrote: I'm hearing two options here: 1) Name the new function bcpowmod() to keep it similiar to existing functions, we'll worry about renaming the functions in this module later... 2) Name the new function bc_powmod(), rename the existing functions now, and create aliases. Possibly introduce an ini option to control whether or not deprecated functions are enabled or not. #2 Sounds like The Right Way to do it, but also sounds like something which needs a strong consensus before implementing and should perhaps be put off till the next revision (4.4 or 5.0 -- whichever it winds up being) I'd go for #1 now as this should be done anyway. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $scalar{index} syntax
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
[PHP-DEV] Odp: 'include' function
Finally I've managed to modify the parser. It was a good lesson. KS. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
