Re: [PHP-DEV] comments in php

2001-01-13 Thread Andi Gutmans

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

2001-01-16 Thread Andi Gutmans

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] Patch that corrects non blocked socket reading on W IN32

2001-01-16 Thread Andi Gutmans

Yep!

Andi

At 07:05 PM 1/16/2001 +0100, Sascha Schumann wrote:
On Tue, 16 Jan 2001, Christophe Thibault wrote:

  Actually, it's not that dangerous as the redefinition of errno only occurs
  in fsock.c and errno is only used in fsock.c for retrieving socket 
 errors...

 Something like this is more safer:

 #ifdef PHP_WIN32
 #define php_sock_errno() WSAGetLastError()
 #else
 #define php_sock_errno() errno
 #endif

 - 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]




Re: [PHP-DEV] RE: mysql_pconnect still broken (was: RE: What does this mean ?)

2001-01-17 Thread Andi Gutmans

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

2001-01-21 Thread Andi Gutmans

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

2001-01-21 Thread Andi Gutmans

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] Bug #8732

2001-01-24 Thread Andi Gutmans

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]




Re: [PHP-DEV] Proposal for updating the PDF-extension

2001-01-24 Thread Andi Gutmans

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:

2001-01-27 Thread Andi Gutmans

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

2001-02-03 Thread Andi Gutmans

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

2001-02-03 Thread Andi Gutmans

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

[PHP-DEV] FreeBSD ISO

2001-02-04 Thread Andi Gutmans

Any idea if there's a place where one can download an ISO of FreeBSD? I 
can't seem to find one on ftp.freebsd.org and I don't feel like waiting 
until an order arrives.

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]




Re: [PHP-DEV] wrong implementation of isset()?

2001-02-07 Thread Andi Gutmans

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

2001-02-12 Thread Andi Gutmans

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] Midgard (Was: cvs: php4 /ext/midgard .cvsignore...)

2001-02-12 Thread Andi Gutmans

At 10:18 PM 2/12/2001 +0100, Emiliano wrote:
Sebastian Bergmann wrote:
 
  Emiliano wrote:
   But PEAR is a repository for scripts written in PHP, right?
 
PHP Extension and Add-On Repository. Extensions and Add-Ons, written in
  either PHP or C, are welcome :-)

OK, my mistake. So moving php4/ext/midgard to php4/pear/midgard would
solve this?


Well right now it won't really solve it because pear is included in the 
distribution. However, the idea behind pear is to be something more similar 
to CPAN which means both PHP and C code.

Does the build process differ here? And like my previous question, are
there
examples on how to build config.m4s, and other supportive files, so an
extension can easily be built as an php-dloabable, a static extension,
and a static extension in a statically-compiled PHP (into Apache
itself)?

The easiest way to get it working is "cd php4; cp -r /path/to/midgard ext; 
./buildconf".
That's all people need to do in order to get it to work with their vanilla PHP.
You can check out some of the other extensions to see how to build a shared 
library but with my example it's not necessary.
There is also the phpize stuff (which I don't know). It's something like 
phpize /path/to/midgard and then compiling the midgard as a shared library. 
I think the first example I gave you is probably good enough though.

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] Changing implementation of get_meta_tags for 4.0.5

2001-02-13 Thread Andi Gutmans

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?

2001-02-13 Thread Andi Gutmans

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

2001-02-13 Thread Andi Gutmans

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?

2001-02-19 Thread Andi Gutmans

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

2001-02-20 Thread Andi Gutmans

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()

2001-02-22 Thread Andi Gutmans

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]

2001-02-24 Thread Andi Gutmans

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

2001-02-24 Thread Andi Gutmans

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]




[PHP-DEV] Japanese PHP

2001-02-25 Thread Andi Gutmans

Hi,

I remember there was a patch around for PHP 3.0.x which added some Japanese 
support functions.
Anyone know how many Japanese actually used these functions and how many 
are using Vanilla PHP?
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 :)

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: Japanese PHP

2001-02-25 Thread Andi Gutmans

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

2001-02-27 Thread Andi Gutmans

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

2001-02-27 Thread Andi Gutmans

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!)

2001-02-27 Thread Andi Gutmans

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

2001-02-28 Thread Andi Gutmans

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

2001-02-28 Thread Andi Gutmans

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

2001-03-01 Thread Andi Gutmans

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

