Re: [PHP-DEV] PHP 4.0 Bug #8795: Recieved POST-form-data is unexpectedly escaped with backslashes
From a hostile standpoint, a sendmail server allowing VRFY is considered bad, /let alone giving the hacker detailed uid/gid structure of your system. Jason - Original Message - From: "Ignacio Vazquez-Abrams" [EMAIL PROTECTED] To: "Toby Butzon" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, January 19, 2001 9:02 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8795: Recieved POST-form-data is unexpectedly escaped with backslashes On Thu, 18 Jan 2001, Toby Butzon wrote: As a side note, check this link out ;) http://[removed]?file=/etc/passwd --Toby Oh come on. Exposing this file even with shadow passwords in place is still a HUGE risk, because now your userids are exposed and your system is vulnerable to a brute-force attack. Never, EVER, do something as silly as this, especially in a public forum. -- Ignacio Vazquez-Abrams [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: shebang through suid-wrapper (execv)
Johan,
Your problem has to do with the combination of your suexec-like cgi-wrapper and the
detection algorythem implied in php. CGI mode of php detects your webserver by looking
at
various environment rules (eg. SERVER_SOFTWARE). When you a cgi is executed by
the webserver (ex. wrapper.cgi), PATH_TRANSLATED and/or SCRIPT_FILENAME is
set by the webserver to point to the script you just executed, which is wrapper.cgi.
PHP sees this
and then decides to execute wrapper.cgi. All you need to do to fix your problem is set
PATH_TRANSLATED to the name of the script you want to run.
In answer to your question about mailing me directly, I do not mind, but I ask that
you
cc the php-dev list in case I'm not around.
Here is the corrected wrapper.c:
#include stdlib.h
main(argc,argv)
int argc;
char **argv;
{
char file[] = "./test.cgi";
putenv("PATH_TRANSLATED=./test.cgi");
execv(file, argv);
}
-Jason
- Original Message -
From: "Johan Ekenberg" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 19, 2001 9:36 AM
Subject: shebang through suid-wrapper (execv)
Hi!
I saw your name in a few of the bug-reports at bugs.php.net concerning
shebang related problems. I have a problem which I'm not sure if I should
report as a bug or not:
I'm trying to use a C-wrapper for PHP just like I do for cgi scripts written
in Perl. The reason is to run the script suid user. I made a small cgi
script in C, which uses execv() to start the actual program - a Perl or PHP
script. This works perfectly when the actual program is a Perl script, but
when it's a PHP script the PHP binary tries to parse and execute the calling
program (the wrapper) instead of the called file.
The VERY STRANGE thing is that it works when I execute the wrapper at the
commandline, but when the wrapper is called by Apache as a cgi, then PHP
outputs the contents of the compiled wrapper (lots of garbage) instead of
executing the PHP script. Somewhere along the line I guess that PHP gets
"/usr/bin/php wrapper.c" instead of "/usr/bin/php wrapped-php.cgi". Forget
the suid stuff, it doesn't matter if I add or remove the suid-bit on the
wrapper binary.
I'm not sure if I'm explaining myself. Please tell me if I should take this
to someone else, or to a mailinglist (which one?).
An example here:
http://www.ekenberg.se/phpwrap/
The files:
== wrapper.c == (gcc -o wrapper.cgi wrapper.c)
main(argc,argv)
int argc;
char **argv;
{
char file[] = "/path/to/wrapped-php.cgi";
execv(file, argv);
}
// EOF
== wrapped-php.cgi ==
#!/usr/bin/php
?php
echo "this is a test\n";
?
// EOF
Best regards,
/Johan Ekenberg
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Mean
I was just looking at php4/TODO. What is the desired capability for array_mean? Is this refering to the mean of all numerical elements in the list? Is the desired functionality to count non numerical data as 0's or to completly ignore them from the alg? -Jason
Re: [PHP-DEV] Mean
Thanks, I Removed it from cvs. -Jason Andrei Zmievski wrote: On Fri, 19 Jan 2001, Jason Greene wrote: I was just looking at php4/TODO. What is the desired capability for array_mean? Is this refering to the mean of all numerical elements in the list? Is the desired functionality to count non numerical data as 0's or to completly ignore them from the alg? That can be removed from TODO. The desired functionality can be achieved by array_sum($array)/count($array). -Andrei "The only true currency in this bankrupt world is what we share with each other when we're uncool." -- Lester Bangs, from the film 'Almost Famous' -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] http://cvs.php.net/
Thats when you cp /mnt/winblows/windows/fonts/*.ttf .; mkttfdir fonts.dir; killall -HUP xfs : ) Jason - Original Message - From: "Anil Madhavapeddy" [EMAIL PROTECTED] To: "Martin Jansen" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 22, 2001 1:24 PM Subject: Re: [PHP-DEV] http://cvs.php.net/ [switching this to [EMAIL PROTECTED], its pretty offtopic for php-dev] Quoting Martin Jansen [EMAIL PROTECTED]: Hartmut told me that it's looking not that nice under Linux, so there might be some stuff to fix before putting it on cvs.php.net :) Mmm yeah, the joys of stylesheets and X11 font rendering. I guess using absolute font-sizing is a bit no-no (although it looks ok on my Debian setup). If people want to send me screenshots of how bad it looks under your particular setup, that would help. -- Anil Madhavapeddy, [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] array_add
Is array_add in TODO refering to the summation of the individual elements in an array? ex (1,2,3) +(2,3,4)=(3,5,7)? Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Fw: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed.
MaxRequestsPerChild is perfectly safe, and I always believe in setting it. Keep in mind that if you compile all modules into apache statically, it takes up far more base mem per process. If you use all DSO's, you can significantly reduce memory usage. To find out what's in use on RH7 cat /proc/pid/maps of an apache child. You can also reduce the KeepAlive timeout value to help-out. Jason - Original Message - From: "Rasmus Lerdorf" [EMAIL PROTECTED] To: "Filip Sielimowicz" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, January 29, 2001 7:51 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed. On Mon, 29 Jan 2001, Filip Sielimowicz wrote: A quick fix would be to set your MaxRequestsPerChild to a lower value. Have you ever tried to measure the time of killing and starting httpd process ? You can see that with a bare human eye. Sure. But that isn't something that happens on an actual request, so an end user isn't going to see that. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed.
What is your typical apache process size, and number of current running procs? Jason - Original Message - From: "Brian Moon" [EMAIL PROTECTED] To: "Rasmus Lerdorf" [EMAIL PROTECTED] Cc: "Filip Sielimowicz" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 29, 2001 6:23 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed. Ok, so what are the benefits of not returning memory to the system? It seems that no one who can do it wants to so there must be a good reason. Brian Moon -- Phorum Dev Team - http://phorum.org Making better forums with PHP -- - Original Message - From: "Rasmus Lerdorf" [EMAIL PROTECTED] To: "Brian Moon" [EMAIL PROTECTED] Cc: "Filip Sielimowicz" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 29, 2001 5:03 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed. Seems to me like it would be a lot easier just to add more RAM. $89 for 256M these days. RAM is cheap. -Rasmus On Mon, 29 Jan 2001, Brian Moon wrote: That is what we are doing now. We have it at 5. Any higher and we are running out. There is only 128MB of RAM in our machine. I am considering switching to CGI PHP just to eliviate this problem. Of course, that sucks. Brian Moon -- Phorum Dev Team - http://phorum.org Making better forums with PHP -- - Original Message - From: "Rasmus Lerdorf" [EMAIL PROTECTED] To: "Filip Sielimowicz" [EMAIL PROTECTED] Cc: "Brian Moon" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 29, 2001 6:56 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed. Yes, yes, I agree ! But this is the problem ! Unfortunatelly "memory hungry script" happens from time to time and there's no chance to prevent httpd processes from keeping memory (which is not used again in most cases). Maybe it is not a problem for you, but it is for us. A quick fix would be to set your MaxRequestsPerChild to a lower value. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: safe_mode redesign
Zeev,
I understand your viewpoint, but I respectfully disagree. I believe that there are
multiple levels of security, and that the OS is
just part of the picture. There always is some layer of application
security(especially for those apps that run id=0). If you are a
hosting company ( which is becoming a very large business), then you desire a way to
provide your customers with a programming
interface that does not infringe on other customers, or your systems security. Without
a safe_mode, ? $x = file("/etc/passwd"); ?
is still allowed.
While the details get tricky, and sometime complex, the overall concept is simple.
Before any risky activity is performed, check the
list of things to block. There are tons of applications out there that perform these
kind of important checks. ProFTPD is a good
example of one such application. It allows you to lock users into certain areas, use
specific uids etc.
It seems that your biggest concern is giving users a false sense of security. This
feature is something that would not be used by
the average user. The people who would mainly be using this would have an ok knowledge
of security, and if you have an ok knowledge,
then you will know to Never Trust Anything
There is always a possibility of security methods being penetrated, everyone just has
to be made aware that security is just
something that rules out the majority of breach attempts. That is why you need
multiple levels
I believe that performing something similar to a chroot in the lower level file
operations, would lock php itself into a protected
area. PHP is very modular, and has an excellent lower level API., both of which makes
this a very possible thing.
I have spent quite a bit of time customizing PHP to work well in a secure environment,
and I have seen other service providers doing
the same thing. The problem is that ppl are still going to do this whether its part of
the codebase or not. If all of this work was
combined, then it can be shared, repaired, and optimized by everyone.
A safe programming chapter could be referred to in documentation as "An experimental
security option designed for ISP and hosting
providers. This is by no means the finality of security, just a tool to help
in developing a secure environment"
Thanks,
Jason
- Original Message --
From: "Zeev Suraski" [EMAIL PROTECTED]
To: "Jason Greene" [EMAIL PROTECTED]
ACc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, February 04, 2001 6:43 AM
Subject: Re: safe_mode redesign
Jason,
The one main problem with safe_mode in general is that the idea is
problematic by definition. Security outside the OS level is prone to
errors, and a false sense of security is much worse than knowing you're
insecure.
In my opinion, safe mode should only feature features which can have an
infrastructure-level solution, and are not prone to errors. There aren't
too many of these. The current safe mode implementation is extremely prone
to errors because it tries to protect opened files, and the way its built,
it's bound to be missing checks in many places...
Zeev
At 22:53 1/2/2001, Jason Greene wrote:
Is anyone up for a discussion on the redesign of safe_mode? I would like
to start working on this sometime soon, and I have a lot of
ideas, but I know this is going to be something of a large debate.
Some of the new features I think would benefit php include:
* safe_mode_hide_env_vars - will allow extra protection on removing
environmental vars from hosted users ( I actually have a patch
for this but I have been waiting on it to discuss the redesign)
* User configurable policy - safe_mode could have configuration directives
to specify exactly what checks are desired
* Virtual Chroot - the ability to perform a chroot to a virtual host
directory structure, so that a hosted user can not access
anything outside of their directory structure.
* Shared Directories - The ability to specify a list of paths that are
shared amongst all hosted users. This would allow certain
extensions (gd, oracle, etc) the ability to access the needed datafiles
without failing a safe_mode check.
Any comments, suggestions, other ideas?
-Jason
--
Zeev Suraski [EMAIL PROTECTED]
CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: safe_mode redesign
Zeev,
I see your point. Would you accept changing safe_mode to restrictive_mode,
and refer to features as what they really are?
For example:
restrictive_uid_check = yes
restrictive_purge_environment_vars = ( )
There could be a page on php that explains all the various modes, functionality, etc...
We could then of course state that this is not intended to replace OS security.
Also, be advised that many functions don't use the APIs, but use system
calls directly.
I thought everything went through TSRM?
-Jason
- Original Message -
From: "Zeev Suraski" [EMAIL PROTECTED]
To: "Jason Greene" [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, February 06, 2001 5:36 PM
Subject: Re: safe_mode redesign
At 21:53 6/2/2001, Jason Greene wrote:
Zeev,
I understand your viewpoint, but I respectfully disagree. I believe that
there are multiple levels of security, and that the OS is
just part of the picture. There always is some layer of application
security(especially for those apps that run id=0). If you are a
hosting company ( which is becoming a very large business), then you
desire a way to provide your customers with a programming
interface that does not infringe on other customers, or your systems
security. Without a safe_mode, ? $x = file("/etc/passwd"); ?
is still allowed.
My point is that with safe_mode, $x = file("/etc/passwd") can probably
still be achieved, only perhaps not that easily. The false sense of
security that it gives you may (will) cause administrators to set their
servers up in an insecure way.
It seems that your biggest concern is giving users a false sense of
security. This feature is something that would not be used by
the average user. The people who would mainly be using this would have an
ok knowledge of security, and if you have an ok knowledge,
then you will know to Never Trust Anything
There is always a possibility of security methods being penetrated,
everyone just has to be made aware that security is just
something that rules out the majority of breach attempts. That is why you
need multiple levels
I believe that performing something similar to a chroot in the lower level
file operations, would lock php itself into a protected
area. PHP is very modular, and has an excellent lower level API., both of
which makes this a very possible thing.
Well, I respectfully disagree :) One thing we haven't done, is telling
people one clear statement - 'Safe mode is NOT secure'. It's a functional
feature, not a security feature. It hasn't been audited, and God knows how
many bugs and loopholes lurk in the dark (my guess - many).
I don't mind seeing an impressive safe mode being implemented, as long as
it's presented as a functional feature, with the appropriate disclaimers
telling people that this does *NOT* replace security measure that they
would otherwise use.
Also, be advised that many functions don't use the APIs, but use system
calls directly.
Zeev
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
Some of my thoughts: 1. if you change the return value of in_array to return the key, you can get a false error in your if statement, imagine if in_array found the element in key 0? : ) 2. I would say that returning a key is a bit more useful then an option that does not reset the internal pointer or not, though I can see a use of it I do agree that having too many parameters is a bad thing, but if this is a concern what about making another function? There seems to be a large desire to see the key of in_array (see the haystack comment in docs) -Jason - Original Message - From: "Andrei Zmievski" [EMAIL PROTECTED] To: "Andr Langhorst" [EMAIL PROTECTED] Cc: "PHP Development" [EMAIL PROTECTED] Sent: Monday, February 19, 2001 11:36 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found On Mon, 19 Feb 2001, Andr Langhorst wrote: How about using array_keys($array, $value) to find the key? obviously it is cheaper to let in_array return it and it is more php 4 stylish, we have booleans, why not use them? if ($key=in_array()) do_someting_with_key($key); So, you suggest putting in 4th parameter? Then someone on php-general suggested a few months ago to put in another parameter that controls whether in_array() moves internal pointer or not.. Too many parameters. -Andrei * Power corrupts. Atomic power corrupts atomically. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
We can change in_array() to return the the key if it's found, and false if it's not, but imagine all the scripts it would break.. about 1/4th of mine : ) Well I think the basic problem is that people are using in_array against its intention. It is a Boolean function, and that really shouldn't be changed. We could create another function that is more designed for searching? perhaps array_find? I wouldn't mind spending time on this if agreed upon. -Jason - Original Message - From: "Andrei Zmievski" [EMAIL PROTECTED] To: "Jason Greene" [EMAIL PROTECTED] Cc: "Andr Langhorst" [EMAIL PROTECTED]; "PHP Development" [EMAIL PROTECTED] Sent: Monday, February 19, 2001 11:50 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found On Mon, 19 Feb 2001, Jason Greene wrote: Some of my thoughts: 1. if you change the return value of in_array to return the key, you can get a false error in your if statement, imagine if in_array found the element in key 0? : ) 2. I would say that returning a key is a bit more useful then an option that does not reset the internal pointer or not, though I can see a use of it I do agree that having too many parameters is a bad thing, but if this is a concern what about making another function? There seems to be a large desire to see the key of in_array (see the haystack comment in docs) -Andrei * The future is not what it used to be. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found
I agree, That way we don't duplicate code, and we don't have different behavior.. Ill work on this sometime today -Jason - Original Message - From: "Andrei Zmievski" [EMAIL PROTECTED] To: "Jason Greene" [EMAIL PROTECTED] Cc: "Andr Langhorst" [EMAIL PROTECTED]; "PHP Development" [EMAIL PROTECTED] Sent: Monday, February 19, 2001 12:02 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found On Mon, 19 Feb 2001, Jason Greene wrote: We can change in_array() to return the the key if it's found, and false if it's not, but imagine all the scripts it would break.. about 1/4th of mine : ) Well I think the basic problem is that people are using in_array against its intention. It is a Boolean function, and that really shouldn't be changed. We could create another function that is more designed for searching? perhaps array_find? I wouldn't mind spending time on this if agreed upon. Could be done. The way I'd do it is have one php_in_array() C function that gets parameters passed through from in_array() and array_find() as well as a flag indicating whether to just return true/false or the actual key. -Andrei "The human brain is a wonderful thing. It starts working the moment you are born, and never stops until you stand up to speak in public. " -- Sir George Jessel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] CVS Account Request
We still are getting these? - Original Message - From: "CVS Account Request" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, February 27, 2001 8:22 AM Subject: [PHP-DEV] CVS Account Request Full name: Ivan Ivanov Email: [EMAIL PROTECTED] ID: johnt Purpose: web programming -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] OO overloading
Andi, I just started working on an InterMail extension for php. I am not sure if I can release it into the tree (openwave has some licensing issues), but If I can I will add it in the future. Anyways, I am in the initial phases of this project, and I was considering using the Zend OO overloading that is used by the java and COM extensions. The Intermail C APIwantsto be used in an OO way. Are there any issues that you know of that I might run into using this method? Another question I had for you is about PHP's OO support. I have seen alot of various issues with it , and I have seen threads go on about how to solve things that appear simple to the user, though very complex internally. Is PHP's OO were we all want it to be? Are we looking at a possible redesign in much later revisions? Thanks, -Jason
Re: [PHP-DEV] Static vars in methods
this sounds like a bad thing, especially if people start depending on that
behavior
-Jason
- Original Message -
From: "Andrei Zmievski" [EMAIL PROTECTED]
To: "PHP Developers" [EMAIL PROTECTED]
Cc: "Zeev Suraski" [EMAIL PROTECTED]; "Andi Gutmans" [EMAIL PROTECTED]
Sent: Friday, March 09, 2001 10:50 AM
Subject: [PHP-DEV] Static vars in methods
Just ran into something (well, actually searching for it) and wanted to
know what everyone's thoughts on this were and whether it should stay
that way.
?php
class Foo {
function get()
{
static $i = 0;
return ++$i;
}
}
$c1 = new Foo;
var_dump($c1-get());
var_dump($c1-get());
$c2 = new Foo;
var_dump($c2-get());
?
Outputs:
int(1)
int(2)
int(3)
Basically, the static variable keeps its value even between different
class instances. In my case, it actually helps me with something, but on
the other hand, it doesn't seem that it should be this way..
-Andrei
* I don't have a solution but I admire the problem. *
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] zend_llist_destroy on overloaded element list casuses SEG
I am writing an OO overloaded module, and I can not figure out why this is occuring, but after my function call handler is called, I get a segmentation fault in zend_llist_destroy on REMOVE_POINTER_FROM_LIST(p) within efree. Does anyone know off the top of their head what I could possibly be doing to cause this? Thanks, -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] zend_llist_destroy on overloaded element list casuses SEG
Never mind this, I somehow was overwriting part of my stack frame, specifically where my overloaded element list was. Thanks, -Jason - Original Message - From: "Jason Greene" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 09, 2001 12:41 PM Subject: [PHP-DEV] zend_llist_destroy on overloaded element list casuses SEG I am writing an OO overloaded module, and I can not figure out why this is occuring, but after my function call handler is called, I get a segmentation fault in zend_llist_destroy on REMOVE_POINTER_FROM_LIST(p) within efree. Does anyone know off the top of their head what I could possibly be doing to cause this? Thanks, -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend_API.c zend_API.h
Simple, allocate an arbitrary large number, like a gig, give there OS's paging routines a test : ) That is a true point, I was thinking that in most cases you could accurately predict the size. g_strdup_printf - that sounds like a fun function, why don't most libraries have this feature : ) -Jason - Original Message - From: "Andrei Zmievski" [EMAIL PROTECTED] To: "Jason Greene" [EMAIL PROTECTED] Cc: "Zeev Suraski" [EMAIL PROTECTED]; "php-dev mailinglist" [EMAIL PROTECTED] Sent: Monday, March 12, 2001 10:15 AM Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend_API.c zend_API.h On Mon, 12 Mar 2001, Jason Greene wrote: strlcpy, and strlcat are in the win32 build (main/strlcat.c main/strlcpy.c) why dont you malloc a buffer that would fit the sprintf data, and then strlcpy the size restriction? Hmm, and how would you know how big the sprintf buffer would need to be for an arbitrary format and arguments? :) In my case it's much simpler, so yes, I could do that, but otherwise.. That's why Glib has g_strdup_printf() function.. quite nice. -Andrei * If it ain't broken, it doesn't have enough features yet. * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] whats the standard for OO builtin_functions?
Can anyone tell me what the standard is for the builtin_functions function_entry in OO,
should i use a or b
A)
static function_entry class_function_entry = {
PHP_FALIAS(member_fnction, php_member_function, NULL)
{NULL, NULL,NULL}
};
B)
static function_entry class_function_entry = {
{"member_function",PHP_FN(php_member_function), NULL}
{NULL,NULL, NULL}
};
Thanks,
-Jason
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/fbsql .cvsignore Makefile.in config.m4 fbsql.dsp php_fbsql.c php_fbsql.h
Frank, Your config.m4 breaks the build. -Jason - Original Message - From: "Frank M. Kromann" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 13, 2001 2:58 PM Subject: [PHP-CVS] cvs: php4 /ext/fbsql .cvsignore Makefile.in config.m4 fbsql.dsp php_fbsql.c php_fbsql.h fmk Tue Mar 13 12:58:48 2001 EDT Added files: /php4/ext/fbsql .cvsignore config.m4 fbsql.dsp Makefile.in php_fbsql.c php_fbsql.h Log: Initial check-in of FrontBase extension -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: =?iso-8859-1?Q?Re: [PHP-CVS] cvs: php4 /ext/fbsql .cvsignore Makefile.in config.m4 fbsql.d=
The problem was not with the module itself, but with your m4 file... you were enabling your extension by default, as well as running config tests outside of the $PHP_FBSQL test section Jani and I modified the your file to allow ./buildconf to work correctly -Jason - Original Message - From: [EMAIL PROTECTED] Sent: Tuesday, March 13, 2001 4:24 PM Subject: =?iso-8859-1?Q?Re: [PHP-CVS] cvs: php4 /ext/fbsql .cvsignore Makefile.in config.m4 fbsql.d= sp php_fbsql.c php_fbsql.h?= To: Jason Greene [EMAIL PROTECTED] From: "Frank M. Kromann" [EMAIL PROTECTED] X-Mailer: Swwwing 2000 MIME-Version: 1.0 Reply-To: "Frank M. Kromann" [EMAIL PROTECTED] Date: Tue, 13 Mar 2001 14:24:20 -0800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Jason, As my cvs message said this is the initial checkin. The code has ben tested on Windows 2000, Mac OS X and Sun solaris 5.8. I Dont have any problems with the code on any of these platforms. What platform are you building on ? - Frank P.S. I'll change the comments as soon as possible. Frank, Your config.m4 breaks the build. -Jason - Original Message - From: "Frank M. Kromann" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 13, 2001 2:58 PM Subject: [PHP-CVS] cvs: php4 /ext/fbsql .cvsignore Makefile.in config.m4 fbsql.dsp php_fbsql.c php_fbsql.h fmk Tue Mar 13 12:58:48 2001 EDT Added files: /php4/ext/fbsql .cvsignore config.m4 fbsql.dsp Makefile.in php_fbsql.c php_fbsql.h Log: Initial check-in of FrontBase extension -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: RE: [PHP-DEV] 4.0.5RC1
Andi + Zeev, I wouldn't consider bug number 8828 a show-stopper, unless you want to implement a work-around for OS X. If you read my comments on 8828 you will see that PHP's mktime + documentation is clearly following the standard, its OS X that isn't -Jason - Original Message - From: "Andi Gutmans" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 11:17 AM Subject: Fwd: RE: [PHP-DEV] 4.0.5RC1 Any idea what the problem could be? I doubt Mac OS X uses \r\n. Andi From: Lon Baker [EMAIL PROTECTED] To: [EMAIL PROTECTED], "Zeev Suraski" [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] Subject: RE: [PHP-DEV] 4.0.5RC1 The source compiles and installs as a DSO under: Mac OS X 10.0 RC1 Apache 1.3.19 MySQL 3.23.34a Config line used: ./configure --with-apxs=/usr/sbin/apxs --enable-track-vars --with-mysql=/usr/local/mysql --with-zlib With the following issues: Requires corrected lines in internal_functions.c @ line 32 as noted in bug report #9716 -After this edit the compile proceeds as normal and runs fine. Outstanding bugs that still affect 4.0.5 RC1: #8828 mktime still does not produce correct information. - No known work-around for this issue. A show stopper in my opinion. Lon Baker -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #8828 Updated: mktime using mday=0
Hi Sascha, Look at 7.23.2.6 Normalization of broken-down times -Jason - Original Message - From: "Sascha Schumann" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 12:49 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8828 Updated: mktime using mday=0 This actually is part of the Ansi C standard. Solaris 8 manpage --- The original values of the components may be either greater than or less than the specified range. For example, a tm_hour of -1 means 1 hour before midnight, tm_mday of 0 means the day preceding the current month, and tm_mon of -2 means 2 months before January of tm_year This seems to be a Solaris extension. It does not contradict C99, but I would not consider it portable. Neither section 7.23.1, "Components of time" nor 7.23.2.3, "The mktime function" say anything with regard to values which exceed the normal ranges as specified in 7.23.1. - Sascha Experience IRCG http://schumann.cx/ http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #8828 Updated: mktime using mday=0
I think i was looking at a draft, is there anything in the your copy oflC99 that resembles?: 7.23.2.6 Normalization of broken-down times [#1] A broken-down time is normalized by the mkxtime function in the following manner. A broken-down time is normalized by the mktime function in the same manner, but as if the struct tm structure had been replaced by a struct tmx structure containing the same values except: tm_versionis 1 tm_zone is _LOCALTIME 7.23.2.4 Library 7.23.2.6 WG14/N843August 3, 1998 389 tm_leapsecs is _NO_LEAP_SECONDS tm_isdst is -1, 0, or an implementation-defined positive value according to whether the original member is less than, equal to, or greater than zero [#2] If any of the following members is outside the indicated range (where L is LONG_MAX/8), the behavior is undefined: tm_year [-L/366, +L/366] tm_mon[-L/31, +L/31] tm_mday [-L, +L] tm_hour [-L/3600, +L/3600] tm_min[-L/60, +L/60] tm_sec[-L, +L] tm_leapsecs [-L, +L] or _NO_LEAP_SECONDS tm_zone [-L/60, +L/60] tm_isdst [-L/60, +L/60] or _LOCALTIME The tm_version member shall be 1. [#3] Values S and D shall be determined as follows: 7.23.2.6 Library 7.23.2. #define QUOT(a,b) ((a)0 ? (a)/(b) : -(((b)-(a)-1)/(b))) #define REM(a,b) ((a)-(b)*QUOT(a,b)) - Original Message - From: "Sascha Schumann" [EMAIL PROTECTED] To: "Jason Greene" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 1:00 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8828 Updated: mktime using mday=0 On Wed, 14 Mar 2001, Jason Greene wrote: Hi Sascha, Look at 7.23.2.6 Normalization of broken-down times Which version of the "Ansi C standard" are you referring to? C99 (ANSI/IEC/ISO 9899:1999) does not contain such a section nor does it contain the term normalization. The Single Unix Spec II which predates C99 also does not say anything with regard to ``normalization''. - Sascha Experience IRCG http://schumann.cx/ http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #8828 Updated: mktime using mday=0
Sascha + Everyone, Thanks for pointing that out ( I should have known better to argue standards with Sascha: ) I reviewed the official C99 ANSI/ISO/IEC 9899-1999 and it does make no mention as to the use of mday=0 or the normalization of tm structs as specified in the proposal that I was citing. This is not potable, though I have seen many Unix's act this way. So should we a) just change our docs to say something to the effect of "Some UNIX's support mday=0 (Possible list of known os's) , but this is not the defacto standard and you should refer to your system docs". b) remove all references from it or c) detect when it doesn't work and emulate the functionality. I vote for (A), seeing as there is no set standard for this, and there is no guarantee that the mday=0 functionality will stay. What do you guys think? -Jason - - Original Message - From: "Sascha Schumann" [EMAIL PROTECTED] To: "Jason Greene" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, March 14, 2001 1:39 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8828 Updated: mktime using mday=0 Hi, Either way though, you are saying that this has not been excepted into the final C99? Correct. A bit of googling brought up this page where Paul Eggert documents why the proposal is broken. http://www.cl.cam.ac.uk/~mgk25/c-time/comment-eggert.html So should we depend on this being a portable standard yet? I have used the mday=0 on Solaris, and Linux and have seen it in the IRIX manpages It is not portable as the Mac OS X case shows. It would be hard to convince a vendor to implement a certain feature, if even the proposal for that feature was rejected by the responsible language committee. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] feature request
Perhaps isset should be branched to form a separate function to handle multi args, we could offer things in the new function such as an optional argument that passes back an array of results. -Jason - Original Message - From: "Phil Driscoll" [EMAIL PROTECTED] To: "Chris Newbill" [EMAIL PROTECTED]; "Zeev Suraski" [EMAIL PROTECTED]; "Andi Gutmans" [EMAIL PROTECTED] Cc: "PHP DEV" [EMAIL PROTECTED] Sent: Monday, March 19, 2001 1:58 PM Subject: Re: [PHP-DEV] feature request My earlier post to the list doesn't seem to have arrived yet, so here it is again. You'll note from the posting that I'm not keen on the patch staying in. There are considerable efforts being made by several of us on the QA team trying to make the language more orthogonal, and this kind of ad hoc addition really doesn't help. That is the only thing that I see of any real use as well. I was just humoring Andi and his idea that we would soon be requesting that feature of knowing which one failed the test. I was really voting no for the original feature - just returning true or false - unless it can be shown (and implemented) that iswhatever(multiple args) will work sensibly across the board, and that implementing iswhatever(multiple args) does not waste the function namespace for a new feature - e.g. loads of php functions take optional extra arguments to modify their behaviour, but once iswhatever gained the multi argument functionality described, it would be impossible to extend the functionality in this way. Cheers, and apologies for such a long sentence -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] feature request
After thinking about it more, it seems that in every scenario I could think of where you wanted an array of results, you should not be using independent vars in the first place. It would seem much more reasonable to use an array of combined values, and then parse those accordingly. I don't have any objection with the isset function taking multi args. -Jason --- Original Message - From: "Andi Gutmans" [EMAIL PROTECTED] To: "Jason Greene" [EMAIL PROTECTED]; "Phil Driscoll" [EMAIL PROTECTED]; "Chris Newbill" [EMAIL PROTECTED]; "Zeev Suraski" [EMAIL PROTECTED] Cc: "PHP DEV" [EMAIL PROTECTED] Sent: Monday, March 19, 2001 2:11 PM Subject: Re: [PHP-DEV] feature request Ugh, that's exactly what I didn't want to get into. If you want an array of results you're better of doing a few if() statements. It's faster and writes much nicer code. Andi At 02:08 PM 3/19/2001 -0600, Jason Greene wrote: Perhaps isset should be branched to form a separate function to handle multi args, we could offer things in the new function such as an optional argument that passes back an array of results. -Jason - Original Message - From: "Phil Driscoll" [EMAIL PROTECTED] To: "Chris Newbill" [EMAIL PROTECTED]; "Zeev Suraski" [EMAIL PROTECTED]; "Andi Gutmans" [EMAIL PROTECTED] Cc: "PHP DEV" [EMAIL PROTECTED] Sent: Monday, March 19, 2001 1:58 PM Subject: Re: [PHP-DEV] feature request My earlier post to the list doesn't seem to have arrived yet, so here it is again. You'll note from the posting that I'm not keen on the patch staying in. There are considerable efforts being made by several of us on the QA team trying to make the language more orthogonal, and this kind of ad hoc addition really doesn't help. That is the only thing that I see of any real use as well. I was just humoring Andi and his idea that we would soon be requesting that feature of knowing which one failed the test. I was really voting no for the original feature - just returning true or false - unless it can be shown (and implemented) that iswhatever(multiple args) will work sensibly across the board, and that implementing iswhatever(multiple args) does not waste the function namespace for a new feature - e.g. loads of php functions take optional extra arguments to modify their behaviour, but once iswhatever gained the multi argument functionality described, it would be impossible to extend the functionality in this way. Cheers, and apologies for such a long sentence -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
Though I am still considered new to this group, I thought I would put in my two cents. Are we considering fastcgi module stable? We currently release EXPERIMENTAL modules as part of the distribution. If fastcgi is considered EXPERIMENTAL, then I don't see why the module itself could not be included in the RC branch. The only piece that really has to be checked is config.m4, and in this scenario there doesn't appear to be problems(efficient or not). As long as the withval test is valid, and the module is not enabled by default it really shouldn't affect php as a whole. I believe that this is a fine exception to the rule. However, if fastcgi is being labled stable, then, IMHO, I believe it should wait for thorough testing, and the next freeze. I think that Sascha, and Jani have concerns with this being the first domino in a series of continually growing exceptions to the release process. An RP ruleset is one of those things that is often considered "Holy",and shouldn't have reoccuring exceptions. Zeev has expressed valid points about the functionality being important and shouldn't wait. Which, if there is big need for it, why can't there be a compromise? Perhaps everyone should consider altering the RP ruleset, to include an exception about adding new modules. If the exception policy was in place here are some questions of thought: What would be necessary to make it safe to php in a whole? What should the requirements be to allow this to happen ( ex. a lot of user demand, replaces something considered unstable) ? Should this require any re-testing? Should this require x amount of RCs to follow and how many? Should there be a vote on whether or not to allow the module in? Is this module something that should first be released as an add-on? I honestly agree with both positions on this one, and I think good can come from both of them : ) -Jason - Original Message - From: "Zeev Suraski" [EMAIL PROTECTED] To: "Sascha Schumann" [EMAIL PROTECTED] Cc: "PHP Developers Mailing List" [EMAIL PROTECTED]; "PHP Quality Assurance Team Mailing List" [EMAIL PROTECTED] Sent: Wednesday, March 21, 2001 1:33 PM Subject: Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi But I referred to 4.0.3pl1 :) At 21:23 21/3/2001, Sascha Schumann wrote: The Apache module issue was a security problem. A fairly major one, too. Yes, that is why I mentioned 4.0.4pl1 as an exception in an earlier email. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] non-thread-safe yet pthreads-friendly build of PHP?
I have ran into this issue many times, with the sudden system call switch between a threaded and non-threaded mode. In one scenario I had a problem where a 3rd party module (chilisoft) was linked against an so that was linked against libpthread. I had an issue where signals where not being utilized correctly (SIGALRM would no longer work after one try) which would break keep-alive in apache. My first fix was a patch to the source to reset non-blocking on SIGALRM with every request. Later I discovered just compiling the webserver with -lthread and -lpthread solved all problems. I am currently developing an Intermail module, which uses threads as well, and have had no problems. (the same applies to the php/java module.) I definitely think this is something that is not as well known as it should be. -Jason - Original Message - From: "Zeev Suraski" [EMAIL PROTECTED] To: "Rasmus Lerdorf" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, March 27, 2001 4:32 PM Subject: Re: [PHP-DEV] non-thread-safe yet pthreads-friendly build of PHP? Ok, thanks! Zeev At 00:29 28/3/2001, Rasmus Lerdorf wrote: Is there any way to build PHP with pthreads, with ZTS disabled? The reason I'm asking is that there are some thread-safe 3rd party libraries which are linked against pthreads, and apparently, if PHP isn't built with pthreads - it crashes. Any experience with it? If you link Apache with pthreads that should suffice. Just add -lpthreads to the Apache LIBS line. -Rasmus -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
IMHO, this sounds like its best for everyone, *especially* the end users of midgard and php. -Jason - Original Message - From: "James Moore" [EMAIL PROTECTED] To: "[EMAIL PROTECTED]" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 30, 2001 12:02 PM Subject: [PHP-DEV] PHP 4.0.5 Release Midgard Problems Sorry to bring this up yet again but before we release 4.0.5 this needs to be sorted otherwise nothing will ever happen. We have just reached 4.0.5RC4 (which was the final planned RC) and we find that the midgard folks need to fix some bugs with the build process. This will undoubtedly happen again and again ad midgard and PHP work on different release cycles and is by no means the fault of the midgard people but it just isn't practical if we are trying to release stable versions of PHP and midgard is still undergoing heavy development. Sascha complains about the stability of PHP and all of our patch levels yet Rasmus wants to include these extensions that are applications in their own right, it just isn't practical for the QA team to test something the size of midgard and thus it doesn't get tested (unless the midgard folks test it which we have to presume doesn't happen as we get no feedback from them), we then risk getting to a point like this where we are about to release PHP 4.0.5 and it either 1) has to be delayed with another release cycle 2) has to continue with a broken midgarad, neither are great but for the QA team its very annoying when midgard, somewhat of an outside extension means we have to do a whole new cycle. I propose that we remove midgard from the PHP CVS into a separate PEARC module before the release of 4.0.5 so that midgard is never been included in a PHP release. It will give some incentive to get the PEARC system running sooner too. If nobody objects to this strongly I propose we do this in 24-48 hours and then release 4.0.5 which has been dragging on for a while now. James -- James Moore [EMAIL PROTECTED] PHP Web Scripting: http://www.php.net/ PHP QA Team: http://qa.php.net/ PHP-GTK: http://gtk.php.net/ VL-SRM: http://www.vl-srm.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] mail errors on bug form
While updating bugs 9729, 9664, 9656, 8667, I kept getting Warning: Could not execute mail delivery program in /local/Web/sites/phpweb/bugs.php on line 637 Warning: Could not execute mail delivery program in /local/Web/sites/phpweb/bugs.php on line 638 Is anyone aware of this? -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/sockets sockets.c
/usr/src/web/php/php4/ext/standard/url_scanner_ex.re:19: php.h: Permission Do you have any idea which php.h file is being accessed? That line is simply an include, and this implies you don't have read access to php.h -Jason - Original Message - From: "Derick Rethans" [EMAIL PROTECTED] To: "Jason Greene" [EMAIL PROTECTED] Cc: "Jani Taskinen" [EMAIL PROTECTED]; "Sascha Schumann" [EMAIL PROTECTED]; "PHP Quality Assurance Team Mailing List" [EMAIL PROTECTED] Sent: Tuesday, April 10, 2001 12:40 PM Subject: Re: [PHP-CVS] cvs: php4 /ext/sockets sockets.c On Tue, 10 Apr 2001, Jason Greene wrote: Out of those platforms you listed, I have tested this on Linux. I will test FreeBSD today. However, I do not have an OpenBSD box, does anyone out there want to try and build the latest cvs with --enable-sockets on OpenBSD? The socket part builds fine, but I had a lot of other problems on it building PHP: gcc -I. -I/home/derick/php4/ext/standard -I/home/derick/php4/main -I/home/derick/php4 -I/home/derick/php4/Zend -I/home/derick/php4/ext/mysql/libmysql -I/home/derick/php4/ext/xml/expat/xmltok -I/home/derick/php4/ext/xml/expat/xmlparse -I/home/derick/php4/TSRM -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2 -c url_scanner_ex.c touch url_scanner_ex.lo /usr/src/web/php/php4/ext/standard/url_scanner_ex.re:19: php.h: Permission denied *** Error code 1 Stop in /home/derick/php4/ext/standard. *** Error code 1 Stop in /home/derick/php4/ext/standard (line 37 of /home/derick/php4/build/rules.mk). *** Error code 1 Thanks, -Jason - Original Message - From: "Jani Taskinen" [EMAIL PROTECTED] To: "Jason Greene" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, April 10, 2001 5:01 AM Subject: Re: [PHP-CVS] cvs: php4 /ext/sockets sockets.c Have you tested it on Linux, FreeBSD, OpenBSD... ? :) If you know for sure it will work on these, go ahead. --Jani On Mon, 9 Apr 2001, Jason Greene wrote: Everyone, Can I merge this into the current RC? This should not cause any problems. -Jason - Original Message - From: "Jason Greene" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 09, 2001 10:16 PM Subject: [PHP-CVS] cvs: php4 /ext/sockets sockets.c jason Mon Apr 9 20:16:06 2001 EDT Modified files: /php4/ext/sockets sockets.c Log: Fix for PR #9729, 9664, 9656, 8667. All compilers on Solaris should build this extension correctly now. It turns out the SUN CC, by default, enables a define that enables the use of #pragma redefine extname in sun header files. This is why cc would work, and gcc wouldn't. -Jason Index: php4/ext/sockets/sockets.c diff -u php4/ext/sockets/sockets.c:1.33 php4/ext/sockets/sockets.c:1.34 --- php4/ext/sockets/sockets.c:1.33 Thu Mar 22 05:16:58 2001 +++ php4/ext/sockets/sockets.c Mon Apr 9 20:16:05 2001 @@ -17,7 +17,7 @@ +--+ */ -/* $Id: sockets.c,v 1.33 2001/03/22 13:16:58 sniper Exp $ */ +/* $Id: sockets.c,v 1.34 2001/04/10 03:16:05 jason Exp $ */ #include "php.h" @@ -34,6 +34,10 @@ #define _XOPEN_SOURCE_EXTENDED #define _XPG4_2 #define __EXTENSIONS__ + +#ifndef __PRAGMA_REDEFINE_EXTNAME +#define __PRAGMA_REDEFINE_EXTNAME +#endif #include "ext/standard/info.h" #include "php_sockets.h" -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP CVS Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED] Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
i like the sound of that -jason - Original Message - From: "Stig Sther Bakken" [EMAIL PROTECTED] To: "Sascha Schumann" [EMAIL PROTECTED] Cc: "Stig Sther Bakken" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, April 11, 2001 1:43 PM Subject: Re: [PHP-DEV] always building cgi... [Sascha Schumann [EMAIL PROTECTED]] Sascha, what symbols can sneak in to break linking? A few examples I can test with would be nice. As other people on this list have mentioned, building --with-apxs illustrates the breakage. The chosen SAPI module (i.e. sapi/apache/libsapi.la) is part of libphp4.la. Usually, the SAPI module contains calls to server-specific APIs which are resolved upon loading the SAPI module into the web-server. Those external symbols cannot be found (of course) during creating the CGI which is built using libphp4.la. Okay, what about making libphp4.la contain everything but libsapi.la, and make a new final target including libsapi.la called libphp4_xxx.la, where xxx is the sapi module used. With some more minor restructuring, we can then let people build _all_ sapi modules in one go if they like. - Stig -- Stig Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
If there was some way of building the cgi with any sapi, that would be nice. PHP as a cgi is becoming more of a utility than a cgi. Is there a way to accomplish this without changing the user compile interface much? -Jason - Original Message - From: "Sascha Schumann" [EMAIL PROTECTED] To: "Stig Sther Bakken" [EMAIL PROTECTED] Cc: "Stig Sther Bakken" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, April 12, 2001 8:54 PM Subject: Re: [PHP-DEV] always building cgi... Okay, what about making libphp4.la contain everything but libsapi.la, and make a new final target including libsapi.la called libphp4_xxx.la, where xxx is the sapi module used. With some more minor restructuring, we can then let people build _all_ sapi modules in one go if they like. [my internet link died yesterday and I forgot to resend this] Without careful consideration, I would not say that it would require only minor restructuring. If we would implement that change, it would have a direct effect upon the installation procedure of PHP. That is not a problem with online documentation, but what about printed manuals and the dozens of books on PHP? I'd be very hesitant to change anything here which would render those descriptions invalid. On the implementation side, I'm not convinced of the usefulness of such a change. The way libphp4.la is built directly depends upon the chosen SAPI module (thread-safety, shared/static). As of today, there are only a few possible combinations. From day-to-day experience, I have yet to see an installation where web-servers run parallelly (and which use PHP/require the same build options). - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #10322 Updated: Logical error in fopen-wrappers.c
This is almost an exact copy of a patch I had submitted in October of 2000.(before I
became a contributor).
I wonder if it is a copy?
http://marc.theaimsgroup.com/?l=php-devm=97145490702792w=2
This idea (and many others) was on hold to a cleaner redesign of
safe_mode.
-Jason
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, April 14, 2001 4:34 AM
Subject: [PHP-DEV] Bug #10322 Updated: Logical error in fopen-wrappers.c
ID: 10322
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PHP options/info functions
PHP Version: 4.0.4pl1
Assigned To:
Comments:
This will not make it into 4.0.5 as this was branched a while back but it might well
make it into 4.0.6. Ill get a developer to
look at this patch.
- James
Previous Comments:
---
[2001-04-13 20:57:35] [EMAIL PROTECTED]
I thought, while I'm here, I'd submit a patch to fix this.
The patch also includes support for an additional special case in php.ini's
open_basedir.
The current "." allows scripts to access files in the same directory as the script.
"DOCUMENT_ROOT" allows a script to access any other file in the virtualhost's
directory tree. DOCUMENT_ROOT is calculated by
PATH_TRANSLATED and removing SCRIPT_URI from the end - This conveniently works for
both full Apache Virtalhosts and mod_aliased Mass
virtual hosting (I don't know if this is true for the newer mod_vhost - just check
what PATH_TRANSLATED and SCRIPT_URI is set to in
phpinfo() - if removing the latter from the former is the sites docroot then you are
away).
Anyway, the patch: code shamelessly copied from the "." segment :)
*** main/fopen-wrappers.c.orig Fri Apr 13 17:50:02 2001
--- main/fopen-wrappers.c Sat Apr 14 01:46:28 2001
***
*** 141,151
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
int local_open_basedir_pos;
SLS_FETCH();
/* Special case basedir==".": Use script-directory */
! if ((strcmp(PG(open_basedir), ".") == 0)
SG(request_info).path_translated
*SG(request_info).path_translated
) {
--- 141,167
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
+ char *local_open_request_uri;
int local_open_basedir_pos;
SLS_FETCH();
+ /* Special case basedir="DOCUMENT_ROOT": Restrict to directory of the
+* virtualhost itself as calculated by PATH_TRANSLATED - SCRIPT_URI
+* [EMAIL PROTECTED]
+*/
+ if ((strcmp(basedir, "DOCUMENT_ROOT") == 0)
+ SG(request_info).path_translated
+ *SG(request_info).path_translated ) {
+ /* Copy path_translated to local_open_basedir, the look in
+ this string for where request_uri starts and zero that byte
+ thus leaving local_open_basedir set to the virtualhost's
+ DOCUMENT_ROOT */
+ strlcpy(local_open_basedir, SG(request_info).path_translated, si
zeof(local_open_basedir));
+ local_open_request_uri=strstr(local_open_basedir,SG(request_info
).request_uri);
+ if (local_open_request_uri) *local_open_request_uri = '
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] possible --extension-dir directive?
Has there ever been any thought about an extension-dir directive. I don't know what everyone else thinks, but I personally get tired of /usr/local/lib/php/extensions/no-debug-whatever-zendapinum. I think just having an option to force them in /usr/local/lib/php/extensions would be great. I am not familiar of an instance where I have needed multiple extensions per version and type of compile I have performed -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] possible --extension-dir directive?
If not this idea, what about a symbolic link for /usr/local/lib/php/extensions/current to the correct dir? - Jason - Original Message - From: "Jason Greene" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, April 16, 2001 11:10 AM Subject: [PHP-DEV] possible --extension-dir directive? Has there ever been any thought about an extension-dir directive. I don't know what everyone else thinks, but I personally get tired of /usr/local/lib/php/extensions/no-debug-whatever-zendapinum. I think just having an option to force them in /usr/local/lib/php/extensions would be great. I am not familiar of an instance where I have needed multiple extensions per version and type of compile I have performed -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] possible --extension-dir directive?
Hi Stig, I changed this to /usr/local/lib/php/APISPEC in the patch Sascha reverted, but I'll put that part back. The APISPEC part should definitely be included, or we'll have a boatload of mails asking why loading module X failed. If for example some Linux distributions want to skip it (Mandrake cooker does at least), that's up to them. Anyway, the APISPEC will be shortened from "20001222-no-debug-non-zts" to just "20001222", and the "extensions" part of the path is skipped. The PEAR stuff is moved to /usr/local/share/php. Both of these paths can be set with the --datadir and --libdir configure options. I try to put it back in tomorrow. Ok, sounds good. What do you think of the possibility of autobuilding a php.ini file with extensions installed, similar to apache. If one already exists, it could install under a different name? -Jason - Stig -- Stig Sther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] 4.0.5 release
JW, whats the current release schedule plans for 4.0.5, are we going to have an RC8? -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Solaris gcc issues with socket.c, design change recommendation
Sterling, I am writing you because I am assuming you are the socket module maintainer. Awhile back I put in a hack that defines the capability to use a solaris specific pragma (pragma redefine_extname), which essentially allows you to change an external name reference after compile phase, so that the symbol in your object file references another name. Solaris uses this to point all XOPEN socket calls to another function name. (ex socket() is changed to __xnet_socket()) The problem with this is that if the redefine_extname capability isn't available, Solaris uses #define statements. This broke the build on gcc, because it would change every occurrence of socket to __xnet_socket. This ended up producing things like php_if___xnet_socket and php_if___xnet_bind The code I added to cvs prevents the define from occurring, but still does not use the appropriate XOPEN function calls, instead the Solaris functions are referred to. Now when I made the modification, everything tested fine, so using the Solaris socket calls does not appear to cause issues. However, if the functionality of these differ in even a slight way, or in the future they do, we could see possible problems. There is actually a gcc way to perform something equivalent to redefine_extname, but that would require implementing code that fulfilled the job of socket.h. I think that the only clean way to solve the problem is to pull all socket functions into a separate .c file.We can then call them as php_socket, php_bind, etc. In that case, solaris's (and other possible platforms) redefine would no longer be an issue and we could remove the hack I last applied. I am willing to make the modifications of this, but for a change this large, I wanted to get the author's insight. Thanks, -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] stat/fstat
I ran into that a long time ago, and I wondered why. I thought about changing it, but I assumed that it would break backwards compatibility. What about 4.1 though? -Jason - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 10, 2001 5:11 PM Subject: Re: [PHP-DEV] stat/fstat I just figured this only applies to stat() and not fstat(). Which also means they're totally incompatible with each other, although the documentation suggests they're essentially the same, other than the fact that one expects a file handle and the other expects a file name... What gives? At 01:07 11/5/2001, Zeev Suraski wrote: Hey, I just got around to writing a PHP script that uses stat(), and was quite surprised to find that instead of using string indices, it uses hardcoded/obscure numeric indices, e.g.: Array ( [0] = 2050 [1] = 1114462 [2] = 16877 [3] = 2 [4] = 503 [5] = 513 [6] = 11065 [7] = 1024 [8] = 989532201 [9] = 989532201 [10] = 989532201 [11] = 4096 [12] = 2 ) Is there any reason for this? If not, I'd like to add meaningful names as well (I guess it's way too late to remove the numeric indices) Zeev -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] stat/fstat
Its actually not that pretty Since the entries are in a hashtable, you have to duplicate the values, with just another key. -Jason - Original Message - From: Brian Foddy [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Stig Sæther Bakken [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Sent: Friday, May 11, 2001 10:21 AM Subject: Re: [PHP-DEV] stat/fstat [EMAIL PROTECTED] wrote: On 11 May 2001, Stig Sæther Bakken wrote: Why not have both numerical and descriptive indices? Backwards compatible, slightly bloatish, but not really a problem. it's already implemented this way now (it was added last night) AFAIK Derick Rethans You are creating the same array indexed both by a integer and a string? I'm curious how this is done. I might have a good use for this trick. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] stat/fstat
Andrei had the same suggestion, so I went ahead and added it last night. -Jason - Original Message - From: Stig Sæther Bakken [EMAIL PROTECTED] To: Zeev Suraski [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, May 11, 2001 4:18 AM Subject: Re: [PHP-DEV] stat/fstat [Zeev Suraski [EMAIL PROTECTED]] Hey, I just got around to writing a PHP script that uses stat(), and was quite surprised to find that instead of using string indices, it uses hardcoded/obscure numeric indices, e.g.: Array ( [0] = 2050 [1] = 1114462 [2] = 16877 [3] = 2 [4] = 503 [5] = 513 [6] = 11065 [7] = 1024 [8] = 989532201 [9] = 989532201 [10] = 989532201 [11] = 4096 [12] = 2 ) Is there any reason for this? If not, I'd like to add meaningful names as well (I guess it's way too late to remove the numeric indices) Why not have both numerical and descriptive indices? Backwards compatible, slightly bloatish, but not really a problem. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] stat/fstat
On Fri, 11 May 2001, Jason Greene wrote: Its actually not that pretty Since the entries are in a hashtable, you have to duplicate the values, with just another key. You could just reuse the same value with refcount++ but that means you can't use nice add_* functions, gotta use zend_hash_* ones directly. ;-) True, I was lazy though and didn't feel like writing all that additional code, just to save 13 longs of memory space : ) -Jason -Andrei 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, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] stat/fstat
Ah yes, I stand corrected , 13 zvals : ) -Jason - Original Message - From: Andrei Zmievski [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: Jason Greene [EMAIL PROTECTED]; Brian Foddy [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stig Sæther Bakken [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Sent: Friday, May 11, 2001 11:38 AM Subject: Re: [PHP-DEV] stat/fstat On Fri, 11 May 2001, Jason Greene wrote: True, I was lazy though and didn't feel like writing all that additional code, just to save 13 longs of memory space : ) 13 * sizeof(zval) actually. -Andrei When we eliminate the impossible, whatever remains, however improbable, must be true. -- Sherlock Holmes -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] stat/fstat
Well, due to the great interest in memory conservation, fstat and stat are now rewritten to share the vals across multiple keys : ) So now we are saving the user 13* sizeof(zval)+sizeof(zend_mem_header).+whatever of memory : ) -Jason - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Andrei Zmievski [EMAIL PROTECTED] Cc: Jason Greene [EMAIL PROTECTED]; Jason Greene [EMAIL PROTECTED]; Brian Foddy [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stig Sæther Bakken [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Sent: Friday, May 11, 2001 12:36 PM Subject: Re: [PHP-DEV] stat/fstat At 19:38 11/5/2001, Andrei Zmievski wrote: On Fri, 11 May 2001, Jason Greene wrote: True, I was lazy though and didn't feel like writing all that additional code, just to save 13 longs of memory space : ) 13 * sizeof(zval) actually. 13*(sizeof(zval)+sizeof(zend_mem_header)), and possibly slightly more, actually :) Next thing you know you'd run out of memory just because of this. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] stat/fstat
Yikes. We were only kidding, Jason :) Ya , but you guys sparked that old memory efficiency routine in my brain from when I used to write assembly : ) Hey did you get a chance to read my fork() dev posting, and that email about assign-op's in zend_execute? I some advice/suggestions . Thanks, -Jason At 23:00 11/5/2001, Jason Greene wrote: Well, due to the great interest in memory conservation, fstat and stat are now rewritten to share the vals across multiple keys : ) So now we are saving the user 13* sizeof(zval)+sizeof(zend_mem_header).+whatever of memory : ) -Jason - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Andrei Zmievski [EMAIL PROTECTED] Cc: Jason Greene [EMAIL PROTECTED]; Jason Greene [EMAIL PROTECTED]; Brian Foddy [EMAIL PROTECTED]; [EMAIL PROTECTED]; Stig Sæther Bakken [EMAIL PROTECTED]; PHP Developers Mailing List [EMAIL PROTECTED] Sent: Friday, May 11, 2001 12:36 PM Subject: Re: [PHP-DEV] stat/fstat At 19:38 11/5/2001, Andrei Zmievski wrote: On Fri, 11 May 2001, Jason Greene wrote: True, I was lazy though and didn't feel like writing all that additional code, just to save 13 longs of memory space : ) 13 * sizeof(zval) actually. 13*(sizeof(zval)+sizeof(zend_mem_header)), and possibly slightly more, actually :) Next thing you know you'd run out of memory just because of this. Zeev -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] stat/fstat
At 03:31 AM 5/12/01 +0300, Zeev Suraski wrote: Yikes. We were only kidding, Jason :) Well, he could have the last argument of zend_hash_update() to receive the point to inserted value and done refcount++ on that and inserted again. ;-) The only thing with that method is that I was trying to place the hash table in true stat order, so that all the numeric keys are before the string keys, so that someone could easily move to the next element without getting a duplicate value. I suppose I could have created another zval * for each insret to catch the pointer the returned value, but I was trying to make the code is clean as possible, and it just seemed easier to start off declaring the zval with another refcount. I've been thinking we need to have add_* functions returning the pointer to inserted value somehow.. Plus the set of corresponding functions for retrieving data easily. -Andrei I agree, it seems that the add_ functions are so high level that it is common to switch to using the hash functions. However, the hash functions are often too low level, and add a lot of complexity. Some enhanced add functions would help out alot if nothing more then helping readibility of code : ) -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] zval_copy_ctor
zval_copy_ctor used on an array makes a reference copy of the array.
Basically, it just copies all the data items in the hashtable and then adds one to the
reference count for all data items.
Looking at the code, it appears to not recursively copy into nested arrays.
(Could be part of your problem)
Since this is a reference copy, you can not free the memory used by
the array you are copying. I am assuming that this is the cause of your default.
-Jason
- Original Message -
From: Wez Furlong [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 11, 2001 8:42 PM
Subject: [PHP-DEV] zval_copy_ctor
Hi,
In my mailparse extension I am building up an array to contain the headers
while parsing the message. The array is held in a zval in the internal C
structure, one for each message part.
When the user space code requests info for a particular message part it
is returned as an assoc. array. One of the keys contains the headers;
eg:
$info = array(
content-type = text/plain,
headers = array(
to = [EMAIL PROTECTED],
from = [EMAIL PROTECTED]
)
);
So far, to do this I am using this code:
zval * headers;
MAKE_STD_ZVAL(headers);
*headers = *rfcbuf-headers;
if (zval_copy_ctor(headers) == SUCCESS) {
zend_hash_update(HASH_OF(return_value), headers,
strlen(headers) + 1, headers, sizeof(headers)
NULL);
}
where rfcbuf-headers is a zval * created using MAKE_STD_ZVAL and
array_init.
It seems to work OK.
Is it correct? The ZendAPI docs aren't 100% clear about using the copy
constructor, and I am experiencing intermittent segfaults in a specific
part of my application that uses this code.
--Wez.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] zval_copy_ctor
Sorry,
default=segfault
spellcheck got me
-Jason
- Original Message -
From: Jason Greene [EMAIL PROTECTED]
To: Wez Furlong [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, May 11, 2001 10:29 PM
Subject: Re: [PHP-DEV] zval_copy_ctor
zval_copy_ctor used on an array makes a reference copy of the array.
Basically, it just copies all the data items in the hashtable and then adds one to
the
reference count for all data items.
Looking at the code, it appears to not recursively copy into nested arrays.
(Could be part of your problem)
Since this is a reference copy, you can not free the memory used by
the array you are copying. I am assuming that this is the cause of your default.
-Jason
- Original Message -
From: Wez Furlong [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 11, 2001 8:42 PM
Subject: [PHP-DEV] zval_copy_ctor
Hi,
In my mailparse extension I am building up an array to contain the headers
while parsing the message. The array is held in a zval in the internal C
structure, one for each message part.
When the user space code requests info for a particular message part it
is returned as an assoc. array. One of the keys contains the headers;
eg:
$info = array(
content-type = text/plain,
headers = array(
to = [EMAIL PROTECTED],
from = [EMAIL PROTECTED]
)
);
So far, to do this I am using this code:
zval * headers;
MAKE_STD_ZVAL(headers);
*headers = *rfcbuf-headers;
if (zval_copy_ctor(headers) == SUCCESS) {
zend_hash_update(HASH_OF(return_value), headers,
strlen(headers) + 1, headers, sizeof(headers)
NULL);
}
where rfcbuf-headers is a zval * created using MAKE_STD_ZVAL and
array_init.
It seems to work OK.
Is it correct? The ZendAPI docs aren't 100% clear about using the copy
constructor, and I am experiencing intermittent segfaults in a specific
part of my application that uses this code.
--Wez.
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Solaris gcc issues with socket.c, design change recommendation
Sterling, Did you ever get a chance to read the email about the change I suggested to /ext/sockets that would improve compatibility with Solaris? -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] mmap in php_passthru_fd in file.c ?
Mauro et al, Solaris Internals, 5.3.8 Page Faults in Address Spaces, 5.4.1 The vnode Segment: seg_vn, 5.8 The Page Scanner This is an excelent reference, definately a favorite of mine. -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard file.c
I am all for that, but don't forget filestat.c and the macro
in php_filestat.h.
Thanks,
Jason
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 18, 2001 3:08 PM
Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard file.c
I was just about to do an automatic merge of this fix to the PHP_4_0_6
branch when I saw that the merge will also merge the stat() update which
creates associative keys too (cvs update -j 1.159 file.c after an update -r
PHP_4_0_6).
Any objections to me merging that one too? I think it would be good to have
it in 4.0.6.
If people mind I can just merge this one by hand.
Andi
At 05:48 PM 5/18/2001 +, Sascha Schumann wrote:
sas Fri May 18 10:48:43 2001 EDT
Modified files:
/php4/ext/standard file.c
Log:
Files should be shared among processes.
Index: php4/ext/standard/file.c
diff -u php4/ext/standard/file.c:1.158 php4/ext/standard/file.c:1.159
--- php4/ext/standard/file.c:1.158 Sat May 12 14:48:39 2001
+++ php4/ext/standard/file.cFri May 18 10:48:43 2001
@@ -21,7 +21,7 @@
+--+
*/
-/* $Id: file.c,v 1.158 2001/05/12 21:48:39 wez Exp $ */
+/* $Id: file.c,v 1.159 2001/05/18 17:48:43 sas Exp $ */
/* Synced with php 3.0 revision 1.218 1999-06-16 [ssb] */
@@ -1546,7 +1546,7 @@
if (sbuf.st_size sizeof(buf)) {
off = ftell(fp);
len = sbuf.st_size - off;
- p = mmap(0, len, PROT_READ, MAP_PRIVATE, fd, off);
+ p = mmap(0, len, PROT_READ, MAP_SHARED, fd, off);
if (p != (void *) MAP_FAILED) {
PHPWRITE(p, len);
munmap(p, len);
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Fork() in php?
I was thinking about MT in php, but the platform differences would be a nightmare. We could abstract it like perl does, though even their implementation has problems. I would like to start with process control features (fork(), signals, waitpid() etc), but I am not sure where everything should go. Should there be a /ext/process? Should signals be in a separate extension? Let me know what you guys think. -Jason - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Stig Sæther Bakken [EMAIL PROTECTED] Cc: Manuel Lemos [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, May 21, 2001 4:33 AM Subject: Re: [PHP-DEV] Fork() in php? At 16:00 21/5/2001, Stig Sæther Bakken wrote: There are no plans for adding MT to PHP itself, but you do have a poor man's cooperative multi-threading through ticks. So now we have a poor man's objects and a poor man's multitasking. What does that say about us? :-) That we have a filthy rich man's Web platform? :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] is php dev alive
is the list back?? -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Fork() in php?
Hi, When cvs comes back up checkout the new experimental module pcntl. This is experimental so don't go using this for production just yet. Thanks, -Jason - Original Message - From: Daniel Fuehrer [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Sent: Monday, June 18, 2001 5:53 PM Subject: Re: [PHP-DEV] Fork() in php? Hi! could you please send me those fork test functions ? I've written a simple NNTP-Server and the only thing missing is a fork-function. Many thanks in advance. Daniel Fuehrer -- every.de - Your Community / Web: http://www.every.de/ / Mail: [EMAIL PROTECTED] - Original Message - From: Jason Greene [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, May 11, 2001 5:10 PM Subject: [PHP-DEV] Fork() in php? What do you guys think about having fork, waitpid, and signal handling available in php? I wrote a few simple fork test functions, and everything seemed to work fine. I am thinking that with sockets, shm, signals, and fork capability, there could be the possibility of someone writing daemons in php : ) Can anyone think of possible problems that could occur in supporting this functionality? If it were to be added, where should it be added? IMO this type of thing probably shouldn't exist in ext/standard. Thanks, -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] is php dev alive
Hell yah!!! - Original Message - From: spencer 'sporty' portee [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 18, 2001 3:31 PM Subject: Re: [PHP-DEV] is php dev alive yes! On Mon, Jun 18, 2001 at 03:17:59PM -0500, Jason Greene wrote: is the list back?? -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] is php dev alive
now if cvs were to come back : ) - Original Message - From: spencer 'sporty' portee [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, June 18, 2001 3:31 PM Subject: Re: [PHP-DEV] is php dev alive yes! On Mon, Jun 18, 2001 at 03:17:59PM -0500, Jason Greene wrote: is the list back?? -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] pcntl's use of zend_extension API
Andi or Zeev (Whoever has time for this), I have added an experimental process control module to cvs for fork() signals etc. In order for me to provide asynchronously safe signal handling I need to make sure that I never call the programmers php function during any of php's or Zend's internal updates. I am currently using the zend_extension_statement_handler for this purpose, but I have concerns about the efficiency of this. Since this adds additional op-codes, and was mainly intended for debug extensions, it seems that there should be a better hook more suited to what I am doing. I was thinking of a possible callback that could be placed in Zend's main execute loop. What do you guys think? Thanks, -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] lxr.php.net
kudos Andrei - Original Message - From: Andrei Zmievski [EMAIL PROTECTED] To: PHP Developers [EMAIL PROTECTED] Sent: Tuesday, July 03, 2001 2:37 PM Subject: [PHP-DEV] lxr.php.net lxr.php.net is back up. bonsai.php.net to follow shortly. -Andrei The church is near but the road is icy; the bar is far away but I will walk carefully. -- Russian proverb -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Reentrant C scanners for PHP
Sascha, This looks good. Is this going to be brought into php, or is it going to remain a separate project? Thanks, Jason - Original Message - From: Sascha Schumann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 6:08 PM Subject: [PHP-DEV] Reentrant C scanners for PHP This is the first public release of fully reentrant C scanners for the PHP language and the INI system. They can be used to replace the Flex-based implementations commonly found in the Zend Engine. Features: - Flexible I/O model; lays groundwork for fully supporting modern web-servers such as Apache 2.0; - uses portable C only; significantly improves portability by removing dependence on GNU extensions of C++; - fully thread-safe without loss of speed. The software is currently available in the form of three source files and a patch to the Zend Engine. http://schumann.cx/ngscan-0.1.tar.gz To install, cd into the ngscan directory and run make ZEND=../php4/Zend install, followed by a buildconf. Because software already exists to eliminate the scan/parse process, speed was not a main concern. The new language scanner is faster than the old one in all tested scenarios though. time savedlines what 10%500K ? echo test ? 15%500K ? echo test ? 40%1.5M pure HTML -500K ZTS, ? echo test ? (1) 87%500K ZTS, ? echo test ? 99%1.5M ZTS, pure HTML (2) (1) crashed in vprintf, apparently some glibc/pthread issue (2) +4 minutes vs 800 milli-seconds (user times taken from a command-line CGI, CFLAGS=-O, --enable-inline-optimization, gcc 2.95.3, Linux 2.4.6, glibc 2.2.3) - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #8135 Updated: FTP_FPUT can't use a HTTP Filepointer
Sorry, I was half of sleep that night. The idea here is to be able to read from the fopen()'ed stream and ftp_fput() the data.. not the other way around. (Jason, READ the bug reports before closing them, also RTFM) Exaclty what manual would you like me to read, Jani? -Jason --Jani Previous Comments: [2001-07-07 00:21:15] [EMAIL PROTECTED] HTTP fopens are read only. -Jason [2000-12-06 10:43:07] [EMAIL PROTECTED] for example : $fp = fopen(http://www.php.net;, r); ftp_fput( $ftp_stream, remote, $fp, FTP_ASCII); doesn't work. But the following code-example : $fp = fopen(file.txt, r); ftp_fput( $ftp_stream, remote, $fp, FTP_ASCII); works. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8135edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Libtool problem with current build process
Sascha + Everyone, There is a current build problem with libtool where we pass -prefer-non-pic or -prefer-pic during mode=link. Since this is not a valid mode=link option it gets passed to the linker as an option. On some platforms (Sun CC), this cuases an error and aborts. I started to take a look at making a fix, but the build system is quite large, and since I don't feel like breaking, I decided to just email my progress, and see what else should be accounted for. This tiny patch is part of some changes that I think should be made. This changes the standard_libtool_flag, which just gets added to CFLAGS, to using a compile_libtool_flag, and exporting it out so that all the other pieces of the system can use it. Thanks, -Jason === RCS file: /repository/php4/configure.in,v retrieving revision 1.258 diff -u -r1.258 configure.in --- configure.in 2001/07/04 10:10:29 1.258 +++ configure.in 2001/07/09 21:58:22 @@ -658,7 +658,8 @@ case $php_build_target in program|static) -standard_libtool_flag='-prefer-non-pic -static' +compile_libtool_flag='-prefer-non-pic' +standard_libtool_flage='--static' if test $lib_build_shared != yes; then enable_shared=no fi @@ -667,7 +668,7 @@ ;; shared) enable_static=no -standard_libtool_flag=-prefer-pic +compile_libtool_flag=-prefer-pic EXTRA_LDFLAGS=$EXTRA_LDFLAGS -avoid-version ;; esac @@ -824,6 +825,7 @@ PHP_SUBST(localstatedir) PHP_SUBST(datadir) PHP_SUBST(sysconfdir) +PHP_SUBST(compile_libtool_flag) PHP_SUBST(AWK) PHP_SUBST(CC) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Str enhancement, final run
I had suggested the start end construct, but was rejected by Zeev due to performance
reasons,
and that nobody in the history of php has ever need this : )
-Jason
- Original Message -
From: Jeroen van Wolffelaar [EMAIL PROTECTED]
To: Derick Rethans [EMAIL PROTECTED]; André Langhorst [EMAIL PROTECTED]
Cc: Andi Gutmans [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED];
[EMAIL PROTECTED]; Stanislav Malyshev [EMAIL PROTECTED];
Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, July 10, 2001 1:04 PM
Subject: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: Str enhancement, final run
I've said it before, but I *really* am convinced now, that we should:
- At least allow $str{index} (while _deprecating_ the array $str[ ] indices)
- _possibly_ also allowing $str{start..end}
- and if the above is allowed, then I think you should also allow
$str{..end} and $str{start..}
But *nothing else*.
Greetz,
Jeroen
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Bug #11008 Updated: exit() should return an exit status if passed, not send to stdout
Zeev,
New Comment:
Simply put - no, it should not.
exit's optional argument is a termination message, not a shell status.
Actually, if exit's argument is of type long, then the status is set. I think that
since we support this functionality
echoing the status code doesn't make much sense.
To make matters more confusing, the documentaion incorrectly states that die prints a
termination message,
and that exit sets a status code. I actually agree with seperating die and exit, but I
realize this could cause
backwards compatibility issues. So IMHO, I see 2 possible fixes
1. ) Seperate die, exit, and implement them as the php manual states
2. ) Modify the condition of exits param being a long to not print the message
ie
ptr = get_zval_ptr(opline-op1, Ts,
EG(free_op1), BP_VAR_R);
if (Z_TYPE_P(ptr) == IS_LONG) {
EG(exit_status) = Z_LVAL_P(ptr);
} else zend_print_variable(ptr);
FREE_OP(opline-op1, EG(free_op1));
-Jason
Previous Comments:
[2001-05-23 11:24:22] [EMAIL PROTECTED]
Anyone in the Zend core want to comment on this? I know where the code is that does
it. But it is in the Zend code.
Is there a good reason to put this exit status to stdout?
[2001-05-22 01:59:53] [EMAIL PROTECTED]
indeed it does both:
if php; then echo yes; fi
? exit(0) ?
X-Powered-By: PHP/4.0.5
Content-type: text/html
0yes
if php; then echo yes; fi
? exit(1) ?
X-Powered-By: PHP/4.0.5
Content-type: text/html
1
i don't see a real reason for the echoed exit status though
[2001-05-21 21:34:23] [EMAIL PROTECTED]
Working with a shell script here. I hoped that exit() would work like perl and
return the passed status as and exist status. As
it stands now, it sends it to stdout. This is unexpected.
It would be much more useful if exit() could be used to enable the use of PHP in
shell scripts by returning the passed value as an
exit status.
Edit this bug report at http://bugs.php.net/?id=11008edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving output.c from ext/standard to main/
It a shame that CVS doesn't have a way to handle things like this.. Are there commercial systems that can? -Jason - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, July 20, 2001 8:14 AM Subject: [PHP-DEV] Moving output.c from ext/standard to main/ It's been bugging me for over a year now, and I'm now trying to figure out the best way to do it. output.c sits today in ext/standard, which is wrong, as it's really a part of the inner core of PHP, and not a set of functions. If I move the file in the CVS repository and fix the references, then everything would be fine, history would be retained, except checking out old CVS's will no longer work. If import the file into main/ and delete it from ext/standard, we lose the history for it, which is sucky. I'm thinking about moving the file in CVS, and in addition to fixing the HEAD branch, fix also the 4.0.6 branch, so that we at least can check out one version back. What do you guys think? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Moving output.c from ext/standard to main/
Wow, thanx. All my cvs gripes are answered. Can wait to use it when its stable. -Jason - Original Message - From: Sebastian Bergmann [EMAIL PROTECTED] To: php-dev mailinglist [EMAIL PROTECTED] Sent: Friday, July 20, 2001 9:25 AM Subject: Re: [PHP-DEV] Moving output.c from ext/standard to main/ Jason Greene wrote: It a shame that CVS doesn't have a way to handle things like this. Are there commercial systems that can? You don't need a commercial system for this. I recently came by accident across subversion http://subversion.tigris.org/ I have yet to download and get a feel for it, but the website's feature list looks promising. For instance, it says Directories, renames, and file meta-data are versioned. Lack of these features is the most common complaint against CVS -- basically, CVS only versions file contents. Subversion will handle directory changes, file renames, and permission and other meta-data changes as well. -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] cvs socket extension
Just for curiosity, did you considered implementing poll instead of select? You would
not have to worry about specifying
max_fd - 1.
-Jason
- Original Message -
From: Chris Vandomelen [EMAIL PROTECTED]
To: Markus Fischer [EMAIL PROTECTED]
Cc: Daniel Beulshausen [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, July 23, 2001 9:20 AM
Subject: Re: [PHP-DEV] cvs socket extension
socket_select(0x7fff, $fd_set, 0, 0, 0, 0);
we can add a support function which return's the php_socket-socket integer.
Glad someone came up with this.
Since socket_select() always wants highest +1, couldn't this be
implemented into socket_select() to go through all socket sets
and get the number itself ?
Or are there good reasons to let the user specify the value on
its own ?
In theory, the user isn't going to be specifying sockets that aren't
accessible as resources.
The best way around this (IMHO) is to define a php_fd_set something like:
struct php_fd_set {
fd_set the_set;
intmax_fd;
};
Then, whenver someone calls fd_set() or fd_zero(), change
php_fd_set.max_fd appropriately as well as updating php_fd_set.the_set,
and in socket_select(), check all of the max_fd values.
Removing the first arg to socket_select(), if that's implemented, wouldn't
be a bad idea either.
Chris
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Chora installed
I have been using Chora internally for about 2 months, and have had no issues. I highly recommend we make this the default. -Jason - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, July 26, 2001 11:02 AM Subject: [PHP-DEV] Chora installed Chuck installed his PHP-based cvs browsing app. It is available at http://chora.php.net. Go have a look. I think it looks really good and we should probably make it the default for http://cvs.php.net. Anybody see any reason not to do that? -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues
I have been watching this thread for too long and I can no longer resist commenting. If a programmer does not initialize SECURE variables properly, he is going to make far worse security decisions in his software. Next thing we are going to hear is that php does not auto TAINT check parsed variables. I personally disagree with making register_globals=off a default. I really don't think it will make that big of a difference, and come on everyone, this is one of the coolest features of php. -Jason - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Alexander Wagner [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, July 27, 2001 9:37 AM Subject: Re: [PHP-DEV] Security Issues Peter Petermann wrote: I fully agree here with Rasmus and I also think this will be the workaround for most people -- if one _does_ care about security, he even knows what and how to do nowadays. I don't think turning register_globals to off will evangelize people to develop more secure scripts/applications. thats it. I see your point, but I disagree. Register_globals is a lanugage-feature which can result in security-gaps when people don't initialize their variables. It's a common mistake, a pitfall, especially for beginners, that could be resolved by turning register_globals off. And is resolved by turning on E_NOTICE. Please, can you say beginner? Once people read that kind of stuff, they are not beginners any more. They aren't the problem. You can't force people to write secure applications, but you can make it easier. Or you can simply stop these people from using PHP which is another effect turning off register_globals will have. Java does not have this problem because Java is so complex that this same set of users can not program in Java. Fixing this problem by making PHP more complex and eliminating these problem users is a bad idea as far as I am concerned. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)
- Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Jani Taskinen [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 1:02 PM Subject: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...) At 21:01 08-08-01, Jani Taskinen wrote: [moving this to php-dev] First: Great! Woohoo! Thanks Zeev! Andi helped with it too :) I vote for $_EVIL :) Well that would inspire programmers to be moe security consious with that data : ) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)
How about $_COULDCONTAINSHELLCODE? -jason - Original Message - From: Jani Taskinen [EMAIL PROTECTED] To: Zeev Suraski [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 1:09 PM Subject: Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...) On Wed, 8 Aug 2001, Zeev Suraski wrote: At 21:01 08-08-01, Jani Taskinen wrote: [moving this to php-dev] First: Great! Woohoo! Thanks Zeev! Andi helped with it too :) Ah. Thanks Andi! :) I vote for $_EVIL :) I am not kidding. Naming it like that would definately be a clear sign for everyone that this stuff is not safe to use just as it is. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)
What about using the acronyms in any combination. like $_GPC and $_GC and etc -Jason - Original Message - From: Cynic [EMAIL PROTECTED] To: Jani Taskinen [EMAIL PROTECTED] Cc: Zeev Suraski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 1:25 PM Subject: Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...) At 20:14 8/8/2001, Jani Taskinen wrote the following: -- On Wed, 8 Aug 2001, Cynic wrote: How about $_DONT_TOUCH_THIS ? :) Seriously though, I vote for $_REQUEST. After all, it contains data which is (generally) tied to one particular request... This reminds me that should the $_FILES be included in this data too? As it's also something you shouldn't trust and it's also coming from the user. --Jani Yeah. And $_SESSION too. [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)
- Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: Jani Taskinen [EMAIL PROTECTED]; Cynic [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 1:20 PM Subject: Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...) My top of the list is: $_REQUEST $_EVIL (Andi and I think it's really pretty good, but we both figured we'll end up going with a different alternative :) What about $_TAINTED ? -Jason Zeev At 21:12 08-08-01, Jason Greene wrote: What about using the acronyms in any combination. like $_GPC and $_GC and etc -Jason - Original Message - From: Cynic [EMAIL PROTECTED] To: Jani Taskinen [EMAIL PROTECTED] Cc: Zeev Suraski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 1:25 PM Subject: Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...) At 20:14 8/8/2001, Jani Taskinen wrote the following: -- On Wed, 8 Aug 2001, Cynic wrote: How about $_DONT_TOUCH_THIS ? :) Seriously though, I vote for $_REQUEST. After all, it contains data which is (generally) tied to one particular request... This reminds me that should the $_FILES be included in this data too? As it's also something you shouldn't trust and it's also coming from the user. --Jani Yeah. And $_SESSION too. [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.7
There is one issue with 4.0.7 that probably should be fixed before branch. The build system currently adds a libtool flag into CFLAGS whether libtool is in link or compile mode. Since this option is only valid in compile, it gets passed to the compiler. This causes a warning with gcc, but for other compilers (a la SUN CC) they fail I emailed Sascha about this, and he said that these options have to be added to CFLAGS, in order to allow automake to still function correctly. So far it looks like the only solutions, is to get rid of automake, and if that is done, I would think that it should occur before branch. -Jason - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 1:48 PM Subject: [PHP-DEV] PHP 4.0.7 As those of you who are subscribed to php-cvs may have noticed, Andi and I implemented today the functionality I suggested to replace register_globals: - $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace $HTTP_*_VARS (the old vars still remain for downwards compatibility) - The new variables are auto-globals - they're available in all function contexts - there's no need to import them using the 'global' statement or reference them using $GLOBALS. - $_REQUEST (this name might change) - includes the data from $_GET, $_POST, $_COOKIE and $_FILES, all in one array, for those users who don't really care to differentiate between the various types of input. This change was my last major TODO item for PHP 4.0.7. At this point, we should try to get PHP 4.0.7 out the door soon. I suggest we branch 4.0.7 away next Tuesday, and start the QA process. This should give people enough time to make any final changes they want to put into 4.0.7. One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0 simultaneously, with the only difference between them being the default value for register_globals. This would create lots of noise and encourage people to start actually using the new $_GETfriends features, which can otherwise go unnoticed. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.7
Yes, he said the same thing to me. The prefer-pic prefer-non-pic options where added in libtool 1.4 so this issue became present as soon as we moved to 1.4 and added those options. -Jason - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 2:11 PM Subject: Re: [PHP-DEV] PHP 4.0.7 From what I understand, Sascha doesn't have time to do that in the near future, so waiting for this is probably not the right thing to do. Is this a new issue? Zeev At 22:01 08-08-01, Jason Greene wrote: There is one issue with 4.0.7 that probably should be fixed before branch. The build system currently adds a libtool flag into CFLAGS whether libtool is in link or compile mode. Since this option is only valid in compile, it gets passed to the compiler. This causes a warning with gcc, but for other compilers (a la SUN CC) they fail I emailed Sascha about this, and he said that these options have to be added to CFLAGS, in order to allow automake to still function correctly. So far it looks like the only solutions, is to get rid of automake, and if that is done, I would think that it should occur before branch. -Jason - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 1:48 PM Subject: [PHP-DEV] PHP 4.0.7 As those of you who are subscribed to php-cvs may have noticed, Andi and I implemented today the functionality I suggested to replace register_globals: - $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace $HTTP_*_VARS (the old vars still remain for downwards compatibility) - The new variables are auto-globals - they're available in all function contexts - there's no need to import them using the 'global' statement or reference them using $GLOBALS. - $_REQUEST (this name might change) - includes the data from $_GET, $_POST, $_COOKIE and $_FILES, all in one array, for those users who don't really care to differentiate between the various types of input. This change was my last major TODO item for PHP 4.0.7. At this point, we should try to get PHP 4.0.7 out the door soon. I suggest we branch 4.0.7 away next Tuesday, and start the QA process. This should give people enough time to make any final changes they want to put into 4.0.7. One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0 simultaneously, with the only difference between them being the default value for register_globals. This would create lots of noise and encourage people to start actually using the new $_GETfriends features, which can otherwise go unnoticed. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.7
Well it's actually libtool 1.4 combined with automake that creates the issue Automake needs the libtool mode=compile prefer-pic,prefer-non-pic flags added to CFLAGS so that it gets added to the compile line. The problem is that CFLAGS is passed in linking phase as well. If we moved back to libtool 1.3 and/or removed the pic options everything would work fine. Do we want to do this though? -Jason - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED] Sent: Wednesday, August 08, 2001 2:18 PM Subject: Re: [PHP-DEV] PHP 4.0.7 At 02:01 PM 8/8/2001 -0500, Jason Greene wrote: There is one issue with 4.0.7 that probably should be fixed before branch. The build system currently adds a libtool flag into CFLAGS whether libtool is in link or compile mode. Since this option is only valid in compile, it gets passed to the compiler. This causes a warning with gcc, but for other compilers (a la SUN CC) they fail I emailed Sascha about this, and he said that these options have to be added to CFLAGS, in order to allow automake to still function correctly. So far it looks like the only solutions, is to get rid of automake, and if that is done, I would think that it should occur before branch. It used to work. Can't we just rollback to the automake version which worked? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/sablot php_sablot.h
Is this really what the goal is here? It seems like a contest to see how many times Zend can appear in the code. I think some of this stuff should be PHP_ or for things that really are engine related, perhaps ENGINE_ to at least pretend that this is a modular architecture where if someone was brave enough they could try to use the modularity and plug in another engine. There was no need to write this long Email just to make the simple point that you want to make PHP modular in the other way, which it isn't and never designed to be. Yes, PHP is completely dependant on the Zend engine, and it's not supposed to be easy to plug in another scripting engine. When Andi and I separate the engine from PHP it was with one goal - having the ability to reuse it in applications other than PHP. I remember that you immediately thought about it the other way around, but it's not any more true today as it was then, and if you recall, I told you that right away. An app built on a certain infrastructure is dependant on that infrastructure, but not the other way around. However, if everyone on php-dev thinks the above look to a PHP extension is just fine, I'll stop bickering. I'm +1 on that :) Zeev I do have to agree with Rasmus here. Yes, Zeev, PHP is completely dependant on its engine, but the macro names are not acting like a truly modular system. The analogy I come up with here is a hash table data structure. What if instead of having a neutral hash_function = weinberger_hash, you had weinberger_hash = whatever. This name convention really does not make much sence, becuase it implys that every hash function must be a weinberger algorythym. If you take a look at the ZEND_FUNCTION macro, this suggests to the module developer that he is writing a function for the ENGINE not the language. You are right that it is the engine's job to register functions, module names, etc. However that is the description of ANY engine, not just Zend. If you are to say that you are modular you MUST be able to clearly differiantiate between all the modules of the system, and yes any of those module should be capable of being replaced. I am not saying that anyone should even try to replace the engine, but I am saying there should be clear distinction between the components of PHP. If I could argue anything else, I would argue simple readibility. It should be clear to the PHP developers that they are using the systems API not one module that is a part of the system even if that module is the engine. -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Console Work
fork is already implemented, along with signals, waitpid, and all the wait.h macros in the pcntl extension. -Jason - Original Message - From: Dave Wilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, August 15, 2001 11:04 AM Subject: [PHP-DEV] Console Work Hi there, I'm new to the list (only subscribed 2 mins ago!). I have subscribed a) to say bloody well done on a great language! and b) I am trying to find information on a few things related to console php (php -q)... First off, I wrote a small addition to ext/standard/exec.c that adds a fork () function. I haven't been testing it much yet (I've started to write a web server in it to see how well it works), but was wondering, is there a reason why the official PHP 4 currently lacks fork functionality? Obviously this wouldn't work very well in a web server module environment, but compiled as a CGI (for shell script style use), it is very handy. PHP seems pretty complete as far as console work goes, I have a 'standard' read ($prompt) function I can use that will determine the current TTY, open it, and get a line from the user. Readline is also extremely useful. My problem is with beutified output however. The day I untar php-x.xx.tar.gz and see ext/ncurses/php_ncurses.c flying past my terminal is a day I will be very preoccupied with code hacking into the early hours! My last 'feature request' is that of either a select () ability (I see 4.0.6 has a function called select in ext/standard/file.c (and ext/sockets/???.c) but I have not played with it), or another ability to read from files / fifos / character devices in a non-blocking way. Particularly, /dev/modem work is to my knowledge impossible at present. To round up, an ncurses module would be nice, a select function like that in C would be sex (!), a fork function (like that in C..). Thanks for your time taken reading the e-mail, and thanks for a bloody brilliant language (I have used it for web work too). If PHP had the above functionality, I can't see much left that stops it from being a rather complete and feature-packed general shell scripting language! (doh! signal handling would be nice too!) Cherio, -dw PS Another thing I noticed, I wrote a diary.php script that allows me 'ninja speed' access to an OpenSSL'd diary in a very secure way. The code behind it is relatively tight, yet when I run it strace'd, I notice that there are a good 50 or so getuid ()'s before the EDITOR is exec'd. The speed at which the program runs is fine, but I was just wondering if it might indicate an underlying problem, or is that just the nature of interpreted languages (not very optimal)! On request, I'll make diary.php available, I intend sticking it on a public site soon anyway. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Console Work
My last 'feature request' is that of either a select () ability (I see 4.0.6 has a function called select in ext/standard/file.c (and ext/sockets/???.c) but I have not played with it), or another ability to read from files / fifos / character devices in a non-blocking way. Particularly, /dev/modem work is to my knowledge impossible at present oh ya, socket_select in the sockets module is a full implementation of the C select To round up, an ncurses module would be nice, a select function like that in C /ext/ncurses would be sex (!), a fork function (like that in C..). Thanks for your time taken reading the e-mail, and thanks for a bloody brilliant language (I have used it for web work too). If PHP had the above functionality, I can't see much left that stops it from being a rather complete and feature-packed general shell scripting language! (doh! signal handling would be nice too!) Cherio, -dw PS Another thing I noticed, I wrote a diary.php script that allows me 'ninja speed' access to an OpenSSL'd diary in a very secure way. The code behind it is relatively tight, yet when I run it strace'd, I notice that there are a good 50 or so getuid ()'s before the EDITOR is exec'd. The speed at which the program runs is fine, but I was just wondering if it might indicate an underlying problem, or is that just the nature of interpreted languages (not very optimal)! On request, I'll make diary.php available, I intend sticking it on a public site soon anyway. Do You Yahoo!? Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk or your free @yahoo.ie address at http://mail.yahoo.ie -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] chroot(): _not_ safe-mode restricted?
IMHO There is no reason to use chroot in safe_mode, and it should be disabled. As far as webservers running as root, potentially any webserver could, though you are probably right that some do by default. Think of the potential hazard of a multi-threaded webserver This is another dangerous system call for the web environment, and really should be disabled if SAPI!=cgi -Jason - Original Message - From: Jeroen van Wolffelaar [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: PHP Developers Mailing List [EMAIL PROTECTED] Sent: Monday, August 20, 2001 2:01 PM Subject: Re: [PHP-DEV] chroot(): _not_ safe-mode restricted? As I read it in CVS, chroot() will work even in safe-mode. Isn't this a bad idea(tm), or am I wrong? If users can chroot in safe-mode, Apache won't serve any more pages after all children have been chrooted to an empty dir? uhm, where have you read that? [ curious ] I just reasoned what could happen. if you chroot a child, I couldn't see a reason why it'd get respawned (since it doesn't die), but it will become a useless child, I guessed. nope, cause it will run as apache user, and you have to be root to chroot(). I believe there are webservers which are run as root, or not? If that is the case, chroot should be disabled in safe-mode IMHO, or better, disabled in webserver envirment. Currently the docs say that it is not *wise* to use it in webserver-env, not that is impossible. That's why I questioned safe-mode restrictions here. -- teodor Jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: sysvsem extention question
There probably should be a full implementation of semaphores in php. If you
have a need for this, we should discuss exactly how it should be implemented.
I will have some free time available soon, so I can start working on this. Though I
have
a couple other projects as well. If you would be interested in contributing a CVS
account can be arranged. This should probably start as a separate module, and then
eventually replace the sysvsem extension as it is no long being actively maintained.
I have a great desire for php to function well as a standalone scripting language
as well as web, so I am always interested as projects like this.
Is there anyone else who would find this useful?
-Jason
- Original Message -
From: Tom May [EMAIL PROTECTED]
To: Chris Chabot [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Tuesday, August 21, 2001 1:58 PM
Subject: Re: sysvsem extention question
First off, before you get the wrong impression of my answer, let me
say that your observation It all seems kinda kludgy and quick-hack
for a specific project, and not 'sysv semaphores implimented in
php' is right on.
Chris Chabot [EMAIL PROTECTED] writes:
I have been playing with the idea of making some application backend
services using pcntl (for singaling and fork)+ sysvsem's (for
synchronisation).
Cool. But see below.
However while reading thru the sysvsem source code, i noticed the
behaviour of the semaphores in PHP is basicly as a 'lock' (as one would
use a file lock w/ flock()). From what i understand from my advanced
unix programming book, and the linux man pages, this is not what
semaphores are supposed to be (though they can be abused to be so).
The way one would -expect- semaphores to function on a unix platform
is best described in Linux Programmers Guide at
http://uiarchive.uiuc.edu/mirrors/ftp/ftp.ibiblio.org/pub/Linux/docs/linux-doc-project/programmers-guide/lpg-0.4.pdf
(page 46 and on).
A short sumary would be: a semaphore is a resource counter (not an
absolute lock).
A lock is just a degenerate case. A slightly less degenerate case
(that can't be implemented with flock) is when you want to allow N
users of the resource instead of just one.
The main this is that a process other then the process that acquired
the semaphore can decrease the semaphore count, thus releasing it for
another client. Another big difference is that a process can set the
semaphore count lower then zero (0 == locked). This sometimes can be
usefull for Client / Server synchonisation.
Example usage for a typical Client / Server program flow using
semaphores / signals :
I admit I haven't looked at this hard enough to understand all the
details, but could message queues help you out here? You could get
higher throughput since the server fills the buffer and calls msgsnd()
beforehand, whereas in your signalling implementation clients will
stall between the time they signal the server and the time the server
has filled a buffer for them. Also, you need some additional overhead
to manage the buffer handoff from client to server. And doing things
in signal handlers can get dicey.
If a message queue isn't big enough for you, you can pass references
to shared memory in your messages.
Server :
create sem
sem acquire
setup envirioment
fork children
Multiple Clients:
repeat (wait for sem acquire) {
send signal to Server
communicate with server, get 'buffer'
process buffer
}
Server:
while (Fill data into buffer) {
semaphore release (!);
Sleep(infinite or untill time out);
}
- Sleeps untill interupted by signal (signal send by Client/Child)
- In signal handler:
Send 'buffer' to client that acquired semaphore
return;
will cause the program to go back to main loop, sleep was interupted,
so goes to while (fill buffer) again. Also note that the Client -never-
calls semaphore release. The server does that once the resource is
available again.
Rinse and Repeat till end of time, or end of data :-) This will
distribute the data to be processed over all the different clients
(since semaphores guarantee a linear processing of clients, so all
clients get there equal share).
Last, i don't see why the implimentation as exists, requires 3
semaphores.
I don't remember why either. I did that code somewhere around the end
of 1998 . . .
It all seems kinda kludgy and quick-hack for a specific
project, and not 'sysv semaphores implimented in php'. (please forgive
my rude assumptions)
Bingo.
Does the maintainer (Tom May) want to work on this, or anyone else? I'd
be happy to help out, but my last C coding days are over 6 years behind
me, so i don't feel very confident to lead this project.. So any/all
help and/or
Re: [PHP-DEV] Re: Re: sysvsem extention question
- Original Message - From: Chris Chabot [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: Sascha Schumann [EMAIL PROTECTED]; Tom May [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, August 24, 2001 11:30 AM Subject: Re: [PHP-DEV] Re: Re: sysvsem extention question Hey Jason, i do see your point. However, something still illudes me in my reasoning i think.. In a web envirioment, you are most likely to be in one of two situations when using semaphores. - Plain standard lock (with ability of doing resource count) - All web servers connect to a external process that handles a service (like printer) - The web processes them selves are the 'external resource' which handle the decreasing of lock-count The notes in the original source code of the php extention explained that the second+third lock were used for: - Resource count - Be able to set initial max-resource count However, when i follow this reasoning, two things come to mind - Resource count is a API provided by the sysvsem implimentation via semctl (# waiting, etc) - if you try to set the semaphore's resource count, and it fails (other process connected to it and locked it?) then wouldnt it be safe to assume that that 'other process' is another web process, which sets the same resource counters... so we end up with an good situation anyways... So if you would do a semget with IPC_CREATE + IPC_EXCL. If this succeeds, do the SETALL/SETVAL routine via semctl, if it fails on EEXISTS, do a second semget without create+excl and attach to it.. That should work the same as the 3 semaphore method. The thing I wonder is if the module should do this, or if this should be left up to the php programmer. I would suggest getting as close to the C API as possible, with the possibility of adding some easier to use functions. I am starting to think that any other method would be very unflexable. -Jason Donno if it would work, or how-much overhead it would add, but it sounds like it could ;-) -- Chris Jason Greene wrote: - Original Message - From: Sascha Schumann [EMAIL PROTECTED] To: Jason T.Greene [EMAIL PROTECTED] Cc: Tom May [EMAIL PROTECTED]; Chris Chabot [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, August 24, 2001 1:49 AM Subject: Re: [PHP-DEV] Re: Re: sysvsem extention question parent process right before fork. There is no parent initializer for a php module author MINIT() is called from the parent process in forking servers. The mm storage handler uses this hook to instantiate a shared memory segment and propagate the handle to all child processes. Sascha is right... Allow me to reword.. There is no way to allow a php file author the ability to execute php source during module startup of a forking web server. The module would have to allocate and initialize all semaphores before the php source is parsed. This defeats the purpose of a semaphore extension in a forking webserver environment, becuase the php source author would be limited to just the semaphors allocated by the php module. -Jason - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] contribute...
Depends on what you want to do. If you want to start with bug fixes: 1. subscribe to php-dev and php-qa 2. Go through bug db, fix a bug 3. Generate a patch off of latest CVS 4. Email patch to php-dev with [PATCH] in the subject If you are developing new functionality perform steps 3 - 4. After awhile you can request a CVS account. -Jason - Original Message - From: Robin Ericsson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, August 27, 2001 9:52 AM Subject: [PHP-DEV] contribute... Hi, If I want to join the PHP project, and start to contribute code etc, where is a good place to start? Check bugs-database and start fixing bugs? best regards Robin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] ([PATCH] SOCKETS Solaris issues with gcc) socket_read issue with new api
Sterling,
We had spoke in private correspondence several months ago about
Solaris compatibility problems with the sockets extension. This basically
was due to #defines in Solaris's socket header files that rename all socket
functions to __xnet_##function_name ie. __xnet_socket, etc... This
only happens if the compile does not support the redefine_extname pragma.
(The reason for the define hack)
Since you guys have redesigned the API to follow php naming conventions,
this is no longer an issue with function naming. However, the php_socket
structure has a member named socket, which causes compilation problems. I
am sending a simple rename patch that changes this name and all references to
bsd_socket. ( Could be any name of course, just the most appropriate I could
come up with ). I aslo changed the php_read function to take a param of
bsd_socket in place of socket.
While testing I noticed another issue. The new socket_read function returns
the read data instead of taking it as a parameter. This requires me to use the
!== operator to verify there is nothing left to be read. Otherwise data could be
misconstrued as an error.
ie
what once was
while (read($socket, $out,100)){
print $out;
}
is now
while ((out=socket_read($socket, 100)) !== FALSE) {
print $out;
}
This is very cumbersome
The 3rd issue is that the php_read function will return 0 and set errno to 0 on a
partial read. There probably should be a check for errno 0 and not print an error
message in this case. I would have included it in this patch, but I assumed that you
guys might have a better way to solve this problem.
-Jason
===
RCS file: /repository/php4/ext/sockets/sockets.c,v
retrieving revision 1.62
diff -u -r1.62 sockets.c
--- sockets.c 24 Aug 2001 01:21:14 - 1.62
+++ sockets.c 27 Aug 2001 20:46:41 -
@@ -33,9 +33,6 @@
#define _XPG4_2
#define __EXTENSIONS__
-#ifndef __PRAGMA_REDEFINE_EXTNAME
-#define __PRAGMA_REDEFINE_EXTNAME
-#endif
#include ext/standard/info.h
#include php_ini.h
@@ -55,14 +52,14 @@
# include fcntl.h
# include signal.h
# include sys/uio.h
-# define IS_INVALID_SOCKET(a) (a-socket 0)
+# define IS_INVALID_SOCKET(a) (a-bsd_socket 0)
# define set_errno(a) (errno = a)
# define set_h_errno(a) (h_errno = a)
#else /* windows */
# include winsock.h
# include php_sockets.h
# include php_sockets_win.h
-# define IS_INVALID_SOCKET(a) (a-socket == INVALID_SOCKET)
+# define IS_INVALID_SOCKET(a) (a-bsd_socket == INVALID_SOCKET)
#endif
#ifdef ZTS
@@ -199,7 +196,7 @@
{
php_socket *php_sock = (php_socket *) rsrc-ptr;
- close(php_sock-socket);
+ close(php_sock-bsd_socket);
efree(php_sock);
}
@@ -224,7 +221,7 @@
la.sin_family = hp-h_addrtype;
la.sin_port = htons((unsigned short) port);
- php_sock-socket = socket(PF_INET, SOCK_STREAM, 0);
+ php_sock-bsd_socket = socket(PF_INET, SOCK_STREAM, 0);
php_sock-type = PF_INET;
if (IS_INVALID_SOCKET(php_sock)) {
php_error(E_WARNING, Couldn't allocate a new socket from open_listen_sock());
@@ -232,16 +229,16 @@
return NULL;
}
- if (bind(php_sock-socket, (struct sockaddr *)la, sizeof(la)) 0) {
+ if (bind(php_sock-bsd_socket, (struct sockaddr *)la, sizeof(la)) 0) {
php_error(E_WARNING, Couldn't bind socket to given address from
open_listen_sock());
- close(php_sock-socket);
+ close(php_sock-bsd_socket);
efree(php_sock);
return NULL;
}
- if (listen(php_sock-socket, backlog) 0) {
- php_error(E_WARNING, Couldn't listen on socket %d from open_listen_sock(),
php_sock-socket);
- close(php_sock-socket);
+ if (listen(php_sock-bsd_socket, backlog) 0) {
+ php_error(E_WARNING, Couldn't listen on socket %d from open_listen_sock(),
+php_sock-bsd_socket);
+ close(php_sock-bsd_socket);
efree(php_sock);
return NULL;
}
@@ -258,7 +255,7 @@
m = sizeof(*la);
- retval-socket = accept(php_sock-socket, la, m);
+ retval-bsd_socket = accept(php_sock-bsd_socket, la, m);
if (IS_INVALID_SOCKET(retval)) {
php_error(E_WARNING, Couldn't accept incoming connection in accept_connect());
efree(retval);
@@ -269,14 +266,14 @@
}
/* {{{ php_read -- wrapper around read() so that it only reads to a \r or \n. */
-int php_read(int socket, void *buf, int maxlen)
+int php_read(int bsd_socket, void *buf, int maxlen)
{
int m = 0, n = 0;
int no_read = 0;
int nonblock = 0;
char *t = (char *) buf;
- m = fcntl(socket, F_GETFL);
+ m = fcntl(bsd_socket, F_GETFL);
if (m 0) {
return m;
}
@@ -306,7 +303,7 @@
}
if (n maxlen) {
- m = read(socket, (void *) t, 1);
+ m = read(bsd_socket, (void *) t, 1);
}
if (errno != 0 errno != ESPIPE errno != EAGAIN) {
@@ -446,14 +443,14 @@
zend_hash_internal_pointer_reset(Z_ARRVAL_PP(arg2));
while (zend_hash_get_current_data(Z_ARRVAL_PP(arg2), (void**)tmp) == SUCCESS) {
ZEND_FETCH_RESOURCE(php_sock, php_socket*, tmp, -1, le_socket_name, le_socket);
- FD_SET(php_sock-socket, (php_fd-set));
- max_fd = (php_sock-socket max_fd) ?
Re: [PHP-DEV] ([PATCH] SOCKETS Solaris issues with gcc) socket_read issue with new api
Forgot one thing,
Let me know if you would like me to just apply this patch myself.
I just thought it should be reviewed first.
Thanks,
Jason
- Original Message -
From: Jason Greene [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; Chris Vandomelen [EMAIL PROTECTED];
[EMAIL PROTECTED]; Daniel Beulshausen
[EMAIL PROTECTED]
Sent: Monday, August 27, 2001 1:36 PM
Subject: [PHP-DEV] ([PATCH] SOCKETS Solaris issues with gcc) socket_read issue with
new api
Sterling,
We had spoke in private correspondence several months ago about
Solaris compatibility problems with the sockets extension. This basically
was due to #defines in Solaris's socket header files that rename all socket
functions to __xnet_##function_name ie. __xnet_socket, etc... This
only happens if the compile does not support the redefine_extname pragma.
(The reason for the define hack)
Since you guys have redesigned the API to follow php naming conventions,
this is no longer an issue with function naming. However, the php_socket
structure has a member named socket, which causes compilation problems. I
am sending a simple rename patch that changes this name and all references to
bsd_socket. ( Could be any name of course, just the most appropriate I could
come up with ). I aslo changed the php_read function to take a param of
bsd_socket in place of socket.
While testing I noticed another issue. The new socket_read function returns
the read data instead of taking it as a parameter. This requires me to use the
!== operator to verify there is nothing left to be read. Otherwise data could be
misconstrued as an error.
ie
what once was
while (read($socket, $out,100)){
print $out;
}
is now
while ((out=socket_read($socket, 100)) !== FALSE) {
print $out;
}
This is very cumbersome
The 3rd issue is that the php_read function will return 0 and set errno to 0 on a
partial read. There probably should be a check for errno 0 and not print an error
message in this case. I would have included it in this patch, but I assumed that you
guys might have a better way to solve this problem.
-Jason
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] [PATCH] Zend/zend_alloc.c
I disagree with this patch. The scenario of not being able to allocate memory is a
fatal error, and the only appropriate response for php is to exit. If you need other
behavior use pemalloc( which calls malloc if set persistant ).
-Jason
- Original Message -
From: Walter Franzini [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, August 28, 2001 8:50 AM
Subject: [PHP-DEV] [PATCH] Zend/zend_alloc.c
Hi,
is ok to send to this list patch for Zend?
I think _emalloc should not exit if unable to allocate enough memory,
malloc behave differently :-)
the patch below fix also a small problem with the format string.
--- php-4.0.6.ORIG/Zend/zend_alloc.c Tue Jun 19 20:04:53 2001
+++ php-4.0.6/Zend/zend_alloc.c Tue Jul 31 10:32:39 2001
@@ -158,12 +158,11 @@
HANDLE_BLOCK_INTERRUPTIONS();
if (!p) {
- fprintf(stderr,FATAL: emalloc(): Unable to allocate %ld bytes\n, (long) size);
+ fprintf(stderr,FATAL: emalloc(): Unable to allocate %lu bytes\n, (long
unsigned) size);
#if ZEND_DEBUG defined(HAVE_KILL) defined(HAVE_GETPID)
kill(getpid(), SIGSEGV);
-#else
- exit(1);
#endif
+
HANDLE_UNBLOCK_INTERRUPTIONS();
return (void *)p;
}
Ciao
--
Walter Franzini, e-mail: [EMAIL PROTECTED]
SysNet, Via Digione 8, 27100 Pavia - Italy
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Right/Left Shift Zero Fill operator
Good Idea Is there anyone out there who uses on negative numbers? There is the discussion on the engine2 list about whether to make an unsigned right shift, or to introduce a new operator . Speak-up or potential loose your negative shift-ability : ) -Jason - Original Message - From: Andrei Zmievski [EMAIL PROTECTED] To: Andi Gutmans [EMAIL PROTECTED] Cc: Jason T. Greene [EMAIL PROTECTED]; Jason Greene [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, September 07, 2001 8:22 AM Subject: Re: [Zend Engine 2] Right/Left Shift Zero Fill operator On Fri, 07 Sep 2001, Andi Gutmans wrote: I guess the reason for this is because some people in C use 1 to divide by 2. I don't think this has had its uses in PHP and I think we should change it to do an unsigned shift. Maybe you should ask on the php-dev list first.. if anyone uses it for division. -Andrei In this age, which believes that there is a short cut to everything, the greatest lesson to be learned is that the most difficult way is, in the long run, the easiest. -Henry Miller, The Books in My Life -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Right/Left Shift Zero Fill operator
Alexander, Thanks for the input. If you are interested in other language changes subscribe to [EMAIL PROTECTED] Everyone, Well guys we have one person so far who spoke up, and you know what they say for every one there is a hundred : ) Due to the existing users out there I would think the new operator is the way to go. -Jason - Original Message - From: Alexander Wirtz [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Andrei Zmievski [EMAIL PROTECTED]; Andi Gutmans [EMAIL PROTECTED] Sent: Monday, September 10, 2001 9:56 AM Subject: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Right/Left Shift Zero Fill operator -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jason et al., On Monday 10 September 2001 16:24, Jason Greene wrote: Is there anyone out there who uses on negative numbers? There is the discussion on the engine2 list about whether to make an unsigned right shift, or to introduce a new operator . I'd be grateful, if the behaviour of won't change, as I'm using it in some scripts for exactly this purpose. A is the usual unsigned right-shift in c-style languages, it wouldn't hurt to introduce it to PHP as well, would it? Speak-up or potential loose your negative shift-ability Done :) Best Regards, Alex - -- | Alexander Wirtz | eMail: [EMAIL PROTECTED] | | web@ctive GmbH|Accidents, Emergency, Ambulance | -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7nNSEDTqTaMH1weIRAhdBAKCbojb6+0yw1alYGS1tQgydLAcfEQCg24wE ssB1EoyRTzQY2R1jQhAcJDw= =zebw -END PGP SIGNATURE- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Karma Request
Could someone grant me some docs Karma? Thanks, -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PHP pcntl function documentation (and other stuff)
- Original Message - From: Daniel Beckham [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 11:38 PM Subject: Re: PHP pcntl function documentation (and other stuff) - Original Message - From: Jason Greene [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Sent: Thursday, September 13, 2001 6:00 PM Subject: Re: PHP pcntl function documentation (and other stuff) Are you sure you are setting up your signal handlers properly before generating the signal? Every signal has a default action (called SIG_DFL) that differs between signal type(most of the time it aborts the process however). as soon as you call pcntl_signal( SIGKILL, my_signal_catch); Wow.. I'm an idiot. I setup a SIGTERM handler when I first started writing the daemon and totally forgot about it. For whatever reason, in my mind I assumed that the signal handler function that I wrote would just automatically handle all signals. hehe, thanks for the help there. =) I am confused how you would use exec during a SIGHUP. Are you tring to call another php program? Is there any functionality that execve buys you over the standard backticks, system, or exec php function calls? If there are reasons then it would most likely belong in ext/standard I'm actually wanting to execute the currently running program again. It's mostly so I can actually restart my daemon in place without jumping through hoops. (execv will replace the currently runing process with the new process but keep the same pid and any file descriptors that were not set to close on exit.) Right The system and exec (IMHO) are written very badly in PHP and don't even come close to doing what execv will do. They are pretty much the same as using backticks but with a few variations. (Getting the exit code and the last line of output sent by the program.) They just aren't suited to the stuff that's done with fork and execv. Well they are very good at their purpose, which is to take care of all the intricacies of spawning another process. Anyway, it's quite useful when writing daemons that handle the SIGHUP signal. Ah I see. I was assuming you were wanting to execute another program (v)fork() + exec(). Including a plain exec would make sense in pcntl I would suggest: pcntl_exec(string var, array args, array env); The function would then just call execve since all the other execs wrap execve anyways. To tell you the truth I have done absolutely no docs for pcntl, but was planning on it. I just haven't gotten around to it yet. If you would like to help and have time, that would be awesome. I really could use another perspective on them. (the developer is not always the best at explanation) Ok, how about I put together a draft of pcntl_fork, pcntl_wait and pcntl_signal and then we can go from there? I'd like to have something available to the public by the time 4.0.7 is released. Sounds great. I will try and focus as much time as I can on getting docs before the release. -Jason Daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PHP pcntl function documentation (and other stuff)
- Original Message - From: Daniel Beckham [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 14, 2001 1:49 PM Subject: Re: PHP pcntl function documentation (and other stuff) - Original Message - From: Jason Greene [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 14, 2001 11:35 AM Subject: Re: PHP pcntl function documentation (and other stuff) The system and exec (IMHO) are written very badly in PHP and don't even come close to doing what execv will do. They are pretty much the same as using backticks but with a few variations. (Getting the exit code and the last line of output sent by the program.) They just aren't suited to the stuff that's done with fork and execv. Well they are very good at their purpose, which is to take care of all the intricacies of spawning another process. I think that I probably used harsher language then I really meant to when talking about exec and system. My main beef is that exec (and a few other PHP functions) use similar names as their (choose your language) counterparts, but don't make a very good attempt at actually emulating those counterparts. I personally think that exec would always have been better off emulating the exec (3) functions instead. But of course, fork() has been begged for, for eons. Well imagine someone calling exec(3) in a webserver SAPI hehe not good : ) True exec behavior is destructive which is why I agree that pcntl is a good place. The fact that PHP is open source is a blessing and a curse. The blessing is that If you don't like how someone wrote a function like system() or exec() you can just roll your own. The curse is that there end up being three ways to do something and they could probably all be rolled into one for brevity and clarity. Yes it really is quite confusing and a little bit of a mess, but we are still stuck with it for backwards compatibility reasons. Sounds great. I will try and focus as much time as I can on getting docs before the release. Great.. I already have the pcntl_fork and pcntl_waitpid docs done... I'll probably also do the waitpid macros before I send you something. Daniel I took a look at them... Good Job!! As soon as I get my doc karma I can help out. Until then I can add the pcntl_exec function you requested, and I am debating on adding a pcntl_vfork -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PHP pcntl function documentation (and other stuff)
Yes I was debating on whether or not to add that, but I wasn't sure what people were looking for. I was also debating on adding wait3 and wait4. so here are the functions that should be added pcntl_exec() pcntl_wait() pcntl_vfork() pcntl_wait3()??? pcntl_wait4()??? hmm.. maybee they should be combined to a pcntl_wait_rusage() What do you think? -Jason - Original Message - From: Daniel Beckham [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 14, 2001 1:55 PM Subject: Re: PHP pcntl function documentation (and other stuff) One more question. Were you considering adding wait() to the list of functions supported? I know it's very similar as waitpid(), but it is simpler to use unless you are doing something more complex in nature. Daniel -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Doc Karma Request
I hate to be a nag, but when someone gets a change could they add phpdoc to my access list? Thanks, -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Doc Karma Request
Oh, haha thanks I probably should have taken a look at that before asking : ) Sorry Rasmus, -Jason - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Jason Greene [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 14, 2001 5:11 PM Subject: Re: [PHP-DEV] Doc Karma Request Everyone with global php-dev level karma has automatic karma for phpdoc. That includes you. -Rasmus On Fri, 14 Sep 2001, Jason Greene wrote: I hate to be a nag, but when someone gets a change could they add phpdoc to my access list? Thanks, -Jason -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [Zend Engine 2] RE: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity
This easy to understand, efficient (no time consuming code to interpret whether a class was intended), no backwards compatibility issues, no ambiguity, and its not the first 3 symbol operator to hit php. a big +1 -Jason - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Zeev Suraski [EMAIL PROTECTED]; John Parker [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, October 01, 2001 12:16 PM Subject: Re: [Zend Engine 2] RE: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] namespaces ambiguity I think ::: is actually pretty good. We should keep this option open. Andi At 04:36 PM 10/1/2001 +0200, Zeev Suraski wrote: Stupid suggestion, is ::: (three colons) pushing it? Zeev At 16:29 01-10-01, John Parker wrote: '/' is the only operator I can think of that seems to make any sense whatsoever here and is not already used as an operator. I guess you do not divide? :) Zeev Hmm... I'd personally recommend that the namespace operator is ; as no-one ever uses the semi-colon, do they? Sorry, couldn't resist. (I'll smack my wrists on your behalf.) JP. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possibility of moving bugs to another list?
RE: [PHP-DEV] Possibility of moving bugs to another list?by that logic wouldn't email filters fragment discussion as well -Jason - Original Message - From: Robinson, Mike To: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 10:14 AM Subject: RE: [PHP-DEV] Possibility of moving bugs to another list? I disagree. Again. Dev discussion and bug discussion are often intertwined. Separating them would fragment discussion. Email filters are your friend. Mike Robinson IT / Developer - Toronto Star TV Phone: 416.945.8786 Fax: 416.869.4566 Email: [EMAIL PROTECTED] You got it. I'm right there with you. This group get roughly 150 to 200 messages a day. About half of those are Bugzilla messages. I think we could severely imporve the readablity of this group if we seperated the bugs to a PHP-Bugs group. I'm sure most of use wouldn't mind have to two seperate group, because at least then we could tell what we were looking at quickly. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possibility of moving bugs to another list?
Right, To me the bug related emails overshadow the developer threads. I almost want to discuss things on the cvs list just because of this. -Jason - Original Message - From: Chris Gardner To: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 10:23 AM Subject: Re: [PHP-DEV] Possibility of moving bugs to another list? Well, I do have an email filter applied. I do see your point about the discussions being severely related, but if you seperate the two with an email filter anyways, then you're seperating the converastions. If you seperate the group, the conversation about bug could continue on the bug forum, but the general developer threads could get a lot less weakened by other things. Anyways, I'll quite complaining about this now. Chris Gardner Book Systems, Inc. [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Possibility of moving bugs to another list?
haha, good point, well I would ..really I would.. : ) Seriously though, I think it would categorize things a bit better... -Jason - Original Message - From: Andrei Zmievski [EMAIL PROTECTED] To: Chris Gardner [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, October 02, 2001 10:22 AM Subject: Re: [PHP-DEV] Possibility of moving bugs to another list? On Tue, 02 Oct 2001, Chris Gardner wrote: Well, I do have an email filter applied. I do see your point about the discussions being severely related, but if you seperate the two with an email filter anyways, then you're seperating the converastions. If you seperate the group, the conversation about bug could continue on the bug forum, but the general developer threads could get a lot less weakened by other things. Anyways, I'll quite complaining about this now. Nobody would read the bug forum... :) -Andrei * Only 19,999 lines of C++ to my next ski trip... * -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
