Re: [PHP-DEV] comments in php
As it is a compile first, execute later interpreter it will in practice not slow down your code. Of course if your script has only a very small amount of flat code (no loops/function calls) and a huge amount of comments (tens of KB) then it could theoretically make a difference but in reality it doesn't. Andi At 09:05 PM 1/13/2001 +0100, Moritz Petersen wrote: I am wondering, since php is an interpreted language, if it slows down the more comments are inside a sourcecode or not. thanx, mOrP -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Patch that corrects non blocked socket reading on WIN32
I think the code itself should be fixed (with #ifdef or add it to the
socket abstraction). It's dangerous to redefine errno because other code
uses it too.
Andi
At 01:01 PM 1/14/2001 -0800, Christophe Thibault wrote:
I just came across a bug still present in the latest php 4 release. i have
the following script:
$g_ssock=fsockopen($server,$port,$errno,$errstr,30);
socket_set_blocking($g_ssock,0);
while(!feof($g_ssock))
echo fgets($g_ssock,4096);
if you uncomment the socket_set_blocking line it will work fine on win32,
but with non blocking sockets, feof will always return true. by digging
through the code, it appears that fsock.c uses the errno() function for
determining any socket error as seen in function php_sockread_internal:
} else if(nr_bytes == 0 || (nr_bytes 0 errno != EWOULDBLOCK)) {
sock-eof = 1;
}
the problem is that win32 doesn't report socket errors with _errno() but
with WSAGetLastError() so here is my fix:
in fsock.c, line 46, replace:
#ifdef PHP_WIN32
#include winsock.h
#else
with:
#ifdef PHP_WIN32
#include winsock.h
#undef errno
#define errno (WSAGetLastError())
#else
and now it works like a charm :) please submit my patch to the cvs server so
i can benefit of it in the next php releases
bye,
-christophe
--
PHP Development Mailing List http://www.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: mysql_pconnect still broken (was: RE: What does this mean ?)
Looks like this was my bad :)
Sorry,
Andi
At 01:47 AM 1/17/2001 +0200, Zeev Suraski wrote:
Yep, you're right. Fixed.
Thanks,
Zeev
At 23:24 16/1/2001, Steven Roussey wrote:
OK. Look at a quick report. I've just installed php4-200101152345. It runs
with mysql-3.23.27-beta. Apache 1.3.12, Solaris 2.6 (local host) and 2.4
(remote connection).
What I can see is: the offending messages didn't vanish at all (both hosts
are involved):
So, I think it's not fixed yet. Steven, you wrote about 99,8. I suppose
every Apache process here makes this error while ending. I just see it.
:)
Andi, I hope you are reading this.
I looked at the CVS, and my patch was not properly applied. Andi has it
looking through the non-persistant destructors, rather than the persistent
ones (meaning that plist_entry_destructor is identical to
list_entry_destructor).
In file zend_list.c replace the plist_entry_destructor definition with:
void plist_entry_destructor(void *ptr)
{
zend_rsrc_list_entry *le = (zend_rsrc_list_entry *) ptr;
zend_rsrc_list_dtors_entry *ld;
if (zend_hash_index_find(list_destructors, le-type,(void **)
ld)==SUCCESS) {
switch (ld-type) {
case ZEND_RESOURCE_LIST_TYPE_STD:
if (ld-plist_dtor) {
(ld-plist_dtor)(le-ptr);
}
break;
case ZEND_RESOURCE_LIST_TYPE_EX:
if (ld-plist_dtor_ex) {
ld-plist_dtor_ex(le);
}
break;
EMPTY_SWITCH_DEFAULT_CASE()
}
} else {
zend_error(E_WARNING,"Unknown persistent list entry type in
module shutdown (%d)",le-type);
}
}
Sincerely,
Steven Roussey
Network54.com
http://network54.com/?pp=e
--
PHP Development Mailing List http://www.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-DEV] popen() on Win32
Hey, A couple of guys here said they are working on creating a popen() alternative solution for Win32. Any progress? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] popen() on Win32
At 05:27 PM 1/21/2001 +0100, Derick Rethans wrote: Hi, A couple of guys here said they are working on creating a popen() alternative solution for Win32. Any progress? I'm busy with it. I'm making progress indeed. I only have to bring the code into the PHP source now. BUt it looks good. I'll try to finish it this week, but it will be a hack, because I don't understand your V_* macro's quite well. But I assume some devs can assist me with this later on. Great! I can assist you. Ask me questions about the V_*'s and I'll do my best :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Proposal for updating the PDF-extension
At 05:43 PM 1/24/2001 +0200, Jani Taskinen wrote: On Wed, 24 Jan 2001, Uwe Steinmann wrote: On Wed, Jan 24, 2001 at 03:07:09PM +0100, Cynic wrote: confuse folks. and the consensus (at least I got it it's agreed on) is pdf_add_local_link-like names. From the php point of view there should be underscores but the pdflib api doesn't use them except for the one after the 'pdf'. The question is, shall we enforce the php naming or allow the pdflib naming. This API is used in PHP - use the PHP naming. If we start making exceptions we end up having a mess in our hands.. :) There are probably other points which need to be discussed like what a function should return if it fails. Many php functions return false but pdflib's api requires to return -1. Again, we should be consistant within PHP the language. ie. if function fails - RETURN_FALSE. IMO. I agree. PHP doesn't need to map the C API's one-to-one but implement PHP functions in the PHP spirit and in a consistent way. That consistent way is returning false. We've talked about this numerous times. When we implement an extension module for a C library we don't even necessarily need to map the functions one-to-one to PHP but think of what API would be the most useful for PHP programmers allowing them flexibility but staying with it's short development time advantage. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] ooops, i thought it new one but:
Moshe, It's quite difficult to exploit this vulnerability without knowing your servers setup. It is possible, but personally I wouldn't worry too much about it although you should urge your ISP to upgrade to 4.0.4pl1. Andi At 08:07 PM 1/27/2001 +, James Moore wrote: No. the bug was localised after the release of PHP 4.0.4 that is the reason why we released the Security Advisory and PHP 4.0.4pl1 so if you think that your servers could be affected you SHOULD upgrade to PHP 4.0.4pl1. It affects ALL versions of PHP 4 up to PHP 4.0.4, you should read the Advisory carefully and see the corresponding posts on Bugtraq for further information. Security Focus is currently down but check on securityfocus.com next week and read about it. Basically: Issues only affect mod_php4 in apache = The issue that php_value engine off can propagate from virtual host to virtual host can be easy worked around by adding php_value engine on to your DEFAULT server config in httpd.conf. = The second issue where php directives can be set from request to request has questionable real world use but is still a security issue. IIRC you can prevent this to a certain extent by disallowing OPTIONS requests in your httpd.conf Doing the above will not guarantee that your system is safe but it will enable you check the security advisory and then make a decision on whether an upgrade is necessary. James -- James Moore PHP Quality Assurance Team [EMAIL PROTECTED] -Original Message- From: moshe doron [mailto:[EMAIL PROTECTED]] Sent: 27 January 2001 19:30 To: [EMAIL PROTECTED] Subject: [PHP-DEV] ooops, i thought it new one but: in debian, they say this bug affecting also 3pl1, but its not what i fount on php.net. can i be relexed if the servers i using runing 3pl1? -- "Rasmus Lerdorf" [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... pl2? This advisory has been out for over a week and the problem is fixed in 4.0.4pl1 -Rasmus On Sat, 27 Jan 2001, moshe doron wrote: the problem here is, that i have problem to update some servers contains my code coz them not in my ownship, so i just have to test if this bug affected them (if yep i'll temply remove the the file from the server) but no explains. does that subject stay in darken till monday not to give hackers the chance to exploite it during the weekend? btw, ll' there official php4.0.4pl2 on php.net that time? tnx moshe. -- "Rasmus Lerdorf" [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... The reference is right in the link you posted. Just upgrade to the latest version to address it. On Sat, 27 Jan 2001, moshe doron wrote: http://freshmeat.net/news/2001/01/27/980597363.html where can i find any references? tnx moshe. -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.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] popen() on Win32
Reminder! :) Andi At 05:27 PM 1/21/2001 +0100, Derick Rethans wrote: Hi, A couple of guys here said they are working on creating a popen() alternative solution for Win32. Any progress? I'm busy with it. I'm making progress indeed. I only have to bring the code into the PHP source now. BUt it looks good. I'll try to finish it this week, but it will be a hack, because I don't understand your V_* macro's quite well. But I assume some devs can assist me with this later on. Regards, Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] - JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED] H.v. Tussenbroekstraat 1 - 6952 BL Dieren - 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]
Fwd: RE: [PHP-DEV] Bug #8732
Anyone else bump into something like this?
Andi
Subject: RE: [PHP-DEV] Bug #8732
Date: Fri, 2 Feb 2001 13:54:09 +0100
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PHP-DEV] Bug #8732
Thread-Index: AcCG63JZ+YNk1p38Q8COcgf0ren1RwGK6w/Q
From: "Edin Kadribasic" [EMAIL PROTECTED]
To: "Andi Gutmans" [EMAIL PROTECTED]
Hi Andi,
I think that you should have enogh info to fix the problem now. Please
see the two attached messages and let me know if that is enough.
Edin
-Original Message-
From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 25, 2001 5:30 PM
To: Edin Kadribasic
Subject: Re: [PHP-DEV] Bug #8732
Is your /tmp writeable? ls -ld /tmp.
I know it might be an obvious question.
Andi
At 09:55 AM 1/25/2001 +0100, Edin Kadribasic wrote:
I've tried them all. Even '/bin/sh -c "/bin/mkdir /tmp/test"'. It is
very
hard to reproduce, because I have the exact same setup on several 5
machines, and I'm having problems only on one of them.
Server 1: RH 6.1, 2xPIII 550 MHz /* PHP exec functions broken */
Server 2: RH 6.2, 2xPIII 933 MHz
Server 3: RH 6.1, 3xPII 450 MHz
Server 4: RH 6.1, 2XPIII 550 MHz
Server 5: RH 6.1, 1xPIII 550 MHz
The only config change on the machine, was addition of the second
processor.
I'm not exactly sure if the problem begun occuring around the time we
upgraded the machines.
Edin
- Original Message -
From: "Andi Gutmans" [EMAIL PROTECTED]
To: "Edin Kadribasic" [EMAIL PROTECTED]
Sent: Thursday, January 25, 2001 6:35 AM
Subject: Re: [PHP-DEV] Bug #8732
Will it work with full-path? "/bin/mkdir /tmp/test"?
I can try and reproduce this evening (my time). If you can send me
an
Email
reminder that will help :)
Andi
At 03:37 AM 1/25/2001 +0100, Edin Kadribasic wrote:
Sorry for not being more specific, but all those machines are Linux
(RedHat
6.1 6.2). Funny part is the site has not been modified in since
4.0.1pl1,
and all of a sudden decided not to work anymore. Tried with the
latest
release 4.0.4pl1, recompiled apache (used to be 1.3.9), but to no
avail.
Simple system("mkdir /tmp/test", $r) would fail with $r set to -1.
No
errors
or warnings printed.
Edin
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: Edin Kadribasic [EMAIL PROTECTED]; PHP Development (E-mail)
[EMAIL PROTECTED]
Sent: Wednesday, January 24, 2001 7:39 PM
Subject: Re: [PHP-DEV] Bug #8732
Executing external programs right now doesn't work on Windows.
Hopefully this will be fixed soon.
Andi
At 12:14 PM 1/24/2001 +0100, Edin Kadribasic wrote:
I'm experiencing the same probmlem on one of our 5 production
servers.
Exec functions always fail with -1 as the return code. No error
messages
or warnings are displayed. Any suggestion on how to find out
what's
happening?
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail:
[EMAIL PROTECTED]
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Received: from provmail.proventum.dk ([10.0.0.49]) by
asp-exchange.proventum.net with Microsoft SMTPSVC(5.0.2195.1600); Wed, 31
Jan 2001 22:39:37 +0100
Received: by provmail.proventum.dk (Postfix) id 93F6C233BD; Wed, 31 Jan
2001 23:38:49 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
content-class: urn:content-classes:message
Subject: [PHP-DEV] PHP 4.0 Bug #9040: Exec sets return_val to -1 when
compiled with "--enable-sigchild"
Date: Wed, 31 Jan 2001 22:38:35 +0100
Message-ID: [EMAIL PROTECTED]
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PHP-DEV] PHP 4.0 Bug #9040: Exec sets return_val to -1 when
compiled with "--enable-sigchild"
Thread-Index: AcCLzk9KrFtRXMcUTjClvGg8huthcw==
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Operating system: Linux 2.2.17
PHP version: 4.0.3pl1
PHP Bug Type: Program Execution
Bug description: Exec sets return_val to -1 when compiled with
"--enable-sigchild"
I was encouraged to submit this as a bug report...
I acutally compiled the source from Debian's archive, with the latest
security fix (which I think it found in 4.0.4pl1). I was having trouble
with oracle support, so I configured with "--enable-sigchild". That did
not help my problem.
I finally went back to my older oracle libraries, and was able to get
them to work, but left "--enable-sigchild" configured in. Then I
noticed that all of my exec functions were setting return_val (the third
parameter) to -1, indicating an error.
I can include an strace of the problem if needed. I think that the
problem was that there we
Re: [PHP-DEV] wrong implementation of isset()?
At 03:02 AM 2/7/2001 +0100, Cynic wrote:
with all respect to the people who develop the language, I
think this is nonsense:
$rs = mysql_query( 'select x, y, z from foo where ...' ) ;
$x = mysql_fetch_array( $rs , MYSQL_NUM ) ;
var_dump( $x[2] ) ;
var_dump( isset( $x[2] ) ) ;
NULL # well, the column contains null values
bool(false)
But since (almost) everybody else disagrees, I must be missing
something obvious.
BTW, does $x = null really equal to unset( $x ) or does
isset() just get fooled by its value?
unset() removes it from the symbol table and $x = NULL; changes it to be a
NULL value. As far as PHP scripts are concerned it's pretty much the same
thing. There are certain situations where you can't really nuke the
variable but you want to mark it as dead.
In any case, you can always use the === operator to check if something is
really NULL and not false.
if ($x === NULL) {
}
I can't remember off hand all the reasons for isset(NULL) being false but
the main reason is that it makes a lot of sense because what the NULL value
is supposed to mean is that there's no value. Also it allows us to
differentiate between functions returning bool(false) and null values.
Hence also the === operator.
I really think that if your script differentiates between these two cases
you might not be writing it very well.
OK, I know it's a messy Email. I'm on the way to bed but I hope it
clarifies a few things :)
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] FW: [PHP-CVS] cvs: php4 /ext/midgard .cvsignore ChangeLog INSTALL Makefile.in access.c article.c attachment.c calendar.c config.m4 element.c event.c eventmember.c file.c fudge genentry.pl group.c ho
I also tend to think it's kind of strange. It's about 800KB of source code and as far as I understand this is an extension module which will be used by almost no one (and everyone will be forced to dl an extra 800KB (300KB compressed)). Any of the Midgard people on this list? Is there any good reason besides it saving you guys a "cp -r ; ./buildconf" to include it in the main PHP distribution? Andi At 07:15 PM 2/12/2001 +, James Moore wrote: Thought this should really be brought up on Dev list rather than CVS list but personally I dont think that midgard has a place in the main distributions CVS.. maybe im wrong but if we begin to put all full applications in CVS just because they are useful we are going to bloat. Whats the difference between distributing this and distributing Phorum as well?? Perhaps we should move that into the CVS, then oh dont forget phpSHOP and every other project on the http://www.php.net/projects.php page. Perhaps someone can enlighten me?? James http://www.midgard-project.org/topic/165.html Well, that's a nice project, but why does it need to be in the PHP CVS? Just too add to this.. I dont see what place midgard has in PHP CVS, If I go and create a totally separate project which isnt a PHP extension really then can I put it in CVS along with everyone else?? I dont think Midgard has a place here maybe in a separate module or in PEAR (which would be ideal for it) but why main CVS? It just doesnt fit. t -- PHP Development Mailing List http://www.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] Changing implementation of get_meta_tags for 4.0.5
Well maybe we can have a function with another name? or pass an optional second argument? I'm not that sure it's a good thing to break backwards compatibility on this one although I admit not knowing how many people actually use it. My guess is that if it's been in a couple of versions of PHP 4 there are at least a couple of dozen if not more using it. Andi At 11:34 PM 2/13/2001 +0100, Andr Langhorst wrote: This will break backwards compatibility, and I am not really in favor of adding a new param to get_meta_tags in order to include this new functionality, that will just obfuscate the code more than it needs to be. I think we should just change one implementation, to another, better one. I can't imagine that that many people are using this tag often enough to require a huge change in their code. following your description, that function is really broeken (lack of functionality) and thus needs a non-backwards-compatible fix, your fix sounds nice indeed this function is not widespreadly used I guess 2c -- Andr Langhorstt: +49 331 5811560 [EMAIL PROTECTED] m: +49 173 9558736 * PHP Quality Assurance http://qa.php.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]
Re: [PHP-DEV] Compiling under Borland C Builder / No BEGIN_EXTERN_C?
There is no good reason the BEGIN_EXTERN_C() haven't been included. We'd welcome a patch. Check out the other places we do put these to get an idea where they should be. In any case, one thing I've wanted to do for a long time is get PHP to compile with the freeware Borland C++ compiler. However, as it doesn't read .dsp it would have been lots of work. Any chance you can export makefiles from the Builder once things work for you and share them with us? If it works nicely you could be the maintainer :) It would allow people who don't have Visual C++ to compile PHP 4 on Windows. Thanks, Andi At 06:46 PM 2/13/2001 -0500, Bryan Mayland wrote: I've been working on a project which requires me to write a zend extension (http://capnbry.dyndns.org/phpub/), I've been using Visual Studio to do the work so far as this is targeted for the Win32 platform. I recently decided to move to Borland C++ Builder after I got fed up with the VC++ IDE. I had to tweak a couple of things in the header files to get it compiling, but the changes were minor (available upon request). The problem I came into was on the link, unresolved symbol errors on functions exported from php4ts.dll. Digging in I realized that the problem was because /some/ of the names of the functions I was importing (via ZEND_API, PHP_API, etc) were getting mangled because they were not enclosed in the BEGIN_EXTERN_C() / END_EXTERN_C() macros. Is this intentional, or is it just because no one has ever tried to use the headers from inside a .cpp file? Some of the functions of intrest are: main/php_main.h: php_request_startup() ... php_handle_auth_data() ext/standard/php_output.h php_output_startup() .. php_get_output_start_lineno() I've modified the header files to block the __declspec(dllimport) functions with BEGIN / END_EXTERN_C. If there is no reason to *not* have these in, may I submit a patch to allow the headers to be included in C++Builder and other C++ build environments? My C is rusty, so flame me if I'm wrong, Bry -- PHP Development Mailing List http://www.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] Changing implementation of get_meta_tags for 4.0.5
Is the only thing it fixes the multi-line problem? (In such a case I think doing the fix is fine). Also, in your example when you wrote "= NULL" I hope you meant not to define these at all and not making them NULL. It is better (traversal and such). Last but not least, you could send an Email to php-general@ and ask who uses it and how. It will give you an idea if there are lots of people or none. Again, if the only problem you fixed is the multi-line problem then I think people won't get bitten by this. Andi At 01:01 AM 2/14/2001 -0500, Sean R. Bright wrote: Well I certainly don't want to compare it to changes from PHP3 to PHP4, but this really isn't that huge of a change. The only difference is that this time this function will actually work correctly. Its never a Good Thing (tm) to break backwards compatibility but that shouldn't be the only thing reason to not change the implementation. If you guys want it to be another function could someone suggest a name for it? get_meta_tags_ex?? Sean -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 14, 2001 12:41 AM To: Andr Langhorst; [EMAIL PROTECTED]; PHP Development Subject: Re: [PHP-DEV] Changing implementation of get_meta_tags for 4.0.5 Well maybe we can have a function with another name? or pass an optional second argument? I'm not that sure it's a good thing to break backwards compatibility on this one although I admit not knowing how many people actually use it. My guess is that if it's been in a couple of versions of PHP 4 there are at least a couple of dozen if not more using it. Andi At 11:34 PM 2/13/2001 +0100, Andr Langhorst wrote: This will break backwards compatibility, and I am not really in favor of adding a new param to get_meta_tags in order to include this new functionality, that will just obfuscate the code more than it needs to be. I think we should just change one implementation, to another, better one. I can't imagine that that many people are using this tag often enough to require a huge change in their code. following your description, that function is really broeken (lack of functionality) and thus needs a non-backwards-compatible fix, your fix sounds nice indeed this function is not widespreadly used I guess 2c -- Andr Langhorstt: +49 331 5811560 [EMAIL PROTECTED] m: +49 173 9558736 * PHP Quality Assurance http://qa.php.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 Development Mailing List http://www.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] Time for 4.0.5?
At 09:31 AM 2/19/2001 +0100, Sascha Schumann wrote: Hi, what do people think about a PHP 4.0.5 release? We have about 70 change entries in NEWS. Some of the changes are fundamentally needed for some extensions to work correctly or to compile at all. Let me know your thoughts. Our Launchpad (QA) guys have a few fixes to go into the CVS. I think it will be done by the end of the week. So I think March 1st sounds OK for branching off RC1. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] popen() on Win32
I can never remember who said they were mentioning on getting popen() to work on Win32. In any case, if someone's working on it any chance this can make it in for 4.0.5? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] pack()/unpack()
It seems like pack()/unpack() has it's own endianess code instead of using htonl(), htons(). Is there a reason for this? It would be nice to fix this for 4.0.5 because right now if you use pack() on Linux and unpack() on Solaris it doesn't quite work. It seems to me as if fixing this shouldn't be too hard but of course it would be best for the original author (Chris) to dive back into his code :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Renaming fopen-wrappers.[ch] to fopen_wrappers.[ch]
No problem. By the way, any idea how well PHP runs on OS/390? Does it actually work natively? Does it run as an Apache module? Andi At 09:23 PM 2/23/2001 +0100, Sascha Schumann wrote: Background: Apparently, OS/390 cannot handle files containing dashes. Because almost all of our files are using underscores anyway, this step can also be seen as aligning the filenames with our unwritten conventions. If noone objects, I'll rename those files in a couple of hours using a CVS mv, so their history is preserved. - Sascha -- PHP Development Mailing List http://www.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] cvs: Zend / modules.h zend_builtin_functions.c
Hopefully fixed now. Andi At 11:06 PM 2/24/2001 +0100, Sebastian Bergmann wrote: Andi Gutmans wrote: andiSat Feb 24 23:16:58 2001 EDT Modified files: /Zend modules.h zend_builtin_functions.c Log: - Add exports from Daniel Beulshausen cgi_main.c ..\main\php.h(44) : warning C4273: 'first_arg_force_ref' : Inkonsistente DLL-Bindung. dllexport angenommen. ..\main\php.h(45) : warning C4273: 'first_arg_allow_ref' : Inkonsistente DLL-Bindung. dllexport angenommen. ..\main\php.h(46) : warning C4273: 'second_arg_force_ref' : Inkonsistente DLL-Bindung. dllexport angenommen. ..\main\php.h(47) : warning C4273: 'second_arg_allow_ref' : Inkonsistente DLL-Bindung. dllexport angenommen. getopt.c ..\main\php.h(44) : warning C4273: 'first_arg_force_ref' : Inkonsistente DLL-Bindung. dllexport angenommen. ..\main\php.h(45) : warning C4273: 'first_arg_allow_ref' : Inkonsistente DLL-Bindung. dllexport angenommen. ..\main\php.h(46) : warning C4273: 'second_arg_force_ref' : Inkonsistente DLL-Bindung. dllexport angenommen. ..\main\php.h(47) : warning C4273: 'second_arg_allow_ref' : Inkonsistente DLL-Bindung. dllexport angenommen. -- sebastian bergmann e-mail : [EMAIL PROTECTED] homepage : http://www.sebastian-bergmann.de make a gift : http://wishlist.sebastian-bergmann.de measure the usability of your web application - 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]
Re: [PHP-DEV] Re: Japanese PHP
At 08:44 PM 2/25/2001 +, Wez Furlong wrote: Andi Gutmans wrote: Does Japanese actually work in a decent way with PHP? From the zillions of Japanese sites I've seen running it I'd guess it works :) Theres a bunch of extensions that add multibyte support from ftp://night.fminn.nagano.nagano.jp/php4/. Thanks I'll take a peek at those extensions. Andi PHP does work, you just need to be careful of the multibyte charsets, especially in regexps. The GD library is another problem area, but can be worked around using those extensions. -- PHP Development Mailing List http://www.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] ctype function (re?)naming
One of the below IMO. Andi At 10:26 AM 2/26/2001 +0100, Hartmut Holzgraefe wrote: RFC: what should their names be in 4.0.5? ( ) stay with ctype_alpha() ... (X) switch to ctype_isalpha() ... () switch to ctype_isalpha() ... and have ctype_alpha() aliases (X) switch to ctype_is_alpha() ... ( ) switch to ctype_is_alpha() ... and have ctype_alpha() aliases ( ) (fill in your idea here) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 Besuchen Sie uns auf der CeBIT 2001 - in Halle 6 Stand F62/4 -- PHP Development Mailing List http://www.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] SLEEP and MAXEXECUTIONTIME and NAUGHTY modules
At 12:11 PM 2/26/2001 +, Sam Liddicott wrote:
I notice that usleep and sleep both clash on solaris with
Max-execution-time.
1) I notice various modules using sleep:
db, hyperwave, mysql, oci8, satellite
which seems to break max execution time.
Any idea why and where they are using sleep()?
2) Could we not use:
#include unistd.h
#define sleep (n) \
{ struct timeval tv; \
tv.tv_sec=n; \
tv.tv_usec=0; \
select(0,NULL,NULL,NULL,tv); \
}
Where did you see that?
Andi
as well as being more accurate it would not break max-execution-time.
And while we are at it define php_msleep for milliseconds?
--
PHP Development Mailing List http://www.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] SSL socket support (LONG!)
Do you have time to map where in PHP we are currently using socket code? I think according to how many places and how we are using it, it'll help us decide how much redesigning we can do. Also keep Win32 in mind while thinking of this. I didn't have much time but I did read through your RFC quickly. On a whole it looks quite interesting and I'd be quite happy to nuke the SOCK_FGETS() and friends from fopen_wrappers.h and other places. Also try and keep in mind regular files. Maybe we can get rid of the ugly code which is in quite a few places in the source tree which does an if (issock) Messy letter but I hope you get my idea :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] SSL - joining sockets and files
This sounds pretty good. I'll try and look at the code this weekend. Some
of the code is really ugly especially the legacy code.
When you say there are places which need a FILE * do you mean they just
need to check the id and check that it's a FILE * or do they convert
descriptors to FILE * (can't remember if that's possible or not :).
Andi
At 02:12 AM 3/1/2001 +, Wez Furlong wrote:
I've just looked through the code.
The current issock stuff is a bit of a nightmare, but not too much of a
problem.
Most of the codebase seems to be fairly well behaved with FP_FGETS and
friends (apart from the interbase extension, where it does the same thing
as FP_FREAD without using FP_FREAD).
The aim is to reduce three parameters to a single parameter for the FP_
family of macros.
Ideally, it would be nice to do this for php_fopen_wrapper as well, and
have it return the "php_file" abstraction we are proposing. I'm not sure
how well people will like this
in general, but thats why I'm talking about it and not changing the code
right now.
Whenever an extension needs to open a file it also needs to complain if it
can't open it.
All over the code we have the same checks to see if it is a socket or a
file, if it was opened, and if if wasn't complain, but first strip out a
password from the filename/url etc. etc.
A suggestion is this:
typedef struct _php_file {
int file_type; /* bitfield: PHP_FILE_STDIO, PHP_FILE_SOCKET */
int (*write)(php_file *this_ptr, );
int (*read)(php_file *this_ptr,);
int (*open)(php_file *this_ptr,);
int (*close)(php_file *this_ptr,.);
int (*seek)(php_file * this_ptr, ...); /* useful */
} php_file;
php_file * php_fopen_wrapper(char * filename, char * mode,
int options,
char ** opened_path,
int report_error
);
Basically the same as the current implementation except that it returns an
abstraction rather than a bunch of alternatives.
The report error flag will cause the fopen wrapper to display the error
message using the current active function name from the scripting engine,
saving a few lines of code for each call where error reporting is
required, and increasing maintainability.
This is going to break code in 11 files, but that is relatively easy to fix.
Some code requires that we get a FILE * back (the fopen_wrapper_for_zend
is one), and some requires a socket (the code in fsock.c), so we need a
way to get those out of the php_file:
FILE * PHP_FILE_GET_STDIO_FILE(php_file *)
int PHP_FILE_GET_SOCKETD(php_file *)
[the names could be PHPFILEGETSTDIOFILE, but thats a different thread... ;-)]
These could be implemented as macros, provided that all stdio based
abstractions "descend" from a common structure where the FILE * lives at
the same structure offset, and likewise for the socketd versions. In the
common case, there will only be one of each of these types anyway.
I don't think that any of this will have a special impact on win32
platforms (any more than unix), because we are too high level for that.
The only real problem is cleaning up the code to use the php_file
abstraction instead of assuming it's getting a stdio fp back.
Once all this is done, the SSL code could be written as an fopen wrapper.
I'm getting tired, so I may have overlooked something glaringly obvious;
please let me know if
I have, or if you have any other suggestions or improvements.
--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]
Re: [PHP-DEV] SSL - joining sockets and files
Too early in the morning. I just remembered fdopen() :)
Andi
At 07:14 AM 3/1/2001 +0200, Andi Gutmans wrote:
This sounds pretty good. I'll try and look at the code this weekend. Some
of the code is really ugly especially the legacy code.
When you say there are places which need a FILE * do you mean they just
need to check the id and check that it's a FILE * or do they convert
descriptors to FILE * (can't remember if that's possible or not :).
Andi
At 02:12 AM 3/1/2001 +, Wez Furlong wrote:
I've just looked through the code.
The current issock stuff is a bit of a nightmare, but not too much of a
problem.
Most of the codebase seems to be fairly well behaved with FP_FGETS and
friends (apart from the interbase extension, where it does the same thing
as FP_FREAD without using FP_FREAD).
The aim is to reduce three parameters to a single parameter for the FP_
family of macros.
Ideally, it would be nice to do this for php_fopen_wrapper as well, and
have it return the "php_file" abstraction we are proposing. I'm not sure
how well people will like this
in general, but thats why I'm talking about it and not changing the code
right now.
Whenever an extension needs to open a file it also needs to complain if
it can't open it.
All over the code we have the same checks to see if it is a socket or a
file, if it was opened, and if if wasn't complain, but first strip out a
password from the filename/url etc. etc.
A suggestion is this:
typedef struct _php_file {
int file_type; /* bitfield: PHP_FILE_STDIO, PHP_FILE_SOCKET */
int (*write)(php_file *this_ptr, );
int (*read)(php_file *this_ptr,);
int (*open)(php_file *this_ptr,);
int (*close)(php_file *this_ptr,.);
int (*seek)(php_file * this_ptr, ...); /* useful */
} php_file;
php_file * php_fopen_wrapper(char * filename, char * mode,
int options,
char ** opened_path,
int report_error
);
Basically the same as the current implementation except that it returns
an abstraction rather than a bunch of alternatives.
The report error flag will cause the fopen wrapper to display the error
message using the current active function name from the scripting engine,
saving a few lines of code for each call where error reporting is
required, and increasing maintainability.
This is going to break code in 11 files, but that is relatively easy to fix.
Some code requires that we get a FILE * back (the fopen_wrapper_for_zend
is one), and some requires a socket (the code in fsock.c), so we need a
way to get those out of the php_file:
FILE * PHP_FILE_GET_STDIO_FILE(php_file *)
int PHP_FILE_GET_SOCKETD(php_file *)
[the names could be PHPFILEGETSTDIOFILE, but thats a different thread... ;-)]
These could be implemented as macros, provided that all stdio based
abstractions "descend" from a common structure where the FILE * lives at
the same structure offset, and likewise for the socketd versions. In the
common case, there will only be one of each of these types anyway.
I don't think that any of this will have a special impact on win32
platforms (any more than unix), because we are too high level for that.
The only real problem is cleaning up the code to use the php_file
abstraction instead of assuming it's getting a stdio fp back.
Once all this is done, the SSL code could be written as an fopen wrapper.
I'm getting tired, so I may have overlooked something glaringly obvious;
please let me know if
I have, or if you have any other suggestions or improvements.
--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] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming
We're probably best off staying with the status quo and trying to keep a close look at any new modules which make it into the tree and modules which have been added since 4.0.4 (or maybe a small time before). It doesn't make much sense to go back and break old names and it doesn't make lots of sense to create a zillion of aliases.I guess if there are some names which in particular need fixing because they are terrible (there might be some of these) then we should fix them on a per-function basis. I am for uniform names but not if it's at the price of adding a zillion of aliases or at a price of making 50% of people's old scripts not work. I am also very much against compile-time options because I'd expect a script written in PHP and posted on some sites code exchange to work for everybody. Andi At 04:04 AM 3/1/2001 -0700, Zak Greant wrote: Phil wrote: Ron - whose postings I normally agree with :-) - wrote: As do I :) [snip] I know that Zak has been doing some experiments along these lines, but has also been busy on other projects. Any news to report Zak? I now have less hair that I did before starting. ;) Finding sensible consistent names for the function is somewhat of an undertaking. I am still working on it I have been twiddling away with a few ideas and have come to some conclusions. Naming is broken. Points in case: defined, function_exists, isset and class_exists... We should have a set of standard verbs that we use for cases like this. I would like to see something like: function_defined class_defined var[iable]_defined constant_defined We can't agree == No consensus on this issue can be reached. We seem to have several schools of thought on this issue. Here are my bitter, narrow, soft-headed and sarcastic views on them: Deny the existence of a problem :) There is no problem with the function names. So stop yer whining or we'll make you use Damian Conway's Lingua::Romana::Perligata instead of PHP. Well, ok... there may be a problem, but I am not convinced of it. And if there were a problem, we need a better way to fix it than has been yet proposed. Live in eternal fear of backwards compatibility :) -- When issues of function renaming arise, frighten all the little hackers with stories of how the villagers will rise against us if we break backwards compatibility with PHP 2. Refuse to relinquish old C function names :) - At the first sign of any change to the function names, cling tightly to your 'woogie' and begin to cry. They can't make you give up your woogie - why, you;'d rather shave off your beard and give up your suspenders than live life without your woogie. Bite off more than you can chew :) - Attempt to swallow large issues in a single bite and end up choking on your wishful thinking. Core developers stand around you and make bets on what color your face will turn before someone remembers the function name for the Heimlich manuever (is that apply_heimlich_manuever, heim, heimApp, windpipe_clear... or was it set_socket_blocking (FALSE) Expand the scope of the argument :) -- Expand the argument scope until it encompasses almost every aspect of the language. Wonder why everone else looks at you like you are a large cockroach. Hamstring the discussion :) - Ignore the thread til it looks like it is getting somewhere, then unload one crippling message and retreat from the ensuing carnage. Seriously, this is a bugger to resolve! I don't think that there is a hope in hell on getting consensus on this issue. The only solutions I see are: --- Add an extra module that implements sane names. This would be a compile-time option that is disabled by default. Include methods to translate scripts between the two naming scheme. Include tools to make coding easier, including Hartmut's handy function looker-upper widget (basically, if you use an unknown function name, PHP attempts to recommend a proper function name for you to use.) In the off chance that we can get consensus, either: Start a ground up rework of the language for PHP 5. Audit the source code and fix the outstanding gremlins. I suspect that this has about as much chance happening as most of us have of becoming male models. Implement one of the moderate proposals that many of us have already outlined. Fork the codebase - start a variant called H_P_H (Hypertext Preprocessor::Hypocoristic) with sensible names ; )\ In any case, it is 4 in the morning over here and I still have work to do. I hope that this makes some sense. --zak -- PHP Development Mailing List http://www.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] NSAPI Modifications for iPlanet/NES 4.1
Can you please send it as an attachment and I'll apply it. (It would also
be good if someone who is familar with the nsapi extension to take a look
at the patch).
BTW what are MALLOC() and FREE()?
Andi
At 05:14 PM 3/1/2001 -0600, Andrew Johnson wrote:
Someone said they'd commit the following patch to sapi/nsapi/nsapi.c in
CVS for me, but there's been no action from him so I'm posting it here in
the hope that someone else will oblige. Hope it's not too late for the
4.0.5 release. I've tested 4.0.4pl1 with this patch under both NES 3.6
and iPlanet 4.1.
It fixes problems that prevent the NSAPI interface from working due to
Null or empty variables (setting any of the HTTP_SERVER_VARS to an empty
string causes phpinfo() to silently exit prematurely).
- Andrew
--
Every great idea appears crazy to start with.--- nsapi.c.orig Thu Feb 8
17:15:55 2001
+++ nsapi.c Fri Feb 9 14:10:00 2001
@@ -94,15 +94,16 @@
} nsapi_equiv;
static nsapi_equiv nsapi_headers[] = {
- { "CONTENT_LENGTH", "content-length" },
- { "CONTENT_TYPE", "content-type" },
- { "HTTP_ACCEPT","accept" },
+ { "CONTENT_LENGTH", "content-length" },
+ { "CONTENT_TYPE", "content-type" },
+ { "HTTP_ACCEPT","accept" },
{ "HTTP_ACCEPT_ENCODING", "accept-encoding" },
{ "HTTP_ACCEPT_LANGUAGE", "accept-language" },
+ { "HTTP_ACCEPT_CHARSET","accept-charset" },
{ "HTTP_AUTHORIZATION", "authorization" },
- { "HTTP_COOKIE","cookie" },
+ { "HTTP_COOKIE","cookie" },
{ "HTTP_IF_MODIFIED_SINCE", "if-modified-since" },
- { "HTTP_REFERER", "referer" },
+ { "HTTP_REFERER", "referer" },
{ "HTTP_USER_AGENT","user-agent" },
{ "HTTP_USER_DEFINED", "user-defined" }
};
@@ -113,20 +114,22 @@
{ "REQUEST_LINE", "clf-request" },
{ "REQUEST_METHOD", "method" },
{ "SCRIPT_NAME","uri" },
- { "SCRIPT_PROTOCOL","protocol" }
+ { "SERVER_PROTOCOL","protocol" }
};
static size_t nsapi_reqpb_size = sizeof(nsapi_reqpb)/sizeof(nsapi_reqpb[0]);
static nsapi_equiv nsapi_vars[] = {
- { "AUTH_TYPE", "auth-type" },
{ "PATH_INFO", "path-info" },
+ { "PATH_TRANSLATED","path" },
+ { "AUTH_TYPE", "auth-type" },
+ { "CLIENT_CERT","auth-cert" },
{ "REMOTE_USER","auth-user" }
};
static size_t nsapi_vars_size = sizeof(nsapi_vars)/sizeof(nsapi_vars[0]);
static nsapi_equiv nsapi_client[] = {
{ "HTTPS_KEYSIZE", "keysize" },
- { "HTTPS_SECRETSIZE", "secret-keysize" },
+ { "HTTPS_SECRETSIZE", "secret-keysize" },
{ "REMOTE_ADDR","ip" }
};
static size_t nsapi_client_size =
sizeof(nsapi_client)/sizeof(nsapi_client[0]);
@@ -279,47 +282,66 @@
{
nsapi_request_context *rc = (nsapi_request_context
*)SG(server_context);
size_t i;
- char *value = NULL;
+ char *value;
char buf[128];
- *buf = 0;
for (i = 0; i nsapi_reqpb_size; i++) {
- if ((value = pblock_findval(nsapi_reqpb[i].nsapi_eq,
rc-rq-reqpb)) == NULL) {
- value = buf;
+ value = pblock_findval(nsapi_reqpb[i].nsapi_eq,
rc-rq-reqpb);
+ if (value) {
+ php_register_variable( (char
*)nsapi_reqpb[i].env_var, value, track_vars_array ELS_CC PLS_CC );
}
- php_register_variable( (char *)nsapi_reqpb[i].env_var,
value, track_vars_array ELS_CC PLS_CC );
}
for (i = 0; i nsapi_headers_size; i++) {
- if ((value = pblock_findval(nsapi_headers[i].nsapi_eq,
rc-rq-headers)) == NULL) {
- value = buf;
+ value = pblock_findval(nsapi_headers[i].nsapi_eq,
rc-rq-headers);
+ if (value) {
+ php_register_variable( (char
*)nsapi_headers[i].env_var, value, track_vars_array ELS_CC PLS_CC );
}
- php_register_variable( (char *)nsapi_headers[i].env_var,
value, track_vars_array ELS_CC PLS_CC );
}
for (i = 0; i nsapi_vars_size; i++) {
- if ((value = pblock_findval(nsapi_vars[i].nsapi_eq,
rc-rq-vars)) == NULL) {
- value = buf;
+ value = pblock_findval(nsapi_vars[i].nsapi_eq, rc-rq-vars);
+ if (value) {
+ php_register_variable( (char
*)nsapi_vars[i].env_var, value, track_vars_array ELS_CC PLS_CC );
}
- php_register_variable( (char *)nsapi_vars[i].env_var,
value,
Re: [PHP-DEV] NSAPI patch / CVS access
I commited your patch. Andi At 01:26 PM 3/2/2001 +0100, Whitehead Anthony wrote: Hiyas, I just tried to commit the attached patch to the NSAPI module but it seems my CVS write access has expired ;) Here attached is the patch for NSAPI from Andrew Johnson, I've tested it on several UNIX platforms and adjusted it slightly to allow patching of the latest CVS version. If someone wants to commit this for us, or re-enable my CVS account I'd be happy. -Anthony Whitehead Central Data Services Swedish Social Security Ministry -- PHP Development Mailing List http://www.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] NSAPI patch / CVS access
I just reviewed the patch quickly. Are you sure that using MALLOC() for the SG(request_info) variables is OK? Are these all variables which are supposed to be freed by the SAPI module? (I think they are but I don't have time to double check this). If the SAPI module is in charge then it's OK but if it's PHP (SAPI.c) then it probably isn't. Andi At 01:26 PM 3/2/2001 +0100, Whitehead Anthony wrote: Hiyas, I just tried to commit the attached patch to the NSAPI module but it seems my CVS write access has expired ;) Here attached is the patch for NSAPI from Andrew Johnson, I've tested it on several UNIX platforms and adjusted it slightly to allow patching of the latest CVS version. If someone wants to commit this for us, or re-enable my CVS account I'd be happy. -Anthony Whitehead Central Data Services Swedish Social Security Ministry -- PHP Development Mailing List http://www.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: about users of japanese localized php3
At 01:10 AM 3/3/2001 +0900, Rui Hirokawa wrote: Currently, I am working to make some patch for php4/main/php_variables.c to add the encoding translation capability using ext/jstring made by Mr. Tsukada supporting japanese characters handling functions. Great. Interesting to see what you guys can come up with. If your work is extendible to support other languages that have the same problem (there must be others) that would be even better. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] NSAPI patch / CVS access
At 10:29 AM 3/2/2001 -0600, Andrew Johnson wrote: Andi Gutmans wrote: I just reviewed the patch quickly. Are you sure that using MALLOC() for the SG(request_info) variables is OK? I think so. php4_execute() contains nsapi_request_ctor(NSLS_C SLS_CC); retval = nsapi_module_main(NSLS_C SLS_CC); nsapi_request_dtor(NSLS_C SLS_CC); where the _ctor routine does the MALLOC()s and _dtor the FREE()s. OK I just wanted to make sure that you guys checked this. (Appologies for my last unnecessary email Andi, I usually work through my email serially...). Happens to me all the time :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
Can you please resend :) Andi At 11:02 AM 3/6/2001 -0700, Zak Greant wrote: Hello Everyone, Is anyone bold enough to comment on the suggested names besides Phil? I know that you all have opinions... Don't make me use humor again. This time, I'll make fun of people by name (and by reference - I've got to be thorough) grinwink --zak -- PHP Development Mailing List http://www.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] copy of object is not copy PHP4.0.4 serious BUG
There is a problem with deeply places references (often objects) not being
full copy constructed but the reference is copied.
In order to change the behavior we would have to do a deep copy *everytime*
we copy a complex structure. This would be very bad performance wise so
except for thinking about it I don't have a quick answer. You can most
probably code around it (create a $a-clone() function which also copies
the object inside).
Andi
At 07:20 PM 3/6/2001 +0100, Roland wrote:
Hello,
consider following two classes:
class TDynVars
{
var $vars;
function set ($key, $val)
{
$this-vars[$key] = $val;
}
}
class TRequest
{
var $eventData;
function TRequest ()
{
$this-eventData = new TDynVars;
}
}
and two programs, A and B.
program A:
$r1 = new TRequest;
$r1-eventData-vars[0]=1;
$r2 = $r1;
$r2-eventData-vars[0]=2;
print($r1-eventData-vars[0]);
output of program A should be "1" and is "1", it is OK.
program B:
$r1 = new TRequest;
$r1-eventData-set(0,1);
$r2 = $r1;
$r2-eventData-vars[0]=2;
print($r1-eventData-vars[0]);
output of program B should be obviously "1" and is "2", it is NOT OK.
Why $r2 changes data of $r1 if $r2 is $r1's copy by value not reference?
Why this faulty behaviour is dependent on indirect access using member
function use instead of direct acces?
Note: The program B on PHP3.0.8 runs correctly, but not on PHP4.0.4.
Thank you for solving this fundamental problem.
Roland Divin
--
PHP Development Mailing List http://www.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: [PHP-QA] ctype function (re?)naming
For starters (too long of a list and not that easy to decide on each and everyone of them) I'll give you what I can think of :) I started making a list of what looks OK to me but it became too long so I'll just mention what isn't OK in my opinion. Consider me pretty much pro all the other changes. In any case, I think what's important is not just putting underscores but changing the function names to reflect more what they do *even* if the names don't end up being exactly like their C api functions. I am for the socket_* change but this is maybe the exception to my previous sentence where I think we should keep stronger similarity (see 4)). 1) I'm for keeping get_all_headers() the way it is. 2) Things like gmp_clrbit should probably change to gmp_clear_bit and not gmp_clr_bit. Same goes for the rest of gmp_*. 3) Why change the imap ones to not include underscores? Looks as if you did the reverse here :) 4) If we decide to keep the socket functions like their C counterparts then I'd change the following two on your list: getsockname - socket_getsockname() and not socket_get_name() getsockopt - socket_getsockopt() and not socket_get_opt() 5) I think define() and defined() are OK as they are on the language level. 6) I think create_function() is OK. There was a long thread which decided upon this name. Same for function_exists(). That's pretty much it. I'll let you guys know if something else pops up. Interesting to see what others think. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] object-method() chaining
Hi, We are aware of this limitation. I am trying to think of a good way to solve this and it isn't trivial. I'll try and come up with something. Andi At 02:41 PM 3/6/2001 -0600, The Doctor What wrote: I'm currently working on the DB project from h*ll. Why? Because a lot of the tables of the normalized DB are mapped into objects and PHP's object support questionable at best. I've worked around the lack of multiple inheritance, and some of the other problems. But the inability to do something as simple as: object-MethodThatReturnsAnotherObject()-method() is very troublesome I cannot express how error prone it is to have to create tons of temporary variables. I can already hear people saying stuff like: "Why don't you use the attribute (or variable) directly?" Because in most cases MethodThatReturnsAnotherObject() does work before it hands me the object, and it's important to my project. If someone has a good example of an object framework around a normalized database, I'd love to see it. Otherwise, can someone tell me where in the flipping PHP4 code is this limitation coded? Dislaimer: I'm irrate. This problem has been grating against me for 4 weeks straight now. I have a bug entered into the bug database: http://bugs.php.net/bugs.php?id=7515 I'd be happy to fix it if someone can point me to the right place. Ciao! -- installs Windows NT!" Orlando (on Slashdot) The Doctor What: "What, Doctor What" http://docwhat.gerf.org/ [EMAIL PROTECTED] KF6VNC -- PHP Development Mailing List http://www.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: [PHP-QA] ctype function (re?)naming
At 05:05 PM 3/6/2001 -0700, Zak Greant wrote: Andi wrote: [snip] I don't have any complaints or helpful comments on what was above this. 3) Why change the imap ones to not include underscores? Looks as if you did the reverse here :) Removing the underscores was the choice that meant the least amount of change for the extension. :) I think it's a wrong choice. If we're moving to a standard system which puts underscores in key places of the name, we shouldn't remove them from imap. Thanks, Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
At 05:26 PM 3/6/2001 -0700, Zak Greant wrote: Derick Rethans wrote: [snip] 6) I think create_function() is OK. There was a long thread which decided upon this name. Same for function_exists(). Can't we call it lambda()? =) That would make a sensible alias for it. :) Nah no aliasing to this :) This issue was closed a long time ago. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
At 05:43 PM 3/6/2001 -0700, Zak Greant wrote: Sterling wrote: Overall I think this is very good. I have a few problems with it (all prefixed with a large IMHO :)... :) array_multisort - array_multi_sort nah, doesn't sound as good as array_multisort, multisort should be a single word... Its a type of sorting method, shouldn't be two different words After looking at this one again, I agree with you. BZ2 (Added 4.0.4) bzclose - bz_close bzcompress - bz_compress bzdecompress - bz_decompress bzerrno - bz_errno bzerror - bz_error bzerrstr - bz_errstr bzflush - bz_flsuh bzopen - bz_open bzread - bz_read bzwrite - bz_write Why leave the bcmatch functions alone, but change these? Because they are brand spanking new and we can make the follow the naming convention before everyone starts using them. Yep. Let's start doing some damage. bzip2 is a very good victim. The reason they're named this way is also to keep compatibility with the zlib functions. Good point - perhaps a better solution would be to have compression library that uses switches to choose between bzip and gzip? It would be easy to bolt on other compression methods without having to do much additional documentation, etc... You could write a PEAR script for this but I don't think it has anything to do with our current discussion :) EXIF read_exif_data exif_read_data? Yep - we should fix this... Yep. GMP (not in manual yet) gmp_abs gmp_add gmp_and gmp_clrbit - gmp_clr_bit ? this_seems_a_little_long_gmp_clrbit_i_think_might_be_better. I prefer Andi's gmp_clear_bit hmm, so do I. Strange :) gmp_hamdist - gmp_ham_dist ? hamdist is I believe an abbreviation for an algorithm, and a single "concept" therefore it should be kept together. Ah - I was not sure, hence the ? gmp_sqrt - gmp_sqrt_rem why that? Good catch :) readgzfile gzreadfile? Good catch :) IISFUNC (Not in manual yet) iis_addserver - iis_add_server iis_getdirsecurity - iis_get_dir_security iis_getscriptmap - iis_get_script_map iis_getserverbycomment - iis_get_server_by_comment iis_getserverbypath - iis_get_server_by_path iis_getserverright - iis_get_server_right iis_getservicestate - iis_get_service_state iis_removeserver - iis_remove_server iis_setappsettings - iis_set_app_settings iis_setdirsecurity - iis_set_dir_security iis_setscriptmap - iis_set_script_map iis_setserverright - iis_set_server_right iis_startserver - iis_start_server iis_startservice - iis_start_service iis_stopserver - iis_stop_server iis_stopservice - iis_stop_service hrrm. these names seem long, perhaps we can shorten them? I think that they are quite readable now - shortening them would probably reduce this. I agree. msql_regcase - msql_reg_case i like msql_regcase better, we shouldn't be using (IMHO prefixing all of these comments, of course) underscores to seperate words per-s, but rather to seperate concepts. ...hmmm... considering that the legibility of this can't easily be fixed with a change to the function name (unless we want to use msql_regex_case_insensitive :) - either way is fine with me. SABLOT xslt_closelog - xslt_close_log let's leave these (openlog, closelog). Because they match openlog and close log - or is this how sablotron describes these features? xslt_create xslt_errno xslt_error xslt_fetch_result xslt_free xslt_openlog - xslt_open_log xslt_output_begintransform - xslt_output_begin_transform xslt_output_endtransform - xslt_output_end_transform too long :) What about something like xslt_output_begin_trans ? I think having an extra for characters which really help understand the meaning of the function is worth it. There for I would go with Zak's recommendation. ZEND (All of the Zend changes are wishful thinking! :) class_exists crash create_function - func_create (or function_create) define - constant_define defined - constant_defined each error_reporting func_get_arg (or function_get_arg) func_get_args (or function_get_args) func_num_args (or function_num_args) function_exists - func_exists (or function_exists) get_class get_class_methods get_class_vars get_declared_classes get_defined_functions get_defined_vars get_included_files get_object_vars get_parent_class get_required_files get_resource_type is_subclass_of leak method_exists restore_error_handler - error_restore_handler set_error_handler - error_set_handler strcasecmp strcmp strlen strncasecmp strncmp trigger_error - error_trigger user_error zend_version Please, NO! ;-))) Seriously though, I think the Zend names are fine as they are... This seems to be the general consensus so far. (Leaving the functions along that is...) ZZIPLIB zzip_close zzip_closedir -
[PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
At 11:28 PM 3/6/2001 -0700, Zak Greant wrote: Andi wrote: At 05:05 PM 3/6/2001 -0700, Zak Greant wrote: Andi wrote: [snip] I don't have any complaints or helpful comments on what was above this. 3) Why change the imap ones to not include underscores? Looks as if you did the reverse here :) Removing the underscores was the choice that meant the least amount of change for the extension. :) I think it's a wrong choice. If we're moving to a standard system which puts underscores in key places of the name, we shouldn't remove them from imap. I certainly don't have *any* problems adding underscores. :) Removing the underscores was my best attempt to be moderate. If we can get agreement on moving imap towards the naming convention, then I am more than happy to go along! I think the Status Quo is better than removing them. So we should decide to either fix them or to leave them the way they are. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
At 11:07 AM 3/7/2001 +0100, Hellekin O. Wolf wrote: At 23:48 06/03/2001 -0700, Zak Greant wrote: Andi wrote: [snip] Yep. Let's start doing some damage. bzip2 is a very good victim. bzclose - bz_close bzcompress - bz_compress bzdecompress - bz_decompress bzerrno - bz_errno bzerror - bz_error bzerrstr - bz_errstr bzflush - bz_flush bzopen - bz_open bzread - bz_read bzwrite - bz_write Can anyone see a problem with the proposed name changes? *** What is the difference between error ad errstr ? Maybe errstr should be changed to errmsg ? (Did I say that elsewhere ? ;-) As the file extension is .bz2, maybe the prefix should be bz2_ as well (it's an algorithm, not a version right ?) How about error_message or error_string? Comparing Gzip and Bzip2 functions : bz_closegz_close bz_compress gz_compress bz_decompress gz_uncompress -- Something must be done here. bz_errno- bz_error- bz_errstr - bz_flush? bz_open gz_open bz_read gz_read bz_writegz_write, gz_puts - gz_eof - gz_file - gz_getc - gz_gets - gz_getss - gz_passthru - gz_rewind - gz_seek - gz_tell - gz_readfile hellekin -- PHP Development Mailing List http://www.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-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
At 04:34 PM 3/7/2001 +0100, Hellekin O. Wolf wrote: At 17:22 07/03/2001 +0200, Andi Gutmans wrote: *** What is the difference between error ad errstr ? Maybe errstr should be changed to errmsg ? (Did I say that elsewhere ? ;-) As the file extension is .bz2, maybe the prefix should be bz2_ as well (it's an algorithm, not a version right ?) How about error_message or error_string? *** Well, errmsg/errstr are everywhere else, be it in PHP or C. errno would take the lifting also... We would end with function names like : mysql_error_number() mysql_error_string() Looks great regarding paragraph formatting but wastes lots of keystrokes ;-) It's always better to write a few extra characters if it makes your code much more readable. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
At 10:20 AM 3/7/2001 -0700, Zak Greant wrote: Andi wrote: At 04:34 PM 3/7/2001 +0100, Hellekin O. Wolf wrote: At 17:22 07/03/2001 +0200, Andi Gutmans wrote: *** What is the difference between error ad errstr ? bzerror returns an array containing the error string and error number. Maybe it should be error_info() then? Maybe errstr should be changed to errmsg ? (Did I say that elsewhere ? ;-) As the file extension is .bz2, maybe the prefix should be bz2_ as well (it's an algorithm, not a version right ?) bz2_ vs. bz_ ... this is a coin-toss decision. We might run into an extension in the future where bz is a good choice for the name, thought I feel it is unlikely. Personally, I don't *really* care - if it came to a heated discussion and a vote, I would go for bz2_... - just so that the no one could tell us "I told you so..." in the future. ;) Why not bzip2_? How about error_message or error_string? *** Well, errmsg/errstr are everywhere else, be it in PHP or C. errno would take the lifting also... We would end with function names like : mysql_error_number() mysql_error_string() Looks great regarding paragraph formatting but wastes lots of keystrokes ;-) It's always better to write a few extra characters if it makes your code much more readable. Agreed. We could try to save a bit of space doing /error/err/ or /string/str/ or /number/num/. Where do we draw the line on length/convenience vs. readability? It's very hard to draw the line but I tend to be in favor of readability vs. how many characters you need to type. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] ctype function (re?)naming
At 02:20 PM 3/8/2001 +0100, Hellekin O. Wolf wrote: At 22:33 07/03/2001 +0200, Andi Gutmans wrote: Why not bzip2_? *** Well, if bzip2_, then gzip_ ! If gz_ then bz_ or bz2_. Am I wrong or too fastidious ? No, because gz_ has existed for a long time. If we'd give it a name today we'd probably call it gzip_* but it's too late. We can do the right thing for bzip2. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: popen() spans 100 processes
I'm not quite sure if it is related but in general popen() doesn't work on
non-console PHP under windows. I think your CGI is running without a
console and the same happens with ISAPI.
Someone is working on fixing this Windows issue but no results yet.
Andi
At 07:20 AM 3/9/2001 +0100, Andr Langhorst wrote:
Encountered 100 spanned cmd.exe + php.exe using win32 CGI, this does not
happen using apachemod, my task manager was open by accident, otherwise I
would not have noticed this...
?php
popen('php -v','r');
?
andr
--
Andr Langhorstt: +49 331 5811560
[EMAIL PROTECTED] m: +49 173 9558736
* PHP Quality Assurance http://qa.php.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-DEV] Re: Static vars in methods
Yeah, it's supposed to be this way. We copied C++.
Andi
At 10:50 AM 3/9/2001 -0600, Andrei Zmievski wrote:
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-DEV] Re: Static vars in methods
By the way, if you need something that works you can just add the following line in your constructor: $this-mystatic = $GLOBALS["__myclass_mystatic"]; Then use $this-mystatic in all of your methods. It's not built-in but it should work pretty nicely. Andi At 11:02 AM 3/9/2001 -0600, Andrei Zmievski wrote: On Fri, 09 Mar 2001, Andi Gutmans wrote: We need to think of static class variables. I don't think it's very easy to do this in a way which wouldn't cause a general performance loss but I'll put on my thinking cap. Ok, I was gonna try to hack it in myself, but you are obviously more qualified to do it. -Andrei "Claiming Java is easier than C++ is like saying that K2 is shorter than Everest." -- Larry O'Brien (editor, Software Development) -- PHP Development Mailing List http://www.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: static call bugs?
At 12:56 AM 3/10/2001 +0100, Andr Langhorst wrote:
Hi,
1) I am currently completing the php documentation to cover all
undocumented features and I have noticed that using a static method call
to the same class from on instanciated object exhibits the presence of the
instance within the static call
There are no static functions in PHP. This syntax is used to call a method
of the parent. It can be used to call other methods and thus have the wrong
$this but I wouldn't document it.
In general, I think it's a bad idea to document undocumented features
because some of them aren't meant for people to use. The behavior might
change in the future.
Best if you make a list of the things you want to document and we'll tell
you if they are a side-effect, a feature for backwards compatibility but
people shouldn't use it anymore or valid behavior.
2) If you uncomment the marked line, you will get an error without any
reason...
I'll look at this tomorrow. Don't have time right now.
Andi
I guess these are bugs, aren't they?
?php
class foo {
function moo() {
// $this-boo=2; // try to remove the comments
print '$this is ';
if (!isset($this)) {
print 'not set';
foo::zoo();
} else {
print 'set';
$this-zoo();
foo::zoo();
}
}
function zoo() {
print 'br'.'I have been called '.(!isset($this) ?
'statically':'via $this-zoo()');
var_dump($this);
}
}
$s=new foo();
$s-moo();
?BR?php
foo::moo();
?
andr
--
Andr Langhorstt: +49 331 5811560
[EMAIL PROTECTED] m: +49 173 9558736
* PHP Quality Assurance http://qa.php.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]
Re: [PHP-DEV] Re: static call bugs?
At 01:30 AM 3/10/2001 +0100, Andr Langhorst wrote: There are no static functions in PHP. This syntax is used to call a method of the parent. It can be used to call other methods and thus have parent::foo(); If you remember, it has been implemented *after* [classname]::[functionname]() ... I still don't understand what the problem is? What should be documented is the right way to use these calls. the wrong $this but I wouldn't document it. can't this be fixed, otherwise if I start documenting :: (however you want to call it), I cannot leave it out and since PEAR uses it heavily it has to be documented PEAR relies on the $this being correct even when you call a method which is not in the current class or in one of its parent classes? In general, I think it's a bad idea to document undocumented features because some of them aren't meant for people to use. The behavior might change in the future. it's just three features "references inside constructor" (already commited), :: (the magical operator ;) ) and php_ticks Where can I see the documentation? (Any chance you can send it here to save me the time? :). We just need to be sure we don't document things which aren't necessarily supposed to work. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: static call bugs?
At 08:49 PM 3/10/2001 +0100, Andr Langhorst wrote:
When you say that people shouldn't use references because of performance
what do you mean? I think you are right in general but when you are
passing around objects you should use references. for example:
function foo($obj)
{
}
foo($myobject);
I know, what about addming some words on reference counting to the docs (I
know it was on the inital zend.com site around release of php 4), this is
very important to understand how to tweak performance.
I have seen many people doing the contrary coming from c++ etc.
Good idea. I don't have time in the next few days to work on it but maybe
I'll be able to steal some stuff from my Zend.com article.
Andi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend_API.c zend_API.h
I commited a patch but didn't test it. Andrei, please make sure I don't have some dumb bug there. Andi At 10:12 AM 3/12/2001 -0600, 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? -Jason - Original Message - From: "Andrei Zmievski" [EMAIL PROTECTED] To: "Zeev Suraski" [EMAIL PROTECTED] Cc: "php-dev mailinglist" [EMAIL PROTECTED] Sent: Monday, March 12, 2001 9:09 AM Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend_API.c zend_API.h On Mon, 12 Mar 2001, Zeev Suraski wrote: No, it's really inaccessible :) We managed to write the engine without needing it... Is it impossible to replace it with other functions? How do you sprintf to buffer of fixed size without possible overflow? I suppose I could use strlcat() to build the string piece by piece. Is that available in the engine? -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] -- PHP Development Mailing List http://www.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
Because snprintf() sucks and what we did is faster :) Andi At 09:25 AM 3/12/2001 -0800, Shane Caraveo wrote: Why not add a: #define snprintf _snprintf to the zend_config.w32.h file? That should take care of the mentioned compile problem under windows. - Original Message - From: "Andrei Zmievski" [EMAIL PROTECTED] To: "Zeev Suraski" [EMAIL PROTECTED] Cc: "php-dev mailinglist" [EMAIL PROTECTED] Sent: Monday, March 12, 2001 6:09 AM Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend_API.c zend_API.h Use zend_snprintf() instead or what? On Mon, 12 Mar 2001, Zeev Suraski wrote: snprintf() isn't accessible in the Zend engine... Zeev At 08:43 12/3/2001, Sebastian Bergmann wrote: Andrei Zmievski wrote: andrei Mon Mar 12 05:08:29 2001 EDT Modified files: /Zend zend_API.c zend_API.h Log: Improve zend_is_callable() to the point where it's actually useful. Now it just needs to be invoked everywhere in PHP where a callback is expected. This breaks the Win32 build: zend_API.c D:\Programme\MS Visual Studio\Projekte\php\php4\Zend\zend_API.c(958) : warning C4013: 'snprintf' undefiniert; Annahme: extern mit Rueckgabetyp int ZendTS.lib(zend_API.obj) : error LNK2001: Nichtaufgeloestes externes Symbol _snprintf ..\Release_TS_inline\php4ts.dll : fatal error LNK1120: 1 unaufgeloeste externe Verweise -- sebastian bergmann e-mail : [EMAIL PROTECTED] homepage : http://www.sebastian-bergmann.de make a gift : http://wishlist.sebastian-bergmann.de measure the usability of your web application - 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] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -Andrei Any sufficiently advanced bug is indistinguishable from a feature. -- Rich Kulawiec -- PHP Development Mailing List http://www.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] whats the standard for OO builtin_functions?
If it's not an alias I think you probably want PHP_FE(member_function,
NULL) and use PHP_FUNCTION(member_function) in the function decleration.
Andi
At 12:06 PM 3/12/2001 -0600, Jason Greene wrote:
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 Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
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-DEV] Re: Memory corruption in Zend, should we allow this?
I tried the following (command line):
?
$foobar-rfoo=$a;
$foobar-r2foo=$foobar-rfoo;
$foobar-rfoo=4;
print $a;
and it didn't crash.
Are you sure this reproduces a crash for you? On which platform? And any
other information you can give us.
Andi
At 03:27 AM 3/15/2001 +0100, Andr Langhorst wrote:
Hi have found an interesting behaviour, watch below...
1)
$foobar-rfoo=$a;
$foobar-r2foo=$foobar-rfoo;
$foobar-rfoo=4;
What are we assigning 4 here to? The first question is, should we allow
this? I think no, references to non-existing variables should be
disallowed (although Zend allows a lot, this is no good).
This is not even a reference to a variable, which could have been
magically created, named ${''} or another undefined variable, let's say $b...
2)
I tried to simply do a
echo $a;
afterwards and wow!!! It works, sometimes! Intermittently PHP crashes,
without reasons, in this case I put this code below by accident
function strlens($string){ return $string; }
ob_start('strlens');
echo 'PRE';
var_dump($foobar);
echo '/PRE';
ob_end_flush();
I do not know what this crash relates to what made me assuming Zend
randomly corrupted some memory using this undefined behaviour? If I put a
die() below the echo it works in any case...
+1 disallowing this or modifying behaviour that it does nothing or
anything else but referencing to nirvana
andr
--
Andr Langhorstt: +49 331 5811560
[EMAIL PROTECTED] m: +49 173 9558736
* PHP Quality Assurance http://qa.php.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-DEV] Re: [PHP-QA] RE: [PHP-DEV] 4.0.5RC1
At 04:03 PM 3/13/2001 -0800, Lon Baker wrote: 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. Seems like we need "\r\n" in there. The question is, can we detect OS X easily and can we change the scripts which build internal_functions.c accordingly. We might need Sascha on this one. He wrote those scripts. 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. I don't think this is a show stopper. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] QA: chunked output buffering does not work on win32 + internal function output callbacks
This is extremely reproducible. Definitely a show stopper until Zeev fixes
this one.
Andi
At 01:38 AM 3/14/2001 +0100, Andr Langhorst wrote:
Hi Zeev,
chunked output buffering seems to work on Linux. Unfortunately several
things do not work (anymore) on win32 (tested CGI):
1)
Using ob_start([internal_function]) eg. strlen(),nl2br()etc. yield in
no-output, while using a simple user-land wrapper works.
2) this crashes:
function strlens($string){
return $string; }
ob_start('strlens');
echo str_repeat('test',5500);
ob_end_flush();
3) for all specified values for chunked output buffering the buffer grew
up to 10x of its original size (tested with user-land strlen wrapper)
several values
for several values it crashed immediately (eg.2)
andr
--
Andr Langhorstt: +49 331 5811560
[EMAIL PROTECTED] m: +49 173 9558736
* PHP Quality Assurance http://qa.php.net *
--
PHP Quality Assurance Mailing List http://www.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] Getting Started with new module
I'm not too familiar with Tuxedo but the first step would be for you to actually write a PHP module which interfaces with Tuxedo. Once you're done with it/tested it and you feel it's worth putting into PHP we can open you a CVS account. I don't think there are many people who will need this kind of module but I might be wrong. In any case, once we create a repository for modules which live outside the PHP CVS we could then move it there. Andi At 08:29 PM 3/18/2001 -0600, Brian Foddy wrote: Some months back I inquired about writing a BEA Tuxedo module for PHP. I got side-tracked for a while, but now I'd like to resume exploring this possibility. Primarily, because I'd like to use this module myself, but also feel it would be a natural match to an environment like PHP on a web server. First obvious question is is anyone working on a Tuxedo hook? If not, I'd like to volunteer. For those not familiar with Tuxedo, its a high-end transaction middleware Client/Server environment used in many larger corporate environments. Reference http://www.beasys.com/products/tuxedo/index.shtml for a good starting point. My thoughts are that PHP should have the ability to be a Tuxedo client, so it can call Tux services elsewhere in a Tux environment. These services can be located on the same machine, one other machine, numerous other machines, even mainframes. Ideally, all seemlessly called. It would call services in much the same way PHP calls a service from a database. I would only propose a web/PHP server be a client to Tuxedo. I can't imagine how a Tux server would even technically be incorporated into PHP. So, where to start??? I've looked through some of the code for other external modules. Sybase_ct for instance which is another environment I'm familiar with. Tuxedo has numerous API calls, but most of them aren't used for clients, so I don't think there would be many new functions. A basic Tux client can be written with as few as 6 API functions. It does require some similar connection concepts as databases, and also has its own memory allocation / free functions (tpalloc, tpfree). My personal resume includes 8+ years of UNIX, C, and database development mostly on Solaris, Linux, Sybase, and Informix. I feel I should be technically able to complete this type of project. I've read the apidoc.txt and apidoc-zend.txt files, but seems there are still some holes. Can anyone suggest the best way to get started? Much appreciated, Brian Foddy [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] feature request
It should be possible to do this. I'll look into it. But I also need to think about how much sense it makes :) Today you're asking for isset(...,...,...). Tomorrow you will ask to know which one was not set if it failed. So I hope what youreally want is only the first. Andi At 09:42 PM 3/18/2001 -0500, Mike Robinson wrote: Chris Newbill writes: This would not be a bad idea IMHO and I would use it for some things. The functionality would be inclusive not exclusive. So isset($var1, $var2, $var3) would only return true if $var1, $var2, and $var3 are set and false otherwise. So If I had a form passing $name, $email, $phone: example #1 if (isSet($name, $email, $phone)) // ALL GOOD Instead of example #2 if ((isSet($name)) (isSet($email)) (isSet($phone))) // ALL GOOD Granted if one variable wasn't set, then you might run into some minor issues if you want to figure out which one is not set. But that is the developers choice. :) It wouldn't break existing functionality, seems simple enough to implement (although my karma is limited to doc's so someone else would have to do it), and would make some people happy. That seems to be reason enough to do it. Just my 2 cents. Ditto. It would be handy. If you are willing and able to do stuff like this, maybe a request for additional karma would be in order. Mike Robinson -- PHP Development Mailing List http://www.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
:)
Andi
At 08:25 AM 3/19/2001 -0700, Chris Newbill wrote:
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.
-Chris
-Original Message-
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: Monday, 19 March, 2001 7-04 aM
To: Phil Driscoll
Cc: Chris Newbill; Andi Gutmans; PHP DEV
Subject: Re: [PHP-DEV] feature request
Phil is right. The only thing that may be both useful and
practical would
be isset() on multiple variables, returning either true or false.
Zeev
At 11:31 19/3/2001, Phil Driscoll wrote:
$a = 1;
$b = 2;
$d = 4;
$play_nice = isSet($a, $b, $c, $d);
if (!$play_nice) {
print "The variable missing is in position ";
print ($play_nice*-1);
}
And it would print 3, in which case we would know $c is not
set. I'm not
that sure about this approach, seems like a hack,
It is a hack - what if $a AND $c were unset. You really need to return an
arbitrary length bitfield, with one bit for each arg. Then the
sensible name
for the function would be isunset!
That said, I think the whole idea is bad. I appreciate the
reduced number of
keypresses involved, but I don't think that this is a feature
you can apply
orthogonally to the rest of the language without serious
repercussions, and
therefore it would not posses the desirable attribute that you
would be able
to guess that isset worked this way.
Hence my vote:
(X) don't make sweeping changes to language functionality without fully
considering the repercussions.
Cheers
--
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]
--
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]
--
PHP Development Mailing List http://www.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
isset($var1, $var2,...) is in the CVS now.
If everyone is happy with it and doesn't want it to make coffee I think it
should stay in.
If not we have lots of time to revert the patch before 4.0.6 :)
Andi
At 08:25 AM 3/19/2001 -0700, Chris Newbill wrote:
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.
-Chris
-Original Message-
From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
Sent: Monday, 19 March, 2001 7-04 aM
To: Phil Driscoll
Cc: Chris Newbill; Andi Gutmans; PHP DEV
Subject: Re: [PHP-DEV] feature request
Phil is right. The only thing that may be both useful and
practical would
be isset() on multiple variables, returning either true or false.
Zeev
At 11:31 19/3/2001, Phil Driscoll wrote:
$a = 1;
$b = 2;
$d = 4;
$play_nice = isSet($a, $b, $c, $d);
if (!$play_nice) {
print "The variable missing is in position ";
print ($play_nice*-1);
}
And it would print 3, in which case we would know $c is not
set. I'm not
that sure about this approach, seems like a hack,
It is a hack - what if $a AND $c were unset. You really need to return an
arbitrary length bitfield, with one bit for each arg. Then the
sensible name
for the function would be isunset!
That said, I think the whole idea is bad. I appreciate the
reduced number of
keypresses involved, but I don't think that this is a feature
you can apply
orthogonally to the rest of the language without serious
repercussions, and
therefore it would not posses the desirable attribute that you
would be able
to guess that isset worked this way.
Hence my vote:
(X) don't make sweeping changes to language functionality without fully
considering the repercussions.
Cheers
--
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]
--
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]
--
PHP Development Mailing List http://www.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
At 07:58 PM 3/19/2001 +, Phil Driscoll wrote: 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. isset() is not an internal function but a language construct. I disagree on the "using additional arguments for other stuff part". It's often very weird that functions behave differently according to the way they are called, i.e., if they are passed a string vs. an array they behave differently. Very confusing IMO and I wouldn't want to see this kind of polymorphic functionality in basic language constructs. If people are against this patch I don't mind taking it out. Anyway, I think it's fine the way it is now and useful for people who I have seen that do a zillion of isset()'s one after each other, but I might be wrong. Andi 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
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]
Re: [PHP-DEV] feature request
I think it makes sense to have empty() behave the same as isset() (they are brother functions). empty($a, $b, $c) would return 0 if non are empty and 1 if one of those variables is empty. Andi At 12:22 AM 3/20/2001 -0500, Jon Parise wrote: On Mon, Mar 19, 2001 at 11:35:31PM +0200, Zeev Suraski wrote: Fact is, using isset() with multiple arguments is much more necessary in real world than other is_*() functions. isset() is very often used to validate user input. Then should the same argument be applied to empty(), too? For the record, I'm perfectly happy with things the way they are. If I need to test the existence of two variables, I'm content doing so (verbosely) with two isset() calls. Admittedly, I don't see anything wrong or dangerous with extending isset() to test multiple variables, but I just hope this doesn't go too far into the syntactic sugar realm. -- Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PHP Development Mailing List http://www.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(PHP_4_0_5) /sapi/fastcgi
At 08:32 PM 3/20/2001 +0100, Derick Rethans wrote: On Tue, 20 Mar 2001, Andi Gutmans wrote: andi Tue Mar 20 10:13:21 2001 EDT Added files: (Branch: PHP_4_0_5) /php4/sapi/fastcgiCREDITS Makefile.in README.FastCGI config.m4 fastcgi.c php.sym php_fastcgi.h Log: - MFH erhm, I thought that during the Release Process no new things were being added The SAPI extension was never used by anyone before so there's no harm in adding it (this is not changing/patching existing functionality). It does make two changes to two build files but I took a very close look at them and it doesn't seem like they can cause us problems. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
At 07:41 PM 3/20/2001 +0100, Jani Taskinen wrote: On Tue, 20 Mar 2001, Andi Gutmans wrote: At 08:32 PM 3/20/2001 +0100, Derick Rethans wrote: On Tue, 20 Mar 2001, Andi Gutmans wrote: andi Tue Mar 20 10:13:21 2001 EDT Added files: (Branch: PHP_4_0_5) /php4/sapi/fastcgiCREDITS Makefile.in README.FastCGI config.m4 fastcgi.c php.sym php_fastcgi.h Log: - MFH erhm, I thought that during the Release Process no new things were being added The SAPI extension was never used by anyone before so there's no harm in adding it (this is not changing/patching existing functionality). It does make two changes to two build files but I took a very close look at them and it doesn't seem like they can cause us problems. Still, it's against the rules.. :) And the config.m4 for it isn't..hmm..optimized. Jani, I couldn't find any indication that this can break any of the other sapi builds so I don't think there's a problem with adding it. Adding it now will give it more visibility and more people will be able to test it especially Zeus users who are in great need of it. If the fastcgi sapi extension doesn't work well isn't important as long as it doesn't break anything else. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
At 07:57 PM 3/20/2001 +0100, Jani Taskinen wrote: On Tue, 20 Mar 2001, Andi Gutmans wrote: I couldn't find any indication that this can break any of the other sapi builds so I don't think there's a problem with adding it. Okay. But still I find it very annoying that we don't follow the rules we have created. Just for the record. :) And I hope someone really tests this before release. (I know I won't :) Well everyone testing RC2 will because what will be tested is not fastcgi but that nothing else broke due to the patch, and I pretty much went through the changes which can effect non-fastcgi users to make sure it's OK. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi
Why do we need to have an interrogation. Relax, it's not such a big deal. 4.0.4pl1 4.0.3pl1 both had security fixes (Apache config handling was a security issue). Anyway, I still don't understand what the big fuss is about. Let's stop arguing about this like 4th graders. By the way, the error_reporting() pl1 in 4.0.1 was due to a bug which was in the CVS a long time. It was not a spontaneous bug that was introduced. Andi At 07:50 PM 3/21/2001 +0100, Sascha Schumann wrote: On Wed, 21 Mar 2001, Andi Gutmans wrote: A couple of these were buffer overflows IIRC which were security issues. Remember the group@ emails about those? Fixes against format-string attacks and for file-upload issues went into 4.0.3. Or what are you referring to? - 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] Question about socket ext. file descriptors
Why do you need to rely on such behavior? Are you trying to do something naught? :) I think in general it's not a good idea to rely on the value and type of resources (even though this is an integer). I'm not quite sure why it returns integers and not resources. Looks like a bad thing to me as the extension can easily have file descriptor leaks. The socket should really be saved either in the resource list or in a socket extension local list in order to be able to cleanup at shutdown. I think in the meanwhile you should assume it might change to using resources. Andi At 10:56 PM 3/28/2001 -0800, Lars Torben Wilson wrote: At present, the sockets extension uses integers as file descriptors (e.g. socket() return value). At first I thought maybe they should have been resources until I tried writing some socket code, when I realized that it's easier under many circumstances for them to be ints. Is this going to be behaviour that can be relied upon? Thanks, Torben -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torbenhttp://www.adcore.com| |Ph: 1.604.709.0506 [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] Question about socket ext. file descriptors
Lars, I understand what you're saying but there is one important problem with the current implementation which I think outweighs everything else. The fact that right now you are likely to leak file descriptors. This is very bad especially as Apache processes live for many requests. If the person forgets to close the socket(), his program exits before it reaches that code, or someone presses the STOP button on his browser PHP will leak file descriptors. Very quickly the Apache process will have no file descriptors left. This has to be fixed. I prefer seeing it fixed with resources but in the least it should be fixed not to leak fd's even if you go with the integer fix implementation. But it is not very PHP to do that. You already have an fd resource as far as I know in ext/standard so you can use that. Andi At 02:02 AM 3/29/2001 -0800, Lars Torben Wilson wrote: Andi Gutmans writes: Why do you need to rely on such behavior? Are you trying to do something naught? :) I think in general it's not a good idea to rely on the value and type of resources (even though this is an integer). I'm not quite sure why it returns integers and not resources. Looks like a bad thing to me as the extension can easily have file descriptor leaks. The socket should really be saved either in the resource list or in a socket extension local list in order to be able to cleanup at shutdown. I think in the meanwhile you should assume it might change to using resources. Andi That was what I had been thinking, until I started using select(). Since select() needs to know the max fd # you're working with, it's easy to have it as an int. Unless, of course, select()'s PHP implementation is updated to automatically take this into account. I could always parse the 'Resource #n' string, but that is clumsy. There are other things as well, but this is the first one to come to mind. I totally agree that in general it's a good idea to use resources and leave the housekeeping to PHP, but in situations like this I wonder if the usefulness of the int descriptor doesn't outweight the benefit of turning it into a resource. Basically, I guess I'm approaching socket programming in PHP from a C perspective, and thinking that others might as well. Having the descriptors as ints does tend to relieve some aches, but it might be more PHP-like to move that behind a resourse type and let PHP keep track of the highest fd (for stuff like select()). I guess I also sorta think that when you start messing around with stuff like fd_set() and select(), you expect to be given enough rope to hang yourself with. :) I've no particular leaning to one side or the other, but I'd like to know what people think about this. Thanks again, Torben At 10:56 PM 3/28/2001 -0800, Lars Torben Wilson wrote: At present, the sockets extension uses integers as file descriptors (e.g. socket() return value). At first I thought maybe they should have been resources until I tried writing some socket code, when I realized that it's easier under many circumstances for them to be ints. Is this going to be behaviour that can be relied upon? Thanks, Torben -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torben http://www.adcore.com| |Ph: 1.604.709.0506 [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] -- ++ |Torben Wilson [EMAIL PROTECTED]Adcore Finland| |http://www.coastnet.com/~torben http://www.adcore.com| |Ph: 1.604.709.0506 [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] Question about socket ext. file descriptors
At 03:35 PM 3/29/2001 +0200, Zeev Suraski wrote: Note that the situation isn't as bad as you thought - it's not that it's not using the resource mechanism. It is, if it wasn't, we'd be getting loads of complaints from people running out of descriptors very quickly. It just uses old, PHP 3 style resources, of type IS_LONG. They're still destroyed when the request ends, so it's all safe and all. It simply doesn't use the PHP 4 style, of type IS_RESOURCE, which are actually destroyed when they're no longer needed. It's a good idea to update this code, but it's not very dangerous the way it is now. I think you are wrong. Look at the function accept_connect(). You are creating a new file descriptor and not saving it anywhere! Lars - apparently you got it wrong; The integers you are getting are *not* file descriptors. They're resource handles, of type IS_LONG. They might accidentally correspond to the file descriptors, but it'd be complete coincidence. In short, regardless of whether we upgrade the file functions to use IS_RESOURCE resources or not, what they return cannot be relied upon as file descriptor numbers, simply because they're not. I hope that clears it up... Not for me :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
I very much liked Andrei's implementation of Smary templates. It uses the Zend (PHP) scripting language and caches templated scripts without messing with the core of PHP. I haven't used it but from reading the specs it looks like Andrei his guys did a great job. Andi At 11:10 AM 4/1/2001 +0300, Alexander Bokovoy wrote: On Sun, Apr 01, 2001 at 09:07:44AM +0200, Sebastian Bergmann wrote: Alexander Bokovoy wrote: Ask Zend folks, they have our proposals, even C code to Zend engine to implement native templating with no connection to Midgard at all - this system was designed to be generic for any template providers. Does this have to be implemented in the ZendEngine or would a ext/template extension (for instance) be possible, also? This would be great, though Template Engines are a dying species with the advent of XSLT, IMHO. Not so simple because XSLT is far than complex for lot of applications and especially when you are trying to provide content edit capabilities for non-techies. This is huge nische. It most effective at ZendEngine level but actually task is two-tiered. Let me describe: 1. Templating require additional syntax which is better handled by ZendEngine 2. Syntax provides access to collection of template elements and manipulation of them. It's up to template provider to collect template elements from some source(s) before actual template building. This is better handled by extensions. This separation also allows to make complex transitions like 'document with template markup' - XML-based source + XSLT - output In this case second step is done by Template Provider which provides template elements + hooks to translate them to XML + output callbacks. Zend Engine dispatches these calls via easy user-oriented syntax. For example, in Midgard we have two kinds of template calls: [template element] -- just insert content of template element here and evaluate it as PHP code. It looks like hidden functional call to include() but the difference is that 'template element' actually can come from completely different place than file system (in Midgard it comes from Database or FileTemplates). (variable:formatter); -- pass $variable throught existing formatter and insert output into output stream. Different formatters allow to convert plain text to HTML with different levels of formatting, execute PHP code, execute user-defined formatter against $variable. Variable could be any PHP structure (scalar, object, array, etc) These are very simple constucts, but they are greatly reduce build-up for non-technical interfaces. -- Sincerely yours, Alexander Bokovoy The Midgard Project| ALT Linux Team | Minsk Linux Users Group www.midgard-project.org | www.altlinux.ru |www.minsk-lug.net -- Success is in the minds of Fools. -- William Wrenshaw, 1578 -- PHP Development Mailing List http://www.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] Can we have a PING function?
Do most servers and OS's (for example Windows) support the sending of a UDP package to the echo port? Andi At 12:39 AM 4/2/2001 -0400, Dave Crawford wrote: Before I ask for a PING function in a future build of PHP, is there a way to ping a remote host using the existing PHP functions or modules? Based on my knowledge gained from various sources and php.net's online functional reference, there does not appear to be much support for LWP anything. I would like to know how to do, or perhaps you can build a function in a future release that can do basically the same thing as outlined in the following document for a similar function in Perl: http://www.perl.com/pub/doc/manual/html/lib/Net/Ping.html When my site was all html and Perl, I used this function to ping all of my mirror download sites, and I coloured the ping value based on a range (Ex: less than 150ms was green, greater than 600ms was red, etc.) I need a way to incorperate this same functionality into my new all PHP based website. Thanks. -Dave -- PHP Development Mailing List http://www.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] PHP 4.0.5 Release Candidate testing
Andrei, Can you please merge this to 4.0.5. I think it should be in and we better release a final RC6. I think it's better to have another quick RC (I can roll it today or tomorrow) before we get 4.0.5 out of the door. Andi At 08:25 AM 4/2/2001 -0500, Andrei Zmievski wrote: On Mon, 02 Apr 2001, Alexander Feldman wrote: Hi, These are the results and questions from some tests I run yesterday on the last 4.0.5 release candidate. Note that all differences are from PHP 4.0.4pl1. 1. The function array_flip($array) puts one extra zero byte at the end of each element in the return array thus making the result non binary safe. I've just fixed it in CVS. 3. The count_chars() function returns different result from the 4.0.4pl1 count_chars() function. Examples? -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] -- PHP Development Mailing List http://www.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] PHP 4.0.5 Release Candidate testing
Thanks! Does anyone else have any critical bug fixes which need to be in 4.0.5? (I mean critical ones and not huge patches). Andi At 11:17 AM 4/2/2001 -0500, Andrei Zmievski wrote: It's done. On Mon, 02 Apr 2001, Andi Gutmans wrote: Andrei, Can you please merge this to 4.0.5. I think it should be in and we better release a final RC6. I think it's better to have another quick RC (I can roll it today or tomorrow) before we get 4.0.5 out of the door. Andi -Andrei * Non-volatile, random-access, analog memory store... a book. * -- PHP Development Mailing List http://www.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] Can we have a PING function?
Maybe Dave will volunteer to implement this for 4.0.6 :) Andi At 10:42 AM 4/2/2001 +0200, Alexander Feldman wrote: Do most servers and OS's (for example Windows) support the sending of a UDP package to the echo port? Andi Yeah, What about a new ICMP extension - ping, traceroute, etc. -- Alex At 12:39 AM 4/2/2001 -0400, Dave Crawford wrote: Before I ask for a PING function in a future build of PHP, is there a way to ping a remote host using the existing PHP functions or modules? Based on my knowledge gained from various sources and php.net's online functional reference, there does not appear to be much support for LWP anything. I would like to know how to do, or perhaps you can build a function in a future release that can do basically the same thing as outlined in the following document for a similar function in Perl: http://www.perl.com/pub/doc/manual/html/lib/Net/Ping.html When my site was all html and Perl, I used this function to ping all of my mirror download sites, and I coloured the ping value based on a range (Ex: less than 150ms was green, greater than 600ms was red, etc.) I need a way to incorperate this same functionality into my new all PHP based website. Thanks. -Dave -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP 4.0.5 Release Candidate testing
At 05:37 PM 4/2/2001 +0100, Anil Madhavapeddy wrote: Andi Gutmans wrote: Does anyone else have any critical bug fixes which need to be in 4.0.5? (I mean critical ones and not huge patches). Zeev's output buffering fix hasn't been committed yet; it's a one-line change, and it makes the transparent output compression stuff work. I suggest you merge this into 4.0.5 because it seems to me that otherwise output buffering will be quite a mess without it. It would be a shame to release 4.0.5 without it. Does anyone have any objection to an MFH on the small Vary header patch also? It improves PHP's RFC2616 compliance, but it also unbreaks almost every web-cache, which rely on having it present for content-negotiated pages. Your fix looks OK but I'd like to hear the opinion of someone else who is more familiar with RFC2616. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: [PHP-QA] PHP 4.0.5 Release Candidate testing
At 03:18 PM 4/2/2001 +0100, James Moore wrote: 1. The function array_flip($array) puts one extra zero byte at the end of each element in the return array thus making the result non binary safe. I've just fixed it in CVS. How critical is this? does it need to also be in 4.0.5 (sorry Zeev ;)) Yes, I think it should be in 4.0.5 And the output buffering patch of Zeev should be in there too. Hopefully RC6 will be the last RC. Better another RC than a pl1. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RC6 available!
You can get RC6 at http://cvs.php.net/~andi/php-4.0.5RC6.tar.gz (no time to commit to phpweb cvs and wait for it to update, if someone has time then even better, I need some sleep :) In case you're testing it within the next few hours you might need to "touch *" the files in the php4/ directory because of timezone differences (didn't anyone get bitten by this in the past? ). Anyway, as usual, please test it on all the platforms you have. Try not to find bugs but if you do then let everyone know. Happy testing. Hopefully this is the last RC but remember the most important thing is to have a stable release. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6
Anyone have an idea why this happens? Andi At 05:37 PM 4/3/2001 +0200, Andrew Sitnikov wrote: Hello php-qa, test.php ? echo $test; ? http://host/test.php?test=1;2;3 4.0.4pl1 Result: 1;2;3 4.0.5RC6 Result: 1 Best regards, Andrew Sitnikov e-mail : [EMAIL PROTECTED] GSM: (+372) 56491109 -- PHP Quality Assurance Mailing List http://www.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] PHP-4.0.5-RC6
It might be valid but we might be breaking many people's sites. I am not sure this is a very good idea. Is it configurable via php.ini? We could keep the default the old behavior. Andi At 06:35 PM 4/3/2001 +0100, Anil Madhavapeddy wrote: It's the arg_separator changes isn't it? Both '' and ';' are valid delimiters in a URL, so the new 4.0.5 behaviour is actually the valid one, I believe. Refer to the XHTML specification, or check out the bugs db for this. Anil - Original Message - From: "Andi Gutmans" [EMAIL PROTECTED] To: "Andrew Sitnikov" [EMAIL PROTECTED]; [EMAIL PROTECTED]; "php-dev mailinglist" [EMAIL PROTECTED] Sent: Tuesday, April 03, 2001 6:21 PM Subject: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6 Anyone have an idea why this happens? Andi At 05:37 PM 4/3/2001 +0200, Andrew Sitnikov wrote: Hello php-qa, test.php ? echo $test; ? http://host/test.php?test=1;2;3 4.0.4pl1 Result: 1;2;3 4.0.5RC6 Result: 1 Best regards, Andrew Sitnikov e-mail : [EMAIL PROTECTED] GSM: (+372) 56491109 -- PHP Quality Assurance Mailing List http://www.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] PHP-4.0.5-RC6
At 10:01 PM 4/3/2001 +0200, Jani Taskinen wrote: On Tue, 3 Apr 2001, Zeev Suraski wrote: My guess is that's the arg_separator fix. Jani? Yes, that's true. I did ask (couple of times) before I committed that patch. And yes, now both and ; are considered as arg separators. And I'd like to think that it's a feature than bug. ;) Yes I understand but it's not always so clear cut especially not when you can break a lot of scripts. There is always a trade-off between backwards compatibility and doing the right thing. Is this configurable in php.ini? I'm not familiar with the patch itself (couldn't find the CVS diff). This url explains why it's considered a good thing: http://www.w3.org/TR/html4/appendix/notes.html#h-B.2.2 If this breaks someone's scripts, that's their fault.. :-) (ie. they should be using urlencode() on the urls if they contain illegal chars..) --Jani At 19:21 3/4/2001, Andi Gutmans wrote: Anyone have an idea why this happens? Andi At 05:37 PM 4/3/2001 +0200, Andrew Sitnikov wrote: Hello php-qa, test.php ? echo $test; ? http://host/test.php?test=1;2;3 4.0.4pl1 Result: 1;2;3 4.0.5RC6 Result: 1 Best regards, Andrew Sitnikov e-mail : [EMAIL PROTECTED] GSM: (+372) 56491109 -- PHP Quality Assurance Mailing List http://www.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 Quality Assurance Mailing List http://www.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]
Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] PHP-4.0.5-RC6
James,
You have to be aware that now PHP has such a big user base we need to be
very careful in the changes we make especially when we can be pretty
certain that it might burn quite a lot of people. We can break
compatibility more easily when we have a major release (as from PHP 3 to
PHP 4) but these kind of patches need to also be sensitive to the existing
users.
I personally don't know this issue very well and it is hard for me to guess
how many people will be effected. Probably some of you who know this better
can get an idea. Also I missed if this is the same directive as in php.ini.
Anyway, I'm just saying don't take the user base too lightly because most
of them aren't php-dev@ hackers who want the standards but they want their
web sites to continue working.
Anyway, this doesn't mean I am necessarily against including the patch but
we need to make sure we're all OK with it and make a decision not only
based on the standard but also on how much damage this might make.
Andi
At 09:22 PM 4/3/2001 +0100, James Moore wrote:
Yes, that's true. I did ask (couple of times) before
I committed that patch. And yes, now both and ; are
considered as arg separators.
And I'd like to think that it's a feature than bug. ;)
That would be true, if PHP would be some kind of reference
implementation. But we don't exist to force standards down
our users' throats.
It should be optional and default to off.
Why shouldnt we require people to use legal url's?
If we are conforming to standards, and I feel we should where possible (they
are there for a reason.. by your argument why should dirname("/foo/") return
/ rather than /foo, which, to most of us is the most obvious but as you
pointed out earlier the standards say so..).
If I come from some other language or where ever and expect test=1;2;3 to
work someway and it works differently to the standards "just because it does
and we dont want to ram standards down peoples throats" its going to piss me
off. I agree it should be optional but should be defaulted to on.
-James
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
--
PHP Development Mailing List http://www.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-QA] PHP-4.0.5-RC6
At 09:52 PM 4/3/2001 +0100, James Moore wrote: Well, I dont think any of us really know how much damage it will cause. But on the other hand we can do this for years and just say well we mustn't break backwards compatibility and we will end up with somthing looking and behaving like perl. When we have somthing as blantantly wrong as this it should be fixed. I would question about it being optional in the long term though. If we begin to make everything optional then we get to a point where PHP is so configurable with enabling this bug here or there it becomes impossible to create distribuable scipts that are easy to install and make work (making it difficult for commercial companies to create PHP Scripts to sell which is a bad thing IMHO). I also prefer as little as possible to be configurable so that PHP applications written on one PHP installation will run on all others. I think configurability should be kept at a minimum. However, changing such behavior in a mini-version is not obvious. And when you say it's "blantantly wrong" the way it works today, well maybe it is, but we both know how many people really got bitten by this "blatantly wrong". Very few... Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: ; arg seperator
At 02:46 PM 4/3/2001 -0600, Joey Smith wrote: Just wanted to toss in my .02 here... Anyone who wrote scripts in the past expecting: foo.php?a=1;2;3 to get "$a=1;2;3" was relying on a bug, or at the very LEAST an undocumented feature. So if it goes away, it goes away. It should never have worked to begin with, IMHO... Why? It was documented that was the separator. This doesn't mean it won't bite some people, but that's never been a problem before in cases of undocumented features. I don't think it was undocumented. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] Re: ; arg seperator
At 03:18 PM 4/3/2001 -0600, Joey Smith wrote: Speaking of this, I think we need to collect all of these types of issues that are waiting for a "4.1" release somewhere, so we can get a clear idea of when 4.1 is appropriate. Anyone know of any off-hand? If not, I can go search the archives... In any case it is a good idea to make a list of these issues. I can't remember off hand what issues we had so I hope people have a better memory than me :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Unix timestamp maximum
By the time we close in on 2038 and UNIX is still around (*smile*) then most UNIX systems will most probably have moved to 64bit timestamps, thus requiring in the best place just a recompilation of your PHP binary and in the worse case if you saved binary file stamps to a file, some kind of conversion script. It's not as bad as the Y2K bug (which wasn't too bad:) Andi At 05:06 PM 4/4/2001 +0200, Keith Waters wrote: From: [EMAIL PROTECTED] Operating system: RedHat Linux PHP version: 4.0.4pl1 PHP Bug Type: Feature/Change Request Bug description: Unix timestamp doesnt go over Tuesday 19 January 2038 05:11 As you know, most of PHP's date and time functions use the unix timestamp, which wont go past Tuesday 19 January 2038 05:11, numberically represented by 2147483648 (ie 30 bits) Surely PHP can get clever and work around this? (ie allow bigger values which will translate back and forth properly up to the year ?) Otherwise we will all find outselves with a Y2K-like date nightmare! eg: currently: echo mktime(0,0,0,1,1,2099); outputs -1 and putting any number past 2147483648 into date() wont give you anything past Tuesday 19 January 2038 05:11 Thanks! regards, Keith -- PHP Development Mailing List http://www.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] What to do about 4.0.5
OK guys, I feel VERY uncomfortable releasing 4.0.5 with this arg_separators problem. Let's brainstorm and try to think of a nice, clean and constructive way of solving this problem. Let's try to ditch the "screw the user because he didn't read RFC foo.bar approach :) The issue is with the arg_separator of incoming URL's. If we think of a nice solution we should probably make it lookfeel similar to the solution we will have with URL's which are created. Ideas? Thoughts? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] What to do about 4.0.5
At 05:40 PM 4/4/2001 +0200, Jani Taskinen wrote: On Wed, 4 Apr 2001, Andi Gutmans wrote: I feel VERY uncomfortable releasing 4.0.5 with this arg_separators problem. Let's brainstorm and try to think of a nice, clean and constructive way of solving this problem. Let's try to ditch the "screw the user because he didn't read RFC foo.bar approach :) The issue is with the arg_separator of incoming URL's. If we think of a nice solution we should probably make it lookfeel similar to the solution we will have with URL's which are created. We spoke with Zeev about this. We came to conclusion that there should be a php.ini directives like these: arg_separator.input=";" arg_separator.output="amp;" Where defaults are: arg_separator.input="" arg_separator.output="amp;" Sounds like a good solution to me. The places which used the old arg_separator seem to only be in main.c and url_scanner*.c So we should update these and add support for the arg_separator.input. I think that's really OK. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] RE: ; arg seperator
At 07:11 PM 4/4/2001 +0200, Edin Kadribasic wrote: But commercial companies aside, the plethora of configuration options (like magic_quotes_gpc) can and does make life harder for people writing code libraries (like PEAR) that are meant to be dropped in anywhere, or for people trying to write applications that have minimal setup required, or that people can install on hosts where they don't have access to the php.ini parameters. It's certainly something to keep in mind. There was a discussion about things to break in 4.1. magic_quotes_gpc would definitely be my favourite. I'd like to see it set to off for good and removed from php.ini. Is anybody keeping notes ? ;) I think you just volunteered yourself :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.5 Comments change (leads to inappropriate parse error based on contents of comments)
This was fixed to be consistent with ?.
One line comments end at a new line or at a closing bracket (? or %)
Andi
At 05:54 PM 4/4/2001 -0700, Steven Roussey wrote:
Hi,
I found our problem. In 4.0.5, comments seem to be parsed differently. We
have ASP style tags enabled so we can use % as well as ?. But we had
comments like this:
?
//asdfasdf%asdfasdf
echo('');
?
4.0.5 would ignore the whole line. 4.0.5 still parses it for open and
close tags. The lines above get handled differently from 4.0.4 to 4.0.5. It
is hard to track if the comment is inside a class, because there is no parse
error until the end of the file, and the code is not spit out like HTML (as
in the example above) because it is compiling the file. I think this is a
bug. We can clean up our code to fix it (and will), but
Sincerely,
Steven Roussey
Network54.com
http://network54.com/?pp=e
--
PHP Development Mailing List http://www.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 / NEWS php.ini-dist php.ini-optimized /ext/standard url_scanner.c url_scanner_ex.c url_scanner_ex.re /main main.c php_globals.h php_variables.c
At 10:22 AM 4/5/2001 +0200, Sascha Schumann wrote: On Wed, 4 Apr 2001, Jani Taskinen wrote: sniperWed Apr 4 13:46:27 2001 EDT Modified files: /php4 php.ini-dist php.ini-optimized NEWS /php4/ext/standardurl_scanner.c url_scanner_ex.re url_scanner_ex.c /php4/mainmain.c php_globals.h php_variables.c Log: Added new configuration directives: arg_separator.input and arg_separator.output Am I the only one who thinks that breaking installations which use a different arg_separator is odd? Now all those working installations have to be manually modified just to append ".output". Considering the ambiguity I think it is the right thing to do. The default behavior will be backwards compatible and we can have a big caps news entry about it (for people who changed arg_separator). We could also keep arg_separator as an INI parameter in 4.0.5 and raise an error with a message on how to fix it (changing arg_separator to arg_separator.output). Andi Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Request for new feature: $HTTP_SESSION_VARS when register_globals = on
Yes, what you're saying definitely makes sense and I think it should be fixed. Andi At 09:20 PM 4/5/2001 +0200, Carsten Gehling wrote: One of the IMHO stranger behaviors in PHP is what happens to the $HTTP_SESSION_VARS array when changing register_globals from off to on. If register_globals is set to on, you cannot access $HTTP_SESSION_VARS any longer. Instead you can get the values through implicit created variables or through the $GLOBALS array. Now compare this to $HTTP_GET_VARS and $HTTP_POST_VARS. Both of these arrays are available regardless of what register_globals is set to. Shouldn't it be the same for $HTTP_SESSION_VARS ? - Carsten -- PHP Development Mailing List http://www.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] Hash Functions API
At 01:40 AM 4/12/2001 -0400, Stig Sther Bakken wrote: ["Brian Foddy" [EMAIL PROTECTED]] I've been looking everywhere for a good reference of how to read and update arrays. The Zend documentation (www.zend.com/apidoc) has descriptions of how to create an array, and how to add elements to it, but I can't find anything on how to simply read the values of an array. Mostly I want to write two functions: 1. Accept a provided 2 dimensional array and loop through every element, by primary index then an inner loop by the second index, sequentially. I need to extract from the array the two keys and the value. The keys will not be sequential, at least the primary. 2. Build a 2-d array, basically the reverse of 1 above. Build an array with specific primary and secondary indexes. Again keys will not be sequential. To make matters worse, I'd like the keys to be either integer or strings. I've looked through the zend_hash.h header, and a few functions look likely (zend_hash_move_forward, zend_hash_get_current_key). Those are the ones you want, plus zend_hash_get_current_data. Also check out the _ex() functions. They give you more features. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] always building cgi...
Well I have been abroad and been reading Emails very slowly via international calls so I might have missed a few (no need for the sarcasm). What I describe is the situation I would like to see. I will try and catch up will the zillions of Email I have and see why this can't be achieved. Andi At 04:01 PM 4/15/2001 +0200, Sascha Schumann wrote: All it really requires is compiling cgi_main.c with the same flags and linking it to the libphp4.la If you had read the emails, you would have noticed the problem behind that thought. - 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] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
At 03:33 AM 4/19/2001 +0300, Zeev Suraski wrote: Guys, Over the years, there's always been a tendency to think about things which are 10 steps ahead. It never worked, and I don't think it would work here either. Moreover, I don't see any advantage in discussing this now - on the contrary - we really have no idea what we're talking about. Whether or not we separate modules *at all* will greatly depend on how good an implementation we end up having. How many of them we end up separating will also depend on that. Let's just wait with those discussions until they're somehow connected with reality. Zeev Scary... Didn't read this before :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
At 08:03 AM 4/19/2001 -0400, Stig Sther Bakken wrote: [Andi Gutmans [EMAIL PROTECTED]] At 06:53 PM 4/18/2001 -0400, Stig Sther Bakken wrote: *BLAM* That's the sound of someone shooting himself in the foot. The PEAR installer needs the XML extension. :-) What do you mean? Has work started on this already? I'm not quite sure what you mean by the PEAR installer but I think we should discuss the util we would need to list/fetch/build C extensions from the PEAR repository on php-dev@. I think it's a waste of time to decide right now what to remove instead of trying to finalizing this utility. Once we see how well it works it'll be time to start thinking of what extensions to remove. I think it's just putting energy in the wrong place right now :) You don't read php-cvs anymore do you Andi? :-) I do but I'm senile :) If you configure the CGI and do "make install", you'll have a command-line utility written in PHP called "pear" that can do two things: make a package tarball, and install a tarball. It currently only support "pure PHP" packages. How to test it: $ cvs co pear/HTTP $ cd pear/HTTP $ pear package package.xml (this will give you a file called HTTP-1.0.tgz) $ pear install HTTP-1.0.tgz OK I definitely missed that one. There's a lot of stuff missing from the installer still, but that'll be added in time. It is also UNIX-only right now. Since I'm not a Windows user myself, I totally depend on the help of some Windows people to make it work in Windows. The reason I joined the "what extensions to keep" discussion is that I think it (the discussion) is going to take some time. :-) Yeah but I just thought it'd be better to focus people's energy on getting it to work :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
At 08:13 AM 4/19/2001 -0400, Stig Sther Bakken wrote: [Andi Gutmans [EMAIL PROTECTED]] Right but if we chose XML this makes it much harder to have C clients (even Perl because the module might not be installed). I don't think Over my dead body. Take a look at all the magazines reviewing which web development tools to use. Most of them end up with PHP because it fits their job. Imagine all the fun authors of such articles can have it PHP requires Perl to install the stuff you need. it will be such a complicated format for us to need XML here especially as it limits what clients will be created. I think it needs more thought. Having a prototype for the functionality is OK but not if you're talking about a prototype which sets the standard. XML is a commodity today. Just take a look at what the industry out there is using. If we were to write it in C we would most likely need to provide a statically linked binary anyway for the different platforms as not everyone will have access to a fully functioning development environment. If they are compiling PHP and PHP extensions we can expect them to be able to compile an ANSI C program. Despite the pervasiveness of Perl, chances are high that certain Perl modules would be missing and then someone has to go looking for Perl modules to install PHP packages.. Ouch! You can do this kind of stuff with the Vanilla Perl and don't need extensions. To be quite blunt, I don't have the time to implement this in C. I've tried to get people involved in the strategy for PEAR for months and months. It's typical that nobody reacts until after implementation has started though. I want to get this system up and running sooner rather than later, so I'm willing to make something that we throw away and reimplement rather than to not have something for one more year. I think you are right. BTW, how are you planning on making it as transparent as possible for a user who downloads PHP and wants to compile it with PEAR C-extensions such as XML, MySQL Oracle (these are just examples, it doesn't reflect my opinion if these should stay in or out of the php tree itself)? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] RC7 is out
At 02:59 PM 4/20/2001 -0700, Andrew Sitnikov wrote: Hello Zeev, neljapev, 19.04.2001, you wrote: ZS I rolled RC7 - if there are no surprises (there'd better not be! :), it ZS can finally go out early next week. ZS Zeev Where i can get it ? http://www.php.net/distributions/php-4.0.5RC7.tar.gz Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] unix install paths changed
At 09:59 AM 4/23/2001 -0700, Frank M. Kromann wrote: These have to be defined on Win32 as well. In order to compile I can just put some default definitions in config.w32.h. I'm getting another error though: D:\php\php4\main\php_ini.c(190) : error C2065: 'llist_dtor_func_t' : undeclared identifier There is llist_dtor_func_t defined ? This is due to a patch of mine to the Zend CVS. You forgot to update your Zend checkout. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] 4.0.5: Merge Request
At 03:59 PM 4/24/2001 +0300, Zeev Suraski wrote: A reproducible crash bug in a mainstream module is a show stopper IMHO... I think you mean in a mainstream module and in a situation which has a high chance of happening. Crash bugs which are 1 in a million don't necessarily need to be show stoppers. 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]