2001-03-01 Thread Andi Gutmans

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] Re: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV]ctype function (re?)naming

2001-03-02 Thread Andi Gutmans

We should probably just make a list of all the effected functions and see 
which ones we start fixing and which not.
And of course it has to be a very gradual death of the old functions 
similar to the way described on the QA list a while ago about having a 
warning after a few versions and only then nuking the aliases.
By the way, we already have some ugly aliases today which I'd love to nuke :)

But guys, there's one thing you need to remember and I've seen it in the 
past. The amount of people you think will get bitten by something this 
small is usually 10 times more than you really think :'(

Andi

At 09:24 PM 3/1/2001 -0700, Ron Chmara wrote:
Andi Gutmans wrote:
  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.

"zillion" is a bit hard to pin down, isn't it? :-)

I took a swipe at figuring out the scope of the issue, and we have a
small mix of variants in a mostly consistent set of names. I'd say less
than a zillion. A bunch or so, maybe? ;-)

If done as a "think about this when updating and editing old code" problem,
the task of aliasing becomes much smaller, and much more achievable. It
also becomes less wasteful, as functions which aren't being actively
used (and thus, maintained) can atrophy gracefully, without having all
sorts of aliases created for a mostly unused function. (Example: Oracle
functions are slowly falling away, being replaced by OCI, swf functions
are doing a similar thing.)

  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.

I'd definitely agree with both points, but am wondering if there's a 
"reasonable"
limit on supporting old scripts. (I'd call reasonable 6 years worth of
code, or three major codebase rewrites).

(Thanks for the humor Zak, it helps... I'm gonna go cry, hold onto
my woogie, and see if I can remember heim_unblock())
:-)

-Bop

--2D426F70|759328624|00101101011001100111
Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
The opinions expressed in this email are not necessarily those of myself,
my employers, or any of the other little voices in my head.


-- 
PHP Development Mailing List http://www.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

2001-03-02 Thread Andi Gutmans

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

2001-03-02 Thread Andi Gutmans

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

2001-03-02 Thread Andi Gutmans

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

2001-03-02 Thread Andi Gutmans

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]




Re: [PHP-DEV] Re: about users of japanese localized php3

2001-03-04 Thread Andi Gutmans

Please send me your Email (as it should be in the CVS account), preferred 
user name and password.

Andi

At 12:03 PM 3/5/2001 +0900, [EMAIL PROTECTED] wrote:
Hello.

I am Takuya Tsukada. I wrote of some Japanese module for PHP.
I would like to commit the Japanese extention to CVS.
So, Will you be able to have me issue a CVS account?


 
  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
 
 


--
sender: Tsukada Takuya
town: inaba hizume, Nagano City


-- 
PHP Development Mailing List http://www.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] mcrypt

2001-03-04 Thread Andi Gutmans

What bugs?
Can you describe them and cut them down to something very simple which will 
allow us to fix it?

Andi

At 01:48 PM 3/5/2001 +1000, Cameron wrote:
when are the bugs with the latest mcrypt going to be fixed?!?


Cameron


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] Bug #8565 -- analyzed, but...?

2001-03-06 Thread Andi Gutmans

I couldn't reproduce this problem. It only happens when you declare the 
sub-class before you declare the base class.
Is this what is happening to you? Or can you send me a very short 
reproducing set of scripts.

Thanks,

Andi

At 03:17 AM 3/6/2001 -0800, Richard Lee-Morlang wrote:

I ran into bug #8565, and after locating it in the database, I see that
it's marked as analyzed but it hasn't been updated for two months. The
last comment indicates that it's been left for "Zeev/Andi's attention".
I tried current CVS and it breaks as well.

It seems like this would make the parent:: syntax quite useless in many
situations. PEAR comes to mind. Does anyone know the status of this
issue, or has it been forgotten?

Rick



--
PHP Development Mailing List http://www.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

2001-03-06 Thread Andi Gutmans

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

2001-03-06 Thread Andi Gutmans

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

2001-03-06 Thread Andi Gutmans

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

2001-03-06 Thread Andi Gutmans

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

2001-03-06 Thread Andi Gutmans

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

2001-03-06 Thread Andi Gutmans

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

2001-03-06 Thread Andi Gutmans

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

2001-03-06 Thread Andi Gutmans

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

2001-03-07 Thread Andi Gutmans

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

2001-03-07 Thread Andi Gutmans

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

2001-03-07 Thread Andi Gutmans

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

2001-03-08 Thread Andi Gutmans

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

2001-03-09 Thread Andi Gutmans

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

2001-03-09 Thread Andi Gutmans

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

2001-03-09 Thread Andi Gutmans

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?

2001-03-09 Thread Andi Gutmans

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?

2001-03-09 Thread Andi Gutmans

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] static call bugs?

2001-03-09 Thread Andi Gutmans

If you have:

class foo
{
 function blahblah()
 {

 }
}

class foobar extends foo
{
}

class bar extends foobar
{
 function hey()
 {
 foo::blahblah(); -- You want $this to be correct in 
foo::blahblah.
 }

}

Andi

At 01:32 AM 3/10/2001 +0100, Andr Langhorst wrote:

Is that bad? Could come in useful, especially when calling parent
classes.

wow, what a quick response :)
could you elaborate (I guess you do not have parent:: in your mind writing 
from parent classes)?

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 Development Mailing List http://www.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?

2001-03-10 Thread Andi Gutmans

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

2001-03-12 Thread Andi Gutmans

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

2001-03-12 Thread Andi Gutmans

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?

2001-03-12 Thread Andi Gutmans

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

2001-03-14 Thread Andi Gutmans

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?

2001-03-14 Thread Andi Gutmans

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

2001-03-15 Thread Andi Gutmans

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

2001-03-15 Thread Andi Gutmans

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

2001-03-18 Thread Andi Gutmans

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

2001-03-18 Thread Andi Gutmans

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

2001-03-19 Thread Andi Gutmans

:)

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

2001-03-19 Thread Andi Gutmans

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

2001-03-19 Thread Andi Gutmans

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

2001-03-19 Thread Andi Gutmans

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

2001-03-19 Thread Andi Gutmans

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

2001-03-20 Thread Andi Gutmans

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

2001-03-20 Thread Andi Gutmans

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

2001-03-20 Thread Andi Gutmans

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

2001-03-21 Thread Andi Gutmans

At 05:03 PM 3/21/2001 +0100, Sascha Schumann wrote:
  The bottom line is that, as I said, the trick in good opensource software
  is taking calculated risks, and mixing agility with quality assurance.  One
  can look through your binary glasses, and then it's either complete lack of
  quality, or complete lack of risks, and one can look with reasonable
  experienced eyes and strive to get to the right mixture.  I, for one, don't
  enjoy looking through these binary glasses.

 Then please start explaining what the right mixture is.
 Apparently, we have not found the right mixture yet, unless
 of course, patchlevel releases are part of that Great Plan.

I think most (probably not all) pl's were sparked due to security bugs 
which were found and we took the opportunity to add another couple of 
important fixes. Those kind of pl's would not have been prevented by any 
Great Plan.

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

2001-03-21 Thread Andi Gutmans

A couple of these were buffer overflows IIRC which were security issues.
Remember the group@ emails about those?
Andi

At 07:17 PM 3/21/2001 +0100, Sascha Schumann wrote:
  I think most (probably not all) pl's were sparked due to security bugs
  which were found and we took the opportunity to add another couple of
  important fixes. Those kind of pl's would not have been prevented by any
  Great Plan.

 If I remember correctly, 4.0.4pl1 was the only release
 which also happened to include security-related changes
 beside important bug fixes.

 Here is a quick summary.

 4.0.4pl1, two weeks after 4.0.4
 - broken user function calls affects modules like XML and
   Session, broken Apache Config

 4.0.3pl1, three days after 4.0.3
 - broken Apache Config handling

 4.0.1pl2, two days after 4.0.1
 - broken error_reporting() and readdir()

 4.0b4pl1, one day after 4.0b4
 - magic_quotes crash

 - Sascha Experience IRCG
   http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_0_5) /sapi/fastcgi

2001-03-21 Thread Andi Gutmans

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

2001-03-29 Thread Andi Gutmans

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

2001-03-29 Thread Andi Gutmans

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

2001-03-29 Thread Andi Gutmans

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] Question about socket ext. file descriptors

2001-03-29 Thread Andi Gutmans

At 03:47 PM 3/29/2001 +0200, Zeev Suraski wrote:
At 15:41 29/3/2001, Andi Gutmans wrote:
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!

So this function may be an exception to the rule.  But generally, all of 
the file/socket functions use ZEND_REGISTER_RESOURCE() or 
zend_list_insert(), so they're fine.

Well we were talking about the ext/socket extension and all functions there 
which create file descriptors are leaking. It's not an exception. Check 
open_listen_sock() and accept_connect().
You were probably looking at the fd set functions which are just 
emalloc()'ed memory. The happen to use resources but even if they hadn't it 
would be a leak which the Zend memory manager would clean up. The file 
descriptors is the real problem.

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] fastcgi

2001-03-29 Thread Andi Gutmans

I don't have time to look at it but the error about sapi_globals use 
SLS_FETCH(); in the beginning of that function.
The S_ISREG is defined in fopen-wrappers.c. We should probably move it to 
someplace more central so that other files see it (it exists on some 
systems automagically but not on Windows).
And of course, fork() doesn't exist on Windows. No time to go and look at 
why it is used.

Andi


At 07:14 PM 3/29/2001 +0100, James Moore wrote:
Ive been having a play with fastcgi under win32 and what ever I do I seem to
get the following errors:

Compiling...
fastcgi.c
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(103) : warning C4101: 'tmp' :
unreferenced local variable
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(181) : error C2065: 'sapi_globals' :
undeclared identifier
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(181) : error C2223: left of
'-request_info' must point to struct/union
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(185) : warning C4047: 'function' :
'struct sapi_globals_struct *' differs in levels of indirection from 'int '
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(185) : warning C4024:
'php_request_startup' : different types for formal and actual parameter 4
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(219) : warning C4013: 'S_ISREG'
undefined; assuming extern returning int
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(259) : error C2223: left of
'-server_context' must point to struct/union
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(264) : error C2223: left of
'-server_context' must point to struct/union
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(350) : warning C4013: 'fork'
undefined; assuming extern returning int
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(370) : warning C4013: 'wait'
undefined; assuming extern returning int
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(403) : error C2143: syntax error :
missing ')' before ','
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(403) : error C2198:
'init_request_info' : too few actual parameters
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(403) : error C2059: syntax error :
')'
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(404) : error C2223: left of
'-server_context' must point to struct/union
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(405) : error C2065:
'compiler_globals' : undeclared identifier
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(406) : error C2223: left of
'-request_info' must point to struct/union
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(409) : error C2143: syntax error :
missing ')' before ','
D:\php-4.0.5RC4\sapi\fastcgi\fastcgi.c(409) : error C2059: syntax error :
')'
Error executing cl.exe.

Is this just me being totally stupid and not defining somthing I should or
is there actually somthing wrong? or wont it work on win32?

James
--
James Moore
[EMAIL PROTECTED]
PHP Web Scripting: http://www.php.net/
PHP QA Team: http://qa.php.net/
PHP-GTK: http://gtk.php.net/
VL-SRM: http://www.vl-srm.net/


--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]


-- 
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]




Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems

2001-04-01 Thread Andi Gutmans

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?

2001-04-01 Thread Andi Gutmans

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] mail.c

2001-04-02 Thread Andi Gutmans

Seems to me like these lines can be erased. ext/standard is always compiled 
in and doesn't really need ZEND_GET_MODULE() and in any case 
ZEND_GET_MODULE(odbc) seems bogus :)

Andi

At 04:35 PM 4/2/2001 +0100, James Moore wrote:
I was just reading through mail.c and this stuck out to me as seeming a
little strange.. can anyone explain it??

(lines 43-46)
#ifdef COMPILE_DL_STANDARD
ZEND_GET_MODULE(odbc)
#endif

Why is it odbc? is this a careless ctrl-c ctrl-v someone has done or should
it actually be this?

cheers,

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] PHP 4.0.5 Release Candidate testing

2001-04-02 Thread Andi Gutmans

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

2001-04-02 Thread Andi Gutmans

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?

2001-04-02 Thread Andi Gutmans

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

2001-04-02 Thread Andi Gutmans

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

2001-04-02 Thread Andi Gutmans

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!

2001-04-02 Thread Andi Gutmans

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

2001-04-03 Thread Andi Gutmans

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

2001-04-03 Thread Andi Gutmans

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

2001-04-03 Thread Andi Gutmans

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

2001-04-03 Thread Andi Gutmans

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

2001-04-03 Thread Andi Gutmans

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

2001-04-03 Thread Andi Gutmans

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

2001-04-03 Thread Andi Gutmans

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]




  1   2   3   4   5   6   7   8   9   10   >