[PHP-DEV] PHP 4.0 Bug #9783 Updated: dirname()

[andre]

ID: 9783
Updated by: andre
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Assigned
Bug Type: Filesystem function related
Assigned To: andre
Comments:

this seems to be a bug

Previous Comments:
---

[2001-03-16 06:44:10] [EMAIL PROTECTED]
echo dirname("c:/fuck/abc/");
prints out c:/fuck


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9783&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9859: mail() doesn't send cc or bcc as in the manual instructions

[joel]

From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0
PHP version:  4.0.4pl1
PHP Bug Type: Documentation problem
Bug description:  mail() doesn't send cc or bcc as in the manual instructions

script example:
-



the mail was sent?
returnvar= $returnvar";
?>


-
The above does not send the carbon copy.

The pdf manual says:
--
$headers .= "cc:[EMAIL PROTECTED]\n"; // CC to
$headers .= "bcc:[EMAIL PROTECTED], [EMAIL PROTECTED]\n"; // BCCs to
/* and now mail it */
mail($recipient, $subject, $message, $headers);
---

That does not work since Win32 sendmail.c looks for case sensitve "Cc:"
sendmail.c also does not look for "bcc:"

Also you must have "\r\n" not just "\n".

I think the problem is here in win32 sendmail.c :

if (headers && (pos1 = strstr(headers, "Cc:"))) {
pos2 = strstr(pos1, "\r\n");
tempMailTo = estrndup(pos1, pos2-pos1);




-- 
Edit Bug report at: http://bugs.php.net/?id=9859&edit=1



-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgard config.m4)

[Alexander Bokovoy]

On Tue, Mar 20, 2001 at 01:00:15AM +0100, Jani Taskinen wrote:
> On Mon, 19 Mar 2001, Rasmus Lerdorf wrote:
> >Having midgard in the PEAR infrastructure makes sense once the PEAR
> >infrastructure is such that it is easy to install PEAR components that
> >include C bits.  And yes, perhaps the midgard folks are the right people
> >to push this along, if they are willing and able.
> 
> Isn't php-gtk done like the way the PEAR (C) components should be done?
> At least that's how I compiled that extension. Separately from PHP.
> Using phpize. So I would guess having e.g. midgard outside PHP shouldn't
> matter at all?
Before separating PEAR from PHP CVS several serious problems should be solved.
First and main problem is the building environment. I've already did a post
on php-dev@ which describes this problem several weeks ago so I'll just outline
a problem: if extension uses several PHP_ARG_WITH or PHP_ENABLE to tune
behaviour (=which part to compile in), all of them will be compiled in regardless
of user selection. That's due erroreous code which decides that if $php_always_shared
set to 'yes', then all $PHP_BLAH should be set to 'yes'.

> >Another motivator is the readline extension.  Get that into PEAR as a
> >separate easily installable PEAR component and make it LGPL'ed and we
> >avoid any Stallman hassles on that particular extension.
> 
> True, true. :)
Readline is an example of such extension which fail to compile right now
as self contained extension (PEAR module).

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |Aurora R&D team 
Minsk Linux Users Group |www.minsk-lug.net|  www.aurora-linux.com  
ALT Linux Team  |www.alt-linux.org| Architecte Open Source
-- Dijkstra probably hates me
(Linus Torvalds, in kernel/sched.c)

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9858: mail() still doesn't send cc

[joel]

From: [EMAIL PROTECTED]
Operating system: Windows NT 4.0
PHP version:  4.0.4pl1
PHP Bug Type: Performance problem
Bug description:  mail() still doesn't send cc

script example:
-



the mail was sent?
returnvar= $returnvar";
?>


-
The above does not send the carbon copy.

I think the problem is here in win32 sendmail.c :

if (headers && (pos1 = strstr(headers, "Cc:"))) {
pos2 = strstr(pos1, "\r\n");
tempMailTo = estrndup(pos1, pos2-pos1);

Should be  tempMailTo = estrndup(pos1+2, pos2-pos1); 
I think since the pos of "Cc: would give the position of the first C in "Cc:".
"headers" should also be made all upper case to catch the "cc" or the "CC"





-- 
Edit Bug report at: http://bugs.php.net/?id=9858&edit=1



-- 
PHP Development Mailing List 
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] Whither 4.0.5 RC2?

[André Langhorst]

Joey Smith wrote:

> Are we going to have a second RC?

I was just about to ask the same, I did not thoroughly monitor, but I 
guess zeev did not commit the ob fixes yet

andré

-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9857: define("named_constant")

[shmengie_2000]

From: [EMAIL PROTECTED]
Operating system: winNT IIS4
PHP version:  4.0.1
PHP Bug Type: IIS related
Bug description:  define("named_constant")

With this code at the top of an include file, the results are unpretictable.

if(!defined("METABASE_MYSQL_INCLUDED"))
{
 define("METABASE_MYSQL_INCLUDED",1);
 ...rest of include file...
}

require_once(); seems to work though.



-- 
Edit Bug report at: http://bugs.php.net/?id=9857&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Whither 4.0.5 RC2?

[Joey Smith]

Are we going to have a second RC?


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] QA for mozilla

[André Langhorst]

Hi,
Mozilla currently is in its QA phase for 0.8.1 and could benefit from 
the variety of systems and OSses php developers run, I guess.

Anyone who already uses mozilla or wants to help an open-source project 
in a (close-to-)final stage, should check out one or more builds (daily 
snapshots) from
http://ftp.mozilla.org/pub/mozilla/nightly/latest-0.8.1/

If you encounter any problems, look if bugzilla knows them already (be 
sure to read the notes how to create a bug report) and if not file a new 
bug.
You can use this form to create a bug:
http://www.mozilla.org/quality/help/bug-form.html


Note:
I plan to post this again at least 2 times (until 1.0 is out) in the 
next 2,5 months (mozilla has 5 week cycles) to remind to test the 0.9 
and 1.0(maybe 0.9.1) RCs. If you think this is a bad idea respond to me 
privately.

Thanks,
andré





-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9856: Missing run path in shared object library

[bill . roberts]

From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version:  4.0.4pl1
PHP Bug Type: *Install and Config
Bug description:  Missing run path in shared object library

The libtool call at the end of the build lists a lot of -R directives to the build to 
put the run path in libphp4.so, but the run path is not there.  I ran libtool without 
the --silent to see what it was doing and got this:

mizar/bin/sh /data/mizar1/bill/php-4.0.4pl1/libtool 
 --mode=link cc  -I. -I/data/mizar1/bill/php-4.0.4pl1/ -I/data/mizar1/bill/php-4.0
.4pl1/main -I/data/mizar1/bill/php-4.0.4pl1 -I/usr/local/apache_1.3.19/include -I/
data/mizar1/bill/php-4.0.4pl1/Zend -I/usr/local/ssl/include -I/usr/local/ldap/incl
ude -I/usr/local/mysql/include/mysql -I/data/mizar1/bill/php-4.0.4pl1/ext/xml/expa
t/xmltok -I/data/mizar1/bill/php-4.0.4pl1/ext/xml/expat/xmlparse -I/usr/local/incl
ude -I/data/mizar1/bill/php-4.0.4pl1/TSRM  -D_POSIX_PTHREAD_SEMANTICS -DSOLARIS2=2
80 -DMOD_SSL=208101 -DEAPI -DUSE_EXPAT -DSHARED_CORE -DHAVE_NSLDAP -DXML_BYTE_ORDE
R=21 -xO3 -I/usr/local/ssl -DHAVE_NSLDAP -I/usr/include   -o libphp4.la -rpath /da
ta/mizar1/bill/php-4.0.4pl1/libs -avoid-version -L/usr/ucblib -L/usr/local/ssl/lib
 -L/usr/local/ldap/lib -L/usr/local/mysql/lib/mysql -L/usr/local/lib  -R /usr/ucbl
ib -R /usr/local/ssl/lib -R /usr/local/ldap/lib -R /usr/local/mysql/lib/mysql -R /
usr/local/lib stub.lo  Zend/libZend.la  sapi/apache/libsapi.la  main/libmain.la  r
egex/libregex.la  ext/ldap/libldap.la ext/mysql/libmysql.la ext/openssl/libopenssl
.la ext/pcre/libpcre.la ext/posix/libposix.la ext/session/libsession.la ext/standa
rd/libstandard.la ext/xml/libxml.la ext/zlib/libzlib.la  TSRM/libtsrm.la -lpam -ld
l -lz -lmysqlclient -lldap -llber -lcrypto -lssl -lresolv -lresolv -lm -ldl -lcryp
t -lnsl -lsocket -lsocket


rm -fr .libs/libphp4.la .libs/libphp4.* .libs/libphp4.*


/usr/ccs/bin/ld -G -h libphp4.so -o .libs/libphp4.so  stub.lo -z allextract 
Zend/.libs/libZend.al sapi/apache/.libs/libsapi.al main/.libs/libmain.al 
regex/.libs/libregex.al ext/ldap/.libs/libldap.al ext/mysql/.libs/libmysql.al 
ext/openssl/.libs/libopenssl.al ext/pcre/.libs/libpcre.al ext/posix/.libs/libposix.al 
ext/session/.libs/libsession.al ext/standard/.libs/libstandard.al 
ext/xml/.libs/libxml.al ext/zlib/.libs/libzlib.al TSRM/.libs/libtsrm.al -z 
defaultextract  -L/usr/ucblib -L/usr/local/ssl/lib -L/usr/local/ldap/lib 
-L/usr/local/mysql/lib/mysql -L/usr/local/lib -lpam -ldl -lz -lmysqlclient -lldap 
-llber -lcrypto -lssl -lresolv -lresolv -lm -ldl -lcrypt -lnsl -lsocket -lsocket -lpam 
-ldl -lz -lmysqlclient -lldap -llber -lcrypto -lssl -lresolv -lresolv -lm -ldl -lcrypt 
-lnsl -lsocket -lsocket -lc 
creating libphp4.la
(cd .libs && rm -f libphp4.la && ln -s ../libphp4.la libphp4.la)

Note there are no -R directives in the generated ld command.  This leads to:

mizarldd -s .libs/libphp4.so

   find library=.libs/libphp4.so; required by /usr/lib/lddstub

   find library=libpam.so.1; required by .libs/libphp4.so
search path=/usr/lib  (default)
trying path=/usr/lib/libpam.so.1
libpam.so.1 =>   /usr/lib/libpam.so.1

   find library=libdl.so.1; required by .libs/libphp4.so
search path=/usr/lib  (default)
trying path=/usr/lib/libdl.so.1
libdl.so.1 =>/usr/lib/libdl.so.1

   find library=libz.so; required by .libs/libphp4.so
search path=/usr/lib  (default)
trying path=/usr/lib/libz.so
libz.so =>   /usr/lib/libz.so

   find library=libmysqlclient.so.6; required by .libs/libphp4.so
search path=/usr/lib  (default)
trying path=/usr/lib/libmysqlclient.so.6
libmysqlclient.so.6 =>   (file not found)

... other stuff deleted...

i.e. libmysqlclient.so.6 is not found

Note:  I had no LD_LIBRARY_PATH set 

mysql is installed as /usr/local/mysql

I eventually fixed this by cutting and pasting the generated ld command and adding the 
necessary -R directives


-- 
Edit Bug report at: http://bugs.php.net/?id=9856&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Andi 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 
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

[Jon Parise]

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

[Jon Parise]

On Mon, Mar 19, 2001 at 11:27:09PM +0200, Zeev Suraski wrote:

> What is iseverythingelse()?  I don't think we have any other 
> iseverythingelse() function.
 
I'd assume Lars is referring to the is_{type} functions:

http://www.php.net/manual/en/ref.var.php

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9855: Return column data with correct type

[ron . baldwin]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.0.4pl1
PHP Bug Type: MSSQL related
Bug description:  Return column data with correct type

Suggestion:

Add new data retrieval functions (or extend mssql_fetch_array and mssql_fetch_row) to 
return each column in a type that matches the underlying database column type instead 
of the always as type string.  Also, return columns that are NULL as PHP's null type 
(instead of boolean/false).

Two questions - is this the proper place to submit suggestions, and if so should this 
also be submitted to the general 'database functions' category (I know PHP's ODBC 
functions exhibit the same behavior)?



-- 
Edit Bug report at: http://bugs.php.net/?id=9855&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9854 Updated: Empty strings get returned as single spaces

[ron . baldwin]

ID: 9854
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: MSSQL related
Description: Empty strings get returned as single spaces

Add'l info:

Web Server:
   Win2000 Server SP1
   IIS 5.0
   PHP 4.0.4pl1

Database Server:
   WinNT SP6
   MSSQL 7.0

Previous Comments:
---

[2001-03-19 23:42:49] [EMAIL PROTECTED]
mssql_fetch_array (and mssql_fetch_row) return a single space for columns that contain 
an empty string (as opposed to columns that contain NULL).

---


Full Bug description available at: http://bugs.php.net/?id=9854


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9854: Empty strings get returned as single spaces

[ron . baldwin]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.0.4pl1
PHP Bug Type: MSSQL related
Bug description:  Empty strings get returned as single spaces

mssql_fetch_array (and mssql_fetch_row) return a single space for columns that contain 
an empty string (as opposed to columns that contain NULL).


-- 
Edit Bug report at: http://bugs.php.net/?id=9854&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9853: pg_cmdtuples function does not exist

[chriskl]

From: [EMAIL PROTECTED]
Operating system: Win2K
PHP version:  4.0.4pl1
PHP Bug Type: PostgreSQL related
Bug description:  pg_cmdtuples function does not exist

The pg_cmdtuples function does not exist in the pgsql.dll supplied with the windows 
version of PHP.  This is disastrous for applications that need that functionality!!

Chris



-- 
Edit Bug report at: http://bugs.php.net/?id=9853&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9852: Header redirect and db connection cause "CGI misbehaved"

[ron . baldwin]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.0.4pl1
PHP Bug Type: IIS related
Bug description:  Header redirect and db connection cause "CGI misbehaved"

Under the category of "You Can Never Have Too Much Information On A Bug", here is my 
experience with the "CGI App Misbehaved" bug (related bug reports: #8571 and #8744).

Bug report summary:
A PHP script that sends a 'Location' header directive and makes a database connection 
causes IIS to intermittently return a 'Gateway Error 502' when the client browser asks 
for the page specified in the redirect.  The address bar will correctly show the page 
that should have loaded when the error is displayed, and pressing F5 (refresh) will 
correctly load the page.  Note that the error is (seemingly) completely random, 
sometimes you get it, other times the script works correctly.  The error message text 
is:

   -- Begin --
   CGI Error
   The specified CGI application misbehaved by not returning a complete set of HTTP 
headers. The headers it did return are:
   --  End  --

This error depends on:
1) Using PHP in CGI mode (i.e. using php.exe, the ISAPI dll does not seem to produce 
this error, although it has it's own problems).
2) A PHP script that connects to a database (tested both mssql_connect and 
odbc_connect) *and* sends a 'Location:' header.  If the script redirects to something 
other than a .php file (i.e. .html or .pdf) or does not connect to the database, the 
error will not occur.
3) A successful db connection.  If the db connect call fails (due to bad password, 
etc.), the redirect always works.

This error does *not* depend on:
1) A fully qualified 'Location' header.  The following also fails:
   header('Location: http://10.0.0.30/test/done.php');
2) The relative order of the header() and xxx_connect() calls in 'doit.php'.  I 
wouldn't expect the order to affect the result, but I checked it anyway.

Interesting note: While upgrading the server to SP1 to see if it had any affect on 
this bug, I continued to test while it was in the process of performing the upgrade.  
It was very difficult (I gave up) trying to get the error.  The CPU was at 100% due to 
the upgrade which (obviously) caused the web server performance to suffer.  Combined 
with the fact that it occurs randomly anyway, this suggests that it may have something 
to do with the timings between the request for doit.php, execution of doit.php, and 
the request for done.php.


Hardware/Software:
   Web server:
  Win2000 Server (with and without SP1)
  IIS 5.0
  PHP 4.0.4pl1 (CGI mode)

   Database server:
  WinNT 4.0 SP6
  MS-SQL 7.0

   Client:
  Win2000 Professional SP1
  IE 5.5 SP1



Test scripts

start.php

Test

Do test


doit.php



done.php

Test

Test complete
Reset test



Here are actual HTTP headers recorded using a packet sniffer:


Scenario #1 - CGI Error Occurs

Client request

GET /test/doit.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, 
application/msword, */*
Referer: http://10.0.0.30/test/start.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: 10.0.0.30
Connection: Keep-Alive

Server response

HTTP/1.1 302 Object Moved
Location: done.php
Server: Microsoft-IIS/5.0
Content-Type: text/html
Connection: close
Content-Length: 131

Client request (automatic IE request)

GET /test/done.php HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, 
application/msword, */*
Referer: http://10.0.0.30/test/start.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: 10.0.0.30
Connection: Keep-Alive

Server response (Incorrect response)

HTTP/1.1 502 Gateway Error
Server: Microsoft-IIS/5.0
Date: Tue, 20 Mar 2001 00:30:10 GMT
Connection: close
Content-Length: 215
Content-Type: text/html

Client request (F5 - refresh)

GET /test/done.php HTTP/1.1
Accept: */*
Referer: http://10.0.0.30/test/start.php
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Host: 10.0.0.30
C

[PHP-DEV] PHP 4.0 Bug #9851: getenv() functions do not return variables.

[kabal]

From: [EMAIL PROTECTED]
Operating system: Solaris 2.6/2.7 
PHP version:  4.0.3pl1
PHP Bug Type: Other web server
Bug description:  getenv() functions do not return variables.

The getenv() function does not return a value.

machine info:

[root@wink]# uname -a
SunOS wink 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-2
[root@wink]# php -v
4.0.3pl1

Netscape-Enterprise/3.6 SP3 B99.280.0054


sample code:

\n");
print (" $sn  $SCRIPT_NAME \n");
print ("$ra  $REMOTE_ADDR \n");
print (" $ip $IP \n"); 
print ("$rmh $test \n") ;
print ("$myhost $host\n\n\n");
print ("$IPGET  $IP\n");
print ("$HTTPGET $http_ref\n");
print ("$SCTEST $scname\n");

?>

for example $test retuns the correct value while $IP does not.  This also works fine 
with apache but not with Netscape. 


-- 
Edit Bug report at: http://bugs.php.net/?id=9851&edit=1



-- 
PHP Development Mailing List 
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] Extension help

[Sterling Hughes]

On Mon, 19 Mar 2001, Barry Mitchelson wrote:

> hey,
> 
> I'm writing an extension which defines a class.  In the constructor, I'd like to 
>create a member variable which I can then access with the other member functions in 
>my extension.
> 
> In php it would be like :
> 
> class foo
> {
> 
>   var $m_bar;
> 
>   function foo()
>   {
>   $this->m_bar = 123;
>   }
> 
>   function a()
>   {
>   return $this->m_bar;
>   }
> 
> }
>

look at adding it to the value.obj.properties of the class (its a
HashTable).

-Sterling


-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4/ext/midgard config.m4)

[Jani Taskinen]

On Tue, 20 Mar 2001, Emiliano wrote:

>Zeev Suraski wrote:
>>
>> At 02:04 20/3/2001, Rasmus Lerdorf wrote:
>> >No, we need tighter integration.  We want to be able to do something along
>> >the lines of "pear pear.php.net/midgard" and it would go and fetch
>> >the the component, build it and install it.
>>
>> I completely agree with Andi about this.  If it won't be simple, it will
>> simply not be.  We can start simple, and work our way up.
>
>For unixoids, this could probably be a glue script that uses CVS.
>There'd
>probably need to be checkin-time phpize setup or somesuch to make it
>distribution-ready, or people would need autoconf et al on their systems
>allways.
>
>I don't know how this would work for windows system, though.

CVS is not needed here..
I'd like to see something like the RPMs or debian .deps work:

# pear --install cms:midgard
# pear --install payment:verisign
# pear --update cms:midgard
.
.

# pear --update all
# pear --remove

Of course there should be some package info file for each extension,
be it C or PHP one, ie. dependancy info, what the extension provides, etc.
So that the packages depending on some other extension could be
identified and produce some warning if the already installed packages
don't provide what the to be installed one needs..

Maybe there already is something like this in the works? I'm not on any
of the pear mailing lists so I don't know. :(

(Cc: to the pear-dev list)

--Jani



-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgardconfig.m4)

[Rasmus Lerdorf]

> That's great, but it shouldn't be the starting point for the project...
> Jani is right that whenever we speak about separating PEAR, or putting
> extensions in it, it's always at some point in the future.  Opensource
> projects usually start up and roll once they reach some critical mass, and
> waiting for a certain particular development to happen isn't usually
> beneficial.  If there'll be people working on PEAR modules, the incentive
> for the 'pear' utility author will be much higher to make it work, and he
> may also have some support from others.  It's been 14 months since PEAR was
> born, I think it may be a good idea to try and let it walk a bit.

Sure, it's not like anybody is turning away code contributions.  If
someone has an idea for this PEAR infrastructure, it is more than welcome.

-Rasmus


-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgard config.m4)

[Zeev Suraski]

That's great, but it shouldn't be the starting point for the project... 
Jani is right that whenever we speak about separating PEAR, or putting 
extensions in it, it's always at some point in the future.  Opensource 
projects usually start up and roll once they reach some critical mass, and 
waiting for a certain particular development to happen isn't usually 
beneficial.  If there'll be people working on PEAR modules, the incentive 
for the 'pear' utility author will be much higher to make it work, and he 
may also have some support from others.  It's been 14 months since PEAR was 
born, I think it may be a good idea to try and let it walk a bit.

Zeev

At 02:11 20/3/2001, Rasmus Lerdorf wrote:
>See pear/scripts/pear
>
>The framework is there.
>
>On Tue, 20 Mar 2001, Zeev Suraski wrote:
>
> > At 02:04 20/3/2001, Rasmus Lerdorf wrote:
> > >No, we need tighter integration.  We want to be able to do something along
> > >the lines of "pear pear.php.net/midgard" and it would go and fetch
> > >the the component, build it and install it.
> >
> > I completely agree with Andi about this.  If it won't be simple, it will
> > simply not be.  We can start simple, and work our way up.
> >
> > Zeev
> >

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4/ext/midgard config.m4)

[Rasmus Lerdorf]

> Zeev Suraski wrote:
> >
> > At 02:04 20/3/2001, Rasmus Lerdorf wrote:
> > >No, we need tighter integration.  We want to be able to do something along
> > >the lines of "pear pear.php.net/midgard" and it would go and fetch
> > >the the component, build it and install it.
> >
> > I completely agree with Andi about this.  If it won't be simple, it will
> > simply not be.  We can start simple, and work our way up.
>
> For unixoids, this could probably be a glue script that uses CVS.
> There'd
> probably need to be checkin-time phpize setup or somesuch to make it
> distribution-ready, or people would need autoconf et al on their systems
> allways.
>
> I don't know how this would work for windows system, though.

Well, just like the snapshots at snaps.php.net, any C extensions should be
pre-autoconfed and should not require it on the user end.  And no, we
don't want to do software distribution via cvs.  Straight HTTP should be
fine.

-Rasmus


-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4/ext/midgard config.m4)

[Emiliano]

Zeev Suraski wrote:
> 
> At 02:04 20/3/2001, Rasmus Lerdorf wrote:
> >No, we need tighter integration.  We want to be able to do something along
> >the lines of "pear pear.php.net/midgard" and it would go and fetch
> >the the component, build it and install it.
> 
> I completely agree with Andi about this.  If it won't be simple, it will
> simply not be.  We can start simple, and work our way up.

For unixoids, this could probably be a glue script that uses CVS.
There'd
probably need to be checkin-time phpize setup or somesuch to make it
distribution-ready, or people would need autoconf et al on their systems
allways.

I don't know how this would work for windows system, though.

Emile

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9850 Updated: Apache dies

[sniper]

ID: 9850
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Apache related
Assigned To: 
Comments:

1. delete config.cache
2. add --enable-debug into your configure line
3. after configure: 'make clean ; make ; make install'
4. then try generating gdb backtrace:

# gdb /path/to/httpsd
(gdb) run -X

And then (if) it crashes:
(gdb) bt

and copy/paste the output into this bug report using the
web interface.

--Jani
 

Previous Comments:
---

[2001-03-19 19:06:36] [EMAIL PROTECTED]
I am trying to upgrade from php-4.02 and have this problem. Below are the specs on my 
system. It works
find with 4.02, but when I use the exact same procedure to build-4.04p1 the following 
happens.
./configure, make and make install on php complete without errors. httpsd starts and 
immediately dies
with no error messages and nothing has been found in any logs.
When I say it starts and dies I mean:

./httpsd start

gives an OK but

ps -aux|grep ht 

shows no httpd processes running no matter how fast I type but

./httpsd start;ps -aux|grep ht

shows 10 httpd processes, but will have dies before they can be tested again.  
 

The only variable would seem to be the difference between 4.02 and 4.04p1. After a 
careful look at the
requirements and dependency I can't fine the cause. Unfotunately php.net doesn't seem 
to make earlier
versions so I can't same how matters stand on 4.03 (Does anybody have this?).

 
The system is running Red Hat 6.2 with updates
linux kernel 2.2.17-14smp
Apache is RH secure server 3.1.2
glibc 2.1.3-22
   
   
The php configure command line use for both 4.02 and 4.04p1 is:
   
./configure --with-apxs --with-kerberos=/usr/kerberos/ --with-imap --with-mysql 
--with-ldap

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9850&edit=2


-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgardconfig.m4)

[Rasmus Lerdorf]

See pear/scripts/pear

The framework is there.

On Tue, 20 Mar 2001, Zeev Suraski wrote:

> At 02:04 20/3/2001, Rasmus Lerdorf wrote:
> >No, we need tighter integration.  We want to be able to do something along
> >the lines of "pear pear.php.net/midgard" and it would go and fetch
> >the the component, build it and install it.
>
> I completely agree with Andi about this.  If it won't be simple, it will
> simply not be.  We can start simple, and work our way up.
>
> Zeev
>


-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgard config.m4)

[Zeev Suraski]

At 02:04 20/3/2001, Rasmus Lerdorf wrote:
>No, we need tighter integration.  We want to be able to do something along
>the lines of "pear pear.php.net/midgard" and it would go and fetch
>the the component, build it and install it.

I completely agree with Andi about this.  If it won't be simple, it will 
simply not be.  We can start simple, and work our way up.

Zeev


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9850: Apache dies

[cjc]

From: [EMAIL PROTECTED]
Operating system: Red Hat, 6.2 linux 2.2.17-14smp
PHP version:  4.0.4pl1
PHP Bug Type: Apache related
Bug description:  Apache dies

I am trying to upgrade from php-4.02 and have this problem. Below are the specs on my 
system. It works
find with 4.02, but when I use the exact same procedure to build-4.04p1 the following 
happens.
./configure, make and make install on php complete without errors. httpsd starts and 
immediately dies
with no error messages and nothing has been found in any logs.
When I say it starts and dies I mean:

./httpsd start

gives an OK but

ps -aux|grep ht 

shows no httpd processes running no matter how fast I type but

./httpsd start;ps -aux|grep ht

shows 10 httpd processes, but will have dies before they can be tested again.  
 

The only variable would seem to be the difference between 4.02 and 4.04p1. After a 
careful look at the
requirements and dependency I can't fine the cause. Unfotunately php.net doesn't seem 
to make earlier
versions so I can't same how matters stand on 4.03 (Does anybody have this?).

 
The system is running Red Hat 6.2 with updates
linux kernel 2.2.17-14smp
Apache is RH secure server 3.1.2
glibc 2.1.3-22
   
   
The php configure command line use for both 4.02 and 4.04p1 is:
   
./configure --with-apxs --with-kerberos=/usr/kerberos/ --with-imap --with-mysql 
--with-ldap


-- 
Edit Bug report at: http://bugs.php.net/?id=9850&edit=1



-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgardconfig.m4)

[Rasmus Lerdorf]

> On Mon, 19 Mar 2001, Rasmus Lerdorf wrote:
>
> >Because the whole point of this was to make life easier on midgard users.
>
> So you're saying that every widely used external (at the moment)
> php-extension should be put into PHP CVS? :)

If it will help users and there is demand for it, sure.  Like the imlib2
extension for example.  That probably should be in PHP CVS.

> Isn't php-gtk done like the way the PEAR (C) components should be done?
> At least that's how I compiled that extension. Separately from PHP.
> Using phpize. So I would guess having e.g. midgard outside PHP shouldn't
> matter at all?

No, we need tighter integration.  We want to be able to do something along
the lines of "pear pear.php.net/midgard" and it would go and fetch
the the component, build it and install it.

-Rasmus


-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgardconfig.m4)

[Jani Taskinen]

On Mon, 19 Mar 2001, Rasmus Lerdorf wrote:

>Because the whole point of this was to make life easier on midgard users.

So you're saying that every widely used external (at the moment)
php-extension should be put into PHP CVS? :)

>And there are a lot of them.  There are not a lot of php-gtk users out
>there, and people interested in php-gtk don't tend to need as much
>handholding as midgard users.

:)

>Having midgard in the PEAR infrastructure makes sense once the PEAR
>infrastructure is such that it is easy to install PEAR components that
>include C bits.  And yes, perhaps the midgard folks are the right people
>to push this along, if they are willing and able.

Isn't php-gtk done like the way the PEAR (C) components should be done?
At least that's how I compiled that extension. Separately from PHP.
Using phpize. So I would guess having e.g. midgard outside PHP shouldn't
matter at all?

>Another motivator is the readline extension.  Get that into PEAR as a
>separate easily installable PEAR component and make it LGPL'ed and we
>avoid any Stallman hassles on that particular extension.

True, true. :)

>I've been fiddling with a TiVo extension that would also fit better in
>PEAR than in the main PHP distribution.

And there are also these Windows-only extensions, com , dotnet (?),
printer. Hmm, now that I remember..IMO we should create some better tree
structure into the ext/ dir. ie.

ext/dbms/
  oci8
  mysql
  pgsql
  .
  .
ext/xml/
  sablot
  qtdom
  dom
  .
  .
ext/windows/
  :)

Or is this a bad idea?

--Jani


>On Tue, 20 Mar 2001, Jani Taskinen wrote:
>
>> On Mon, 19 Mar 2001, Rasmus Lerdorf wrote:
>>
>> >PEAR will be separate at some point, but let's not go overboard here.  The
>> >midgard stuff adds a total of 76K to the tar.gz file.  Big deal.
>>
>> I was talking in general, not only midgard. The pear stuff takes
>> a lot more than 76k..and this has been pushed further and further into
>> the future EVERY time it's talked about. So why not make it a separate
>> (pear) module in CVS now? It isn't something that HAS to be in, or is it?
>> And if we continue distributing it with PHP we never get PEAR to be
>> what it should be. If the answer still is "at some point", why not add
>> the php-gtk to the PHP distribution too? :) (I don't want that to happen..)
>>
>> --Jani
>>
>>
>>
>
>
>


-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgard config.m4)

[Emiliano]

Rasmus Lerdorf wrote:

> Having midgard in the PEAR infrastructure makes sense once the PEAR
> infrastructure is such that it is easy to install PEAR components that
> include C bits.  And yes, perhaps the midgard folks are the right people
> to push this along, if they are willing and able.

Someone called? Heck yes, willing. Able, most probably, with some
help on how to set up things right for PEAR.

Emile

-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgard config.m4)

[Zeev Suraski]

I agree.

At 01:33 20/3/2001, Jani Taskinen wrote:
>On Mon, 19 Mar 2001, Rasmus Lerdorf wrote:
>
> >PEAR will be separate at some point, but let's not go overboard here.  The
> >midgard stuff adds a total of 76K to the tar.gz file.  Big deal.
>
>I was talking in general, not only midgard. The pear stuff takes
>a lot more than 76k..and this has been pushed further and further into
>the future EVERY time it's talked about. So why not make it a separate
>(pear) module in CVS now? It isn't something that HAS to be in, or is it?
>And if we continue distributing it with PHP we never get PEAR to be
>what it should be. If the answer still is "at some point", why not add
>the php-gtk to the PHP distribution too? :) (I don't want that to happen..)
>
>--Jani

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
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: PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgard config.m4)

[Rasmus Lerdorf]

Because the whole point of this was to make life easier on midgard users.
And there are a lot of them.  There are not a lot of php-gtk users out
there, and people interested in php-gtk don't tend to need as much
handholding as midgard users.

Having midgard in the PEAR infrastructure makes sense once the PEAR
infrastructure is such that it is easy to install PEAR components that
include C bits.  And yes, perhaps the midgard folks are the right people
to push this along, if they are willing and able.

Another motivator is the readline extension.  Get that into PEAR as a
separate easily installable PEAR component and make it LGPL'ed and we
avoid any Stallman hassles on that particular extension.

I've been fiddling with a TiVo extension that would also fit better in
PEAR than in the main PHP distribution.

-Rasmus

On Tue, 20 Mar 2001, Jani Taskinen wrote:

> On Mon, 19 Mar 2001, Rasmus Lerdorf wrote:
>
> >PEAR will be separate at some point, but let's not go overboard here.  The
> >midgard stuff adds a total of 76K to the tar.gz file.  Big deal.
>
> I was talking in general, not only midgard. The pear stuff takes
> a lot more than 76k..and this has been pushed further and further into
> the future EVERY time it's talked about. So why not make it a separate
> (pear) module in CVS now? It isn't something that HAS to be in, or is it?
> And if we continue distributing it with PHP we never get PEAR to be
> what it should be. If the answer still is "at some point", why not add
> the php-gtk to the PHP distribution too? :) (I don't want that to happen..)
>
> --Jani
>
>
>


-- 
PHP Development Mailing List 
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] "Independent" comments on a bug.

[php4]

** Reply to note from Jani Taskinen <[EMAIL PROTECTED]> Sun, 18 Mar 2001 23:33:46 +0100 
(CET)

A few thoughts on this subject...


Anyone should be able to comment on any bug report.


Anyone who comments on a bug report (that is not a developer) should get
an email when the status of the bug changes, or a new comment is posted
to the bug.  The developers list might be subscribers to php-dev.


A special kind of comment, "Add me to the bug's interest list" should
be supported that does not trigger a message, and just adds you to the
list.


Anyone on the interest list for a bug that is declared a duplicate
should be added to the interest list for the bug that it duplicates so
that everyone interested in the problem gets notified when something
happens.  Duplicate email addresses should be eliminated.  An email
should be sent to the interest list of the duplicate telling them that
the bug is a duplicate, what bug it duplicates, and that they will still
be notified when anything changes.




Rick Widmer
Internet Marketing Specialists
http://www.developersdesk.com

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PEAR (was: Re: [PHP-CVS] cvs: php4 /ext/midgard config.m4)

[Jani Taskinen]

On Mon, 19 Mar 2001, Rasmus Lerdorf wrote:

>PEAR will be separate at some point, but let's not go overboard here.  The
>midgard stuff adds a total of 76K to the tar.gz file.  Big deal.

I was talking in general, not only midgard. The pear stuff takes
a lot more than 76k..and this has been pushed further and further into
the future EVERY time it's talked about. So why not make it a separate
(pear) module in CVS now? It isn't something that HAS to be in, or is it?
And if we continue distributing it with PHP we never get PEAR to be
what it should be. If the answer still is "at some point", why not add
the php-gtk to the PHP distribution too? :) (I don't want that to happen..)

--Jani




-- 
PHP Development Mailing List 
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 4.0 Bug #9849 Updated: Square boxes?

[Chris Newbill]

Those square boxes are shown when IE cannot find the character in the
particular font/language set.  If you enable "Install on demand" it will
usually prompt you to download the language pack for whatever language you
are trying to view.

-Chris

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, 19 March, 2001 4-27 pM
> To: Jason Gulledge; Bug Database
> Subject: Re: [PHP-DEV] Re: PHP 4.0 Bug #9849 Updated: Square boxes?
>
>
> On Mon, Mar 19, 2001 at 05:01:00PM -0600, Jason Gulledge wrote:
>
> >  This webpage is what I'm using to install php4 / Apache 1.3.19
> >  http://www.php.net/manual/kr/install.apache.php
> >  and there squares everywhere on the page from what I can see
>
> I have seen such square rectangles with M$ IE in the Japanese PHP manual.
> With Netscape it looks fine, but I don't understand it anyway. So use
> other browsers or play with the language settings for your favorite
> browser.
>
> -Egon
>
> > __ Reply Separator
> _
> > Subject: PHP 4.0 Bug #9849 Updated: Square boxes?
> > Author:  [EMAIL PROTECTED] (Bug Database) at INTERNET
> > Date:3/19/01 4:44 PM
> >
> >
> > ID: 9849
> > Updated by: torben
> > Reported By: [EMAIL PROTECTED]
> > Old-Status: Open
> > Status: Feedback
> > Bug Type: Documentation problem
> > Assigned To:
> > Comments:
> >
> > Um...which square boxes, exactly? :) The user notes, the
> > warnings, the tables, what? It sort of sounds like making the
> > boxes less square would solve your problem, but I honestly
> > doubt that it's square boxes which are causing your problem.
> >
> > Which information did you find useless and/or misleading? If
> > you can give us a better handle on the problems you're having
> > it'll be easier to fix.
> >
> > Thanks,
> >
> > Torben
> >
> > Previous Comments:
> >
> --
> -
> >
> > [2001-03-19 17:25:23] [EMAIL PROTECTED]
> > Is there a reason there are so many square blocks of useless
> data on this websit
> > e
> >
> >
> > I'm trying to install PHP/Apache and get a Core dump everytime
> I try to start Ap
> > ache. I think it may be due to  a step that's not clearly
> documented on the PHP
> > website because of these square boxes replacing actual, useful
> data [which I can
> > not see].
> >
> >
> --
> -
> >
> >
> >
> > ATTENTION! Do NOT reply to this email!
> > To reply, use the web interface found at
> http://bugs.php.net/?id=9849&edit=2
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
>
> --
> --
> LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/
> All known books about PHP and related books: http://php.net/books.php
> Concert Band of the University of Hohenheim: http://www.concert-band.de/
> First and second bestselling book in German: http://www.php-buch.de/
>
> --
> PHP Development Mailing List 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9845 Updated: win2k CRASH when PHP run on a localhost from IE

[sniper]

ID: 9845
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Reproduceable crash
Assigned To: 
Comments:

Not enough info.

--Jani


Previous Comments:
---

[2001-03-19 16:21:49] [EMAIL PROTECTED]
i think it hapends when you do include .. but because of the complete system crash 
(ONLY under IE .. with netscape it works fine) it is hard to trace the bug.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9845&edit=2


-- 
PHP Development Mailing List 
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 4.0 Bug #9849 Updated: Square boxes?

[eschmid+sic]

On Mon, Mar 19, 2001 at 05:01:00PM -0600, Jason Gulledge wrote:

>  This webpage is what I'm using to install php4 / Apache 1.3.19
>  http://www.php.net/manual/kr/install.apache.php
>  and there squares everywhere on the page from what I can see

I have seen such square rectangles with M$ IE in the Japanese PHP manual.
With Netscape it looks fine, but I don't understand it anyway. So use
other browsers or play with the language settings for your favorite
browser.

-Egon

> __ Reply Separator _
> Subject: PHP 4.0 Bug #9849 Updated: Square boxes?
> Author:  [EMAIL PROTECTED] (Bug Database) at INTERNET
> Date:3/19/01 4:44 PM
> 
> 
> ID: 9849
> Updated by: torben
> Reported By: [EMAIL PROTECTED] 
> Old-Status: Open
> Status: Feedback
> Bug Type: Documentation problem
> Assigned To:
> Comments:
>  
> Um...which square boxes, exactly? :) The user notes, the 
> warnings, the tables, what? It sort of sounds like making the 
> boxes less square would solve your problem, but I honestly 
> doubt that it's square boxes which are causing your problem.
>  
> Which information did you find useless and/or misleading? If 
> you can give us a better handle on the problems you're having 
> it'll be easier to fix.
>  
> Thanks,
>  
> Torben
>  
> Previous Comments:
> ---
>  
> [2001-03-19 17:25:23] [EMAIL PROTECTED]
> Is there a reason there are so many square blocks of useless data on this websit
> e
>  
>  
> I'm trying to install PHP/Apache and get a Core dump everytime I try to start Ap
> ache. I think it may be due to  a step that's not clearly documented on the PHP 
> website because of these square boxes replacing actual, useful data [which I can
> not see].
>  
> ---
>  
>  
>  
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=9849&edit=2
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 

-- 
-- 
LinuxTag, Stuttgart, Germany: July 5-8 2001: http://www.linuxtag.de/
All known books about PHP and related books: http://php.net/books.php 
Concert Band of the University of Hohenheim: http://www.concert-band.de/
First and second bestselling book in German: http://www.php-buch.de/

-- 
PHP Development Mailing List 
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

[Phil Driscoll]

Zeev said:
>Define 'change their behavior' though?

'change their behavior' === 'change their behavior' in a subtle way :)

> Almost all SQL functions take an
>optional argument which is the link id.  That is by design, and doesn't
>really mean anything here,

I'm not saying it does mean anything here - I cannot think of a sensible
extra argument to modify isset. What I am saying is that if I were not in
the middle of building a ceiling for my bathroom, I'm sure I could find
either an existing issomething or ext_issomething function which already
uses an optional extra argument, or at least, could use one to good effect.
Torben has picked up on what I'm getting at - all 'is' functions should work
the same way - this (IMHO) is much more important than a bit of useful
ad-hoc functionality. If it turns out that we can do this trick to all 'is'
functions without any problems, then great - do it, but do it to all of
them.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org




-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9849 Updated: Square boxes?

[sniper]

ID: 9849
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Bogus
Bug Type: Documentation problem
Assigned To: 
Comments:



Previous Comments:
---

[2001-03-19 17:25:23] [EMAIL PROTECTED]
Is there a reason there are so many square blocks of useless data on this website 


I'm trying to install PHP/Apache and get a Core dump everytime I try to start Apache. 
I think it may be due to  a step that's not clearly documented on the PHP website 
because of these square boxes replacing actual, useful data [which I cannot see].

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9849&edit=2


-- 
PHP Development Mailing List 
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 4.0 Bug #9849 Updated: Square boxes?

[Jason Gulledge]

 Nevermind...
 
 i replaced http://www.php.net/manual/kr/install.apache.php
 
 with   http://www.php.net/manual/en/install.apache.php
 
 Sorry for the waste of your time
 
 Jason


__ Reply Separator _
Subject: PHP 4.0 Bug #9849 Updated: Square boxes?
Author:  [EMAIL PROTECTED] (Bug Database) at INTERNET
Date:3/19/01 4:44 PM


ID: 9849
Updated by: torben
Reported By: [EMAIL PROTECTED] 
Old-Status: Open
Status: Feedback
Bug Type: Documentation problem
Assigned To:
Comments:
 
Um...which square boxes, exactly? :) The user notes, the 
warnings, the tables, what? It sort of sounds like making the 
boxes less square would solve your problem, but I honestly 
doubt that it's square boxes which are causing your problem.
 
Which information did you find useless and/or misleading? If 
you can give us a better handle on the problems you're having 
it'll be easier to fix.
 
Thanks,
 
Torben
 
Previous Comments:
---
 
[2001-03-19 17:25:23] [EMAIL PROTECTED]
Is there a reason there are so many square blocks of useless data on this websit
e
 
 
I'm trying to install PHP/Apache and get a Core dump everytime I try to start Ap
ache. I think it may be due to  a step that's not clearly documented on the PHP 
website because of these square boxes replacing actual, useful data [which I can
not see].
 
---
 
 
 
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9849&edit=2

-- 
PHP Development Mailing List 
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 4.0 Bug #9849 Updated: Square boxes?

[Jason Gulledge]

 This webpage is what I'm using to install php4 / Apache 1.3.19
 
 
 http://www.php.net/manual/kr/install.apache.php
 
 
 and there squares everywhere on the page from what I can see
 
 
 Jason


__ Reply Separator _
Subject: PHP 4.0 Bug #9849 Updated: Square boxes?
Author:  [EMAIL PROTECTED] (Bug Database) at INTERNET
Date:3/19/01 4:44 PM


ID: 9849
Updated by: torben
Reported By: [EMAIL PROTECTED] 
Old-Status: Open
Status: Feedback
Bug Type: Documentation problem
Assigned To:
Comments:
 
Um...which square boxes, exactly? :) The user notes, the 
warnings, the tables, what? It sort of sounds like making the 
boxes less square would solve your problem, but I honestly 
doubt that it's square boxes which are causing your problem.
 
Which information did you find useless and/or misleading? If 
you can give us a better handle on the problems you're having 
it'll be easier to fix.
 
Thanks,
 
Torben
 
Previous Comments:
---
 
[2001-03-19 17:25:23] [EMAIL PROTECTED]
Is there a reason there are so many square blocks of useless data on this websit
e
 
 
I'm trying to install PHP/Apache and get a Core dump everytime I try to start Ap
ache. I think it may be due to  a step that's not clearly documented on the PHP 
website because of these square boxes replacing actual, useful data [which I can
not see].
 
---
 
 
 
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9849&edit=2

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9849 Updated: Square boxes?

[torben]

ID: 9849
Updated by: torben
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Documentation problem
Assigned To: 
Comments:

Um...which square boxes, exactly? :) The user notes, the 
warnings, the tables, what? It sort of sounds like making the
boxes less square would solve your problem, but I honestly
doubt that it's square boxes which are causing your problem.

Which information did you find useless and/or misleading? If 
you can give us a better handle on the problems you're having
it'll be easier to fix.

Thanks,

Torben

Previous Comments:
---

[2001-03-19 17:25:23] [EMAIL PROTECTED]
Is there a reason there are so many square blocks of useless data on this website 


I'm trying to install PHP/Apache and get a Core dump everytime I try to start Apache. 
I think it may be due to  a step that's not clearly documented on the PHP website 
because of these square boxes replacing actual, useful data [which I cannot see].

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9849&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9849: Square boxes?

[jason . gulledge]

From: [EMAIL PROTECTED]
Operating system: WIn98 (IE)
PHP version:  4.0.4pl1
PHP Bug Type: Documentation problem
Bug description:  Square boxes?

Is there a reason there are so many square blocks of useless data on this website 


I'm trying to install PHP/Apache and get a Core dump everytime I try to start Apache. 
I think it may be due to  a step that's not clearly documented on the PHP website 
because of these square boxes replacing actual, useful data [which I cannot see].


-- 
Edit Bug report at: http://bugs.php.net/?id=9849&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9848: memory leak

[dean]

From: [EMAIL PROTECTED]
Operating system: Windows 98 SE
PHP version:  4.0.4pl1
PHP Bug Type: Performance problem
Bug description:  memory leak

Every time I get memory loss if  I run php.exe at the command line like this:
C:\>php index.html
I use "System Monitor" to check unused physical memory. No php code in index.html 
file, it's only a pure HTML file or a blank file.


-- 
Edit Bug report at: http://bugs.php.net/?id=9848&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9841 Updated: Undefined Function

[sniper]

ID: 9841
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: DBM/DBA related
Assigned To: 
Comments:

You're using the wrong functions.
Please read the manual pages for DBA:

http://www.php.net/manual/en/ref.dba.php

--Jani


Previous Comments:
---

[2001-03-19 16:41:19] [EMAIL PROTECTED]
You can look at:
http://www.qnet3arena.com/index.php <--- for phpinfo()
http://www.qnet3arena.com/phpdev/031601.php <--- for error
http://www.qnet3arena.com/phpdev/031601.phps <--- for source


yes is was enables and activated in configure.


Thank You

---

[2001-03-19 12:17:24] [EMAIL PROTECTED]
please have a look at your configure log and phpinfo() output

was [g]dbm support found and activated by configure?

---

[2001-03-19 12:09:36] [EMAIL PROTECTED]


./configure 
--with-mysql 
--with-apxs=/var/lib/apache/sbin/apxs
--with-gdbm




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9841&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Extension help

[Barry Mitchelson]

hey,

I'm writing an extension which defines a class.  In the constructor, I'd like to 
create a member variable which I can then access with the other member functions in my 
extension.

In php it would be like :

class foo
{

var $m_bar;

function foo()
{
$this->m_bar = 123;
}

function a()
{
return $this->m_bar;
}

}

but I can't figure out how to do it within the extension.

thanks,


barry

-- 
http://www.theshining.org

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9551 Updated: False boolen input/output doesn't work

[phanto]

ID: 9551
Updated by: phanto
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: COM related
Assigned To: 
Comments:

this is not a bug, this is how php handles booleans.

try echo gettype($COMOBJ->SetBoolean);
or echo (int)$COMOBJ->SetBoolean;
and you'll see that all is right :)


Previous Comments:
---

[2001-03-04 17:11:37] [EMAIL PROTECTED]
   $COMOBJ =New COM ("whatever");
$COMOBJ->SetBoolean= False;   #Or 0
$Test = $COMOBJ->SetBoolean;
Print "test=" . $Test;  
#$Test="" always empty
#Note: Set to True or 1 returns 1 and is OK



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9551&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9847: fopen() fails with Error 0 on Forbidden URLs

[bloch]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.4pl1
PHP Bug Type: Filesystem function related
Bug description:  fopen() fails with Error 0 on Forbidden URLs

Perhaps this belongs in the URL related 
functions.

When fopen()-ing an URL that responds
with an HTTP 403 Forbidden, fopen()
fails with an Error 0.   There is no
way to distinguish this error from
a 'Not Found' type of error.

Workaround is to use cURL.

Eric


-- 
Edit Bug report at: http://bugs.php.net/?id=9847&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9846: fopen() fails and gives Error 0 on NoContent URLs

[bloch]

From: [EMAIL PROTECTED]
Operating system: linux,irix,tru64
PHP version:  4.0.4pl1
PHP Bug Type: Filesystem function related
Bug description:  fopen() fails and gives Error 0 on NoContent URLs

This bug might belong in the URL-related section.
I believe it to be a generic problem.

If you fopen() an URL
that returns with an HTTP Header of NoContent (204),
fopen() will fail with Error 0.

Failure would be ok if there was a specific error
code for NoContent URLs.  Either that or returning
a handle that was already at eof would suffice.
As it is now, there's no way to tell the difference
between a bad (NotFound) URL and a NoContent URL.

Work-around it to use cURL to a temporary file
and check the HTTP_CODE with the undocumented
curl_getinfo() function.  Of course, it seems
a little weird to require the temporary file 
for a NoContent URL.  But it works fine.

-Eric Bloch
[EMAIL PROTECTED]



-- 
Edit Bug report at: http://bugs.php.net/?id=9846&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9841 Updated: Undefined Function

[donnaber]

ID: 9841
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: DBM/DBA related
Description: Undefined Function

You can look at:
http://www.qnet3arena.com/index.php <--- for phpinfo()
http://www.qnet3arena.com/phpdev/031601.php <--- for error
http://www.qnet3arena.com/phpdev/031601.phps <--- for source


yes is was enables and activated in configure.


Thank You

Previous Comments:
---

[2001-03-19 12:17:24] [EMAIL PROTECTED]
please have a look at your configure log and phpinfo() output

was [g]dbm support found and activated by configure?

---

[2001-03-19 12:09:36] [EMAIL PROTECTED]


./configure 
--with-mysql 
--with-apxs=/var/lib/apache/sbin/apxs
--with-gdbm




---


Full Bug description available at: http://bugs.php.net/?id=9841


-- 
PHP Development Mailing List 
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

[Lars Torben Wilson]

Zeev Suraski writes:
> What is iseverythingelse()?  I don't think we have any other 
> iseverythingelse() function.
> 
> The fact isset() is a language construct does make a serious 
> difference.  It already is very different from functions, and not in its 
> underlying implementation but its semantics.
> 
> Zeev

If it can be changed like that and be safe and consistent then that's
great. If it makes people's lives better without confusion then that's
perfect. Just as long as it's been considered then I'm happy.

> At 23:21 19/3/2001, Lars Torben Wilson wrote:
> >Jason Greene writes:
> > > > Generally using functions for two different purposes is a bad idea, but
> > > > enhancing functions with additional arguments that extend its 
> > functionality
> > > > is not too bad.  In this case, adding n arguments is perhaps the 
> > extension
> > > > that makes the most sense for isset(), so we should go with 
> > it.  Keeping it
> > > > with one argument 'for future use' doesn't make much sense in my
> > > > opinion.  Not any more sense than saying the same thing about some new
> > > > argument someone might want to add to it in the future - why not keep it
> > > > clean and wait for a 'better' use?
> > > >
> > > > Zeev
> > >
> > > I agree, this is something thats had more thought put into it than it 
> > really needed.
> > > This functionality very much fits issets nature - something goes in and 
> > 0/1 comes
> > > out. There really is no reason to not implement the request.
> > >
> > > -Jason
> >
> >Well, Phil is right in that if isset() is changed then
> >iseverythingelse() also needs to be examined and if necessary and
> >possible changed to suit. Otherwise we'll be fielding questions about
> >'well it works this way for *this* function, why not this one?' for
> >years. The same question. Over and over and over. Because if the
> >language itself isn't consistent then no number of FAQs and manual
> >notes will prevent people from stubbing their toes.
> >
> >I think that too much thought has most definitely *not* been put into
> >this issue--the effect on the whole language needs to be considered,
> >not just isset(). Just IMHO, of course.
> >
> >
> >--
> >++
> >|Torben Wilson <[EMAIL PROTECTED]>Adcore Finland|
> >|http://www.coastnet.com/~torbenhttp://www.adcore.com|
> >|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
> >++
> 
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> 

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

[Zeev Suraski]

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.

Zeev

At 23:27 19/3/2001, Chris Newbill wrote:
>I agree Phil, that is the mature way to examine this.
>
>Except, I would be surprised if we _cannot_ apply the same reasoning to the
>other is_* functions, it's the exact same concept.  I'm just not familiar
>enough with the internal workings to conclude whether is_*($x, $y, $z) would
>be efficient or even used for that matter.
>
>Although I might consider using it like if (isSet($a, $b) && is_int($a,
>$b)).
>
>-Chris
>
> > -Original Message-
> > From: Phil Driscoll [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, 19 March, 2001 2-11 pM
> > To: Chris Newbill; Zeev Suraski; Andi Gutmans; [EMAIL PROTECTED]
> > Cc: PHP DEV
> > Subject: Re: [PHP-DEV] feature request
> >
> >
> > Andi said:
> >
> > >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've just done a quick count of the php functions which take an optional
> > extra argument to change their behaviour, and I stopped when I
> > reached 100.
> >
> > Fair enough, isset is a language construct, but most of the other
> > isblahs/ext_isblahs are functions, however your average php
> > programmer won't
> > even know what this means, let alone be able to discriminate.
> >
> > My point is that if you are going to do it to isset, AND the
> > language is to
> > become more orthogonal then it MUST also be done to isanythingelse. I can
> > see that there are no nasty repercussions with using the technique for
> > isset, however there are many many isanythingelses and I'd be surprised if
> > we can apply the
> > reasoning across the board.
> >
> > I don't want to stifle innovation here, I just want us to think beyond the
> > immediate problem when the language gets extended.
> >
> > Cheers
> > --
> > Phil Driscoll
> > Dial Solutions
> > +44 (0)113 294 5112
> > http://www.dialsolutions.com
> > http://www.dtonline.org
> >
> >

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
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

[Chris Newbill]

I agree Phil, that is the mature way to examine this.

Except, I would be surprised if we _cannot_ apply the same reasoning to the
other is_* functions, it's the exact same concept.  I'm just not familiar
enough with the internal workings to conclude whether is_*($x, $y, $z) would
be efficient or even used for that matter.

Although I might consider using it like if (isSet($a, $b) && is_int($a,
$b)).

-Chris

> -Original Message-
> From: Phil Driscoll [mailto:[EMAIL PROTECTED]]
> Sent: Monday, 19 March, 2001 2-11 pM
> To: Chris Newbill; Zeev Suraski; Andi Gutmans; [EMAIL PROTECTED]
> Cc: PHP DEV
> Subject: Re: [PHP-DEV] feature request
>
>
> Andi said:
>
> >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've just done a quick count of the php functions which take an optional
> extra argument to change their behaviour, and I stopped when I
> reached 100.
>
> Fair enough, isset is a language construct, but most of the other
> isblahs/ext_isblahs are functions, however your average php
> programmer won't
> even know what this means, let alone be able to discriminate.
>
> My point is that if you are going to do it to isset, AND the
> language is to
> become more orthogonal then it MUST also be done to isanythingelse. I can
> see that there are no nasty repercussions with using the technique for
> isset, however there are many many isanythingelses and I'd be surprised if
> we can apply the
> reasoning across the board.
>
> I don't want to stifle innovation here, I just want us to think beyond the
> immediate problem when the language gets extended.
>
> Cheers
> --
> Phil Driscoll
> Dial Solutions
> +44 (0)113 294 5112
> http://www.dialsolutions.com
> http://www.dtonline.org
>
>


-- 
PHP Development Mailing List 
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

[Zeev Suraski]

At 23:10 19/3/2001, Phil Driscoll wrote:
>Andi said:
>
> >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've just done a quick count of the php functions which take an optional
>extra argument to change their behaviour, and I stopped when I reached 100.

Define 'change their behavior' though?  Almost all SQL functions take an 
optional argument which is the link id.  That is by design, and doesn't 
really mean anything here, and it's not really changing their behavior, but 
rather, giving more fine-grained arguments.  The number of functions that 
were added an extra argument after at a later stage (as opposed to their 
time of writing) is very small.  The number of functions that were added an 
extra argument that really changes their behavior is pretty much negligible 
IMHO.


>Fair enough, isset is a language construct, but most of the other
>isblahs/ext_isblahs are functions, however your average php programmer won't
>even know what this means, let alone be able to discriminate.

It doesn't really matter.  Let's say you suggested isset($var[, $reverse]) 
syntax, which will hint isset() whether to reverse its result or not.  Who 
says whether it's a good idea to 'waste' this 2nd argument on this 
purpose?  The way I see it, supporting more than one variable in isset() is 
very useful for users, and keeping it the way it was just to accommodate 
for possible extra arguments in the future that may or may not come doesn't 
make much sense and isn't justified.

>My point is that if you are going to do it to isset, AND the language is to
>become more orthogonal then it MUST also be done to isanythingelse. I can
>see that there are no nasty repercussions with using the technique for
>isset, however there are many many isanythingelses and I'd be surprised if
>we can apply the
>reasoning across the board.

What do you mean by making the language orthogonal?  You mean consistent?

Zeev


-- 
PHP Development Mailing List 
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

[Zeev Suraski]

What is iseverythingelse()?  I don't think we have any other 
iseverythingelse() function.

The fact isset() is a language construct does make a serious 
difference.  It already is very different from functions, and not in its 
underlying implementation but its semantics.

Zeev

At 23:21 19/3/2001, Lars Torben Wilson wrote:
>Jason Greene writes:
> > > Generally using functions for two different purposes is a bad idea, but
> > > enhancing functions with additional arguments that extend its 
> functionality
> > > is not too bad.  In this case, adding n arguments is perhaps the 
> extension
> > > that makes the most sense for isset(), so we should go with 
> it.  Keeping it
> > > with one argument 'for future use' doesn't make much sense in my
> > > opinion.  Not any more sense than saying the same thing about some new
> > > argument someone might want to add to it in the future - why not keep it
> > > clean and wait for a 'better' use?
> > >
> > > Zeev
> >
> > I agree, this is something thats had more thought put into it than it 
> really needed.
> > This functionality very much fits issets nature - something goes in and 
> 0/1 comes
> > out. There really is no reason to not implement the request.
> >
> > -Jason
>
>Well, Phil is right in that if isset() is changed then
>iseverythingelse() also needs to be examined and if necessary and
>possible changed to suit. Otherwise we'll be fielding questions about
>'well it works this way for *this* function, why not this one?' for
>years. The same question. Over and over and over. Because if the
>language itself isn't consistent then no number of FAQs and manual
>notes will prevent people from stubbing their toes.
>
>I think that too much thought has most definitely *not* been put into
>this issue--the effect on the whole language needs to be considered,
>not just isset(). Just IMHO, of course.
>
>
>--
>++
>|Torben Wilson <[EMAIL PROTECTED]>Adcore Finland|
>|http://www.coastnet.com/~torbenhttp://www.adcore.com|
>|Ph: 1.604.709.0506 [EMAIL PROTECTED]|
>++

--
Zeev Suraski <[EMAIL PROTECTED]>
CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/


-- 
PHP Development Mailing List 
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

[Lars Torben Wilson]

Jason Greene writes:
> > Generally using functions for two different purposes is a bad idea, but 
> > enhancing functions with additional arguments that extend its functionality 
> > is not too bad.  In this case, adding n arguments is perhaps the extension 
> > that makes the most sense for isset(), so we should go with it.  Keeping it 
> > with one argument 'for future use' doesn't make much sense in my 
> > opinion.  Not any more sense than saying the same thing about some new 
> > argument someone might want to add to it in the future - why not keep it 
> > clean and wait for a 'better' use?
> > 
> > Zeev
> 
> I agree, this is something thats had more thought put into it than it really needed.
> This functionality very much fits issets nature - something goes in and 0/1 comes
> out. There really is no reason to not implement the request.
> 
> -Jason

Well, Phil is right in that if isset() is changed then
iseverythingelse() also needs to be examined and if necessary and
possible changed to suit. Otherwise we'll be fielding questions about
'well it works this way for *this* function, why not this one?' for
years. The same question. Over and over and over. Because if the
language itself isn't consistent then no number of FAQs and manual
notes will prevent people from stubbing their toes.

I think that too much thought has most definitely *not* been put into
this issue--the effect on the whole language needs to be considered,
not just isset(). Just IMHO, of course.


-- 
++
|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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9845: win2k CRASH when PHP run on a localhost from IE

[emailleonid]

From: [EMAIL PROTECTED]
Operating system: windows 2000
PHP version:  4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description:  win2k CRASH when PHP run on a localhost from IE

i think it hapends when you do include .. but because of the complete system crash 
(ONLY under IE .. with netscape it works fine) it is hard to trace the bug.


-- 
Edit Bug report at: http://bugs.php.net/?id=9845&edit=1



-- 
PHP Development Mailing List 
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

[Jason Greene]

> Generally using functions for two different purposes is a bad idea, but 
> enhancing functions with additional arguments that extend its functionality 
> is not too bad.  In this case, adding n arguments is perhaps the extension 
> that makes the most sense for isset(), so we should go with it.  Keeping it 
> with one argument 'for future use' doesn't make much sense in my 
> opinion.  Not any more sense than saying the same thing about some new 
> argument someone might want to add to it in the future - why not keep it 
> clean and wait for a 'better' use?
> 
> Zeev

I agree, this is something thats had more thought put into it than it really needed.
This functionality very much fits issets nature - something goes in and 0/1 comes
out. There really is no reason to not implement the request.

-Jason




-- 
PHP Development Mailing List 
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

[Phil Driscoll]

Andi said:

>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've just done a quick count of the php functions which take an optional
extra argument to change their behaviour, and I stopped when I reached 100.

Fair enough, isset is a language construct, but most of the other
isblahs/ext_isblahs are functions, however your average php programmer won't
even know what this means, let alone be able to discriminate.

My point is that if you are going to do it to isset, AND the language is to
become more orthogonal then it MUST also be done to isanythingelse. I can
see that there are no nasty repercussions with using the technique for
isset, however there are many many isanythingelses and I'd be surprised if
we can apply the
reasoning across the board.

I don't want to stifle innovation here, I just want us to think beyond the
immediate problem when the language gets extended.

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org



-- 
PHP Development Mailing List 
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

[Chris Newbill]

No doubt, clean code is king! And we don't want more work for Andi! :)

Basically I see this functionality as filling a niche and nothing more.
It's not a wonder-drug, it just makes certain situations a little more
readable/maintainable IMHO.

-Chris

> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> Sent: Monday, 19 March, 2001 1-12 pM
> To: Jason Greene; Phil Driscoll; Chris Newbill; Zeev Suraski
> Cc: PHP DEV
> Subject: Re: [PHP-DEV] feature request
>
>
> Ugh, that's exactly what I didn't want to get into. If you want
> an array of
> results you're better of doing a few if() statements. It's faster and
> writes much nicer code.
>
> Andi
>
> At 02:08 PM 3/19/2001 -0600, Jason Greene wrote:
> >Perhaps isset should be branched to form a separate function to handle
> >multi args,
> >we could offer things in the new function such as an optional argument
> >that passes back an array of results.
> >
> >-Jason
> >
> >- Original Message -
> >From: "Phil Driscoll" <[EMAIL PROTECTED]>
> >To: "Chris Newbill" <[EMAIL PROTECTED]>; "Zeev Suraski"
> ><[EMAIL PROTECTED]>; "Andi Gutmans" <[EMAIL PROTECTED]>
> >Cc: "PHP DEV" <[EMAIL PROTECTED]>
> >Sent: Monday, March 19, 2001 1:58 PM
> >Subject: Re: [PHP-DEV] feature request
> >
> >
> > > My earlier post to the list doesn't seem to have arrived yet,
> so here it is
> > > again. You'll note from the posting that I'm not keen on the
> patch staying
> > > in. There are considerable efforts being made by several of
> us on the QA
> > > team trying to make the language more orthogonal, and this
> kind of ad hoc
> > > addition really doesn't help.
> > >
> > > 
> > > >That is the only thing that I see of any real use as well.
> I was just
> > > >humoring Andi and his idea that we would soon be requesting that
> > feature of
> > > >knowing which one failed the test.
> > >
> > > I was really voting no for the original feature - just
> returning true or
> > > false - unless it can be shown (and implemented) that
> iswhatever(multiple
> > > args) will work sensibly across the board, and that implementing
> > > iswhatever(multiple args) does not waste the function
> namespace for a new
> > > feature - e.g. loads of php functions take optional extra arguments to
> > > modify their behaviour, but once iswhatever gained the multi argument
> > > functionality described, it would be impossible to extend the
> functionality
> > > in this way.
> > >
> > > Cheers, and apologies for such a long sentence
> > > 
> > > --
> > > Phil Driscoll
> > > Dial Solutions
> > > +44 (0)113 294 5112
> > > http://www.dialsolutions.com
> > > http://www.dtonline.org
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > 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 
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

[Zeev Suraski]

At 22:41 19/3/2001, Jason Greene wrote:
>I don't, but I could see that viewpoint where Phil is coming from when he 
>talks about the fact
>that functions can end up with 2 different goals, and then when we want to 
>enhance them
>we end up with multiple behaviors in a single function and way too many 
>option flags.

Generally using functions for two different purposes is a bad idea, but 
enhancing functions with additional arguments that extend its functionality 
is not too bad.  In this case, adding n arguments is perhaps the extension 
that makes the most sense for isset(), so we should go with it.  Keeping it 
with one argument 'for future use' doesn't make much sense in my 
opinion.  Not any more sense than saying the same thing about some new 
argument someone might want to add to it in the future - why not keep it 
clean and wait for a 'better' use?

Zeev


-- 
PHP Development Mailing List 
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

[Jason Greene]

I don't, but I could see that viewpoint where Phil is coming from when he talks about 
the fact
that functions can end up with 2 different goals, and then when we want to enhance them
we end up with multiple behaviors in a single function and way too many option flags.

Thinking about it though, I can't think of anything in the multi-arg version that 
would really
need to be enhanced.  So, like I said, Im not objecting.  : )

-Jason


- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: "Phil Driscoll" <[EMAIL PROTECTED]>; "Chris Newbill" 
<[EMAIL PROTECTED]>; "Andi Gutmans" <[EMAIL PROTECTED]>; "PHP DEV"
<[EMAIL PROTECTED]>
Sent: Monday, March 19, 2001 2:26 PM
Subject: Re: [PHP-DEV] feature request


> I don't see the negative aspect of having it accept multiple variables.  Is
> there one?  If there isn't, then there's no need to invent a problem...
>
> Zeev
>
> At 22:08 19/3/2001, 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 
> > > 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 
> 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 
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

[Zeev Suraski]

I don't see the negative aspect of having it accept multiple variables.  Is 
there one?  If there isn't, then there's no need to invent a problem...

Zeev

At 22:08 19/3/2001, 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 
> > 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 
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

[Jason Greene]

After thinking about it more, it seems that in every scenario I could think of where 
you wanted an
array of results, you should not be using independent vars in the first place. It 
would seem much more reasonable
to use an array of combined values, and then parse those accordingly.

I don't have any objection with the isset function taking multi args.

-Jason

--- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>; "Phil Driscoll" <[EMAIL PROTECTED]>; "Chris 
Newbill" <[EMAIL PROTECTED]>; "Zeev
Suraski" <[EMAIL PROTECTED]>
Cc: "PHP DEV" <[EMAIL PROTECTED]>
Sent: Monday, March 19, 2001 2:11 PM
Subject: Re: [PHP-DEV] feature request


> Ugh, that's exactly what I didn't want to get into. If you want an array of
> results you're better of doing a few if() statements. It's faster and
> writes much nicer code.
>
> Andi
>
> At 02:08 PM 3/19/2001 -0600, Jason Greene wrote:
> >Perhaps isset should be branched to form a separate function to handle
> >multi args,
> >we could offer things in the new function such as an optional argument
> >that passes back an array of results.
> >
> >-Jason
> >
> >- Original Message -
> >From: "Phil Driscoll" <[EMAIL PROTECTED]>
> >To: "Chris Newbill" <[EMAIL PROTECTED]>; "Zeev Suraski"
> ><[EMAIL PROTECTED]>; "Andi Gutmans" <[EMAIL PROTECTED]>
> >Cc: "PHP DEV" <[EMAIL PROTECTED]>
> >Sent: Monday, March 19, 2001 1:58 PM
> >Subject: Re: [PHP-DEV] feature request
> >
> >
> > > My earlier post to the list doesn't seem to have arrived yet, so here it is
> > > again. You'll note from the posting that I'm not keen on the patch staying
> > > in. There are considerable efforts being made by several of us on the QA
> > > team trying to make the language more orthogonal, and this kind of ad hoc
> > > addition really doesn't help.
> > >
> > > 
> > > >That is the only thing that I see of any real use as well.  I was just
> > > >humoring Andi and his idea that we would soon be requesting that
> > feature of
> > > >knowing which one failed the test.
> > >
> > > I was really voting no for the original feature - just returning true or
> > > false - unless it can be shown (and implemented) that iswhatever(multiple
> > > args) will work sensibly across the board, and that implementing
> > > iswhatever(multiple args) does not waste the function namespace for a new
> > > feature - e.g. loads of php functions take optional extra arguments to
> > > modify their behaviour, but once iswhatever gained the multi argument
> > > functionality described, it would be impossible to extend the functionality
> > > in this way.
> > >
> > > Cheers, and apologies for such a long sentence
> > > 
> > > --
> > > Phil Driscoll
> > > Dial Solutions
> > > +44 (0)113 294 5112
> > > http://www.dialsolutions.com
> > > http://www.dtonline.org
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > 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 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9844 Updated: MIME type gets added to variable using POST method

[sniper]

ID: 9844
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Directory/Filesystem functions
Assigned To: 
Comments:

This is fixed in CVS. Try latest CVS snapshot from http://snaps.php.net/

--Jani


Previous Comments:
---

[2001-03-19 15:01:10] [EMAIL PROTECTED]
Every time I try to use POST to submit variables or files to a form it seems to add 
the mimetype to the variable. (GET seems to work fine, but then I can't upload files)

If I upload a Jpeg file, it adds "Content-Type: image/jpeg" to the variable. or if I 
submit a "TEXT AREA" to the script it adds "Content-Type: application/octet-stream" to 
the variable.

I also noticed that a normal TEXT variable gets some extra whitespace added to it in 
the script, so I had to use trim() to remove that.

I found a workaround for the file-upload bug somewhere :

function fix_php_upload_bug($tmp) { 
$infile=fopen($tmp,"r"); // Open the file for the copy 
$outfile=fopen("$tmp.new","w"); // create a new temp file 
$header=fgets($infile,255); //get the 1st line (netscape sometimes doesn't add 
a Content-type line) 
//if its more than just a rn sequence then 
if (strlen($header)>2) $header=fgets($infile,255); //get next line also 
while(!feof($infile)) { // Loop through the remaining file 
$temp=fread($infile,128); 
fwrite($outfile,$temp,strlen($temp)); //copying contents to new temp file 
} 
fclose($outfile); 
fclose($infile); 
copy("$tmp.new","$tmp"); //replace the original with our new bug fixed file 
unlink("$tmp.new"); //and delete the new file 
return filesize($tmp); //return a true file size 
} 


Configure Command : './configure' '--prefix=/usr' '--with-config-file-path=/etc' 
'--disable-debug' '--enable-pic' '--enable-shared' '--enable-inline-optimization' 
'--with-apxs=/usr/sbin/apxs' '--with-exec-dir=/usr/bin' '--with-regex=system' 
'--with-gettext' '--with-gd' '--with-jpeg-dir=/usr' '--with-png' '--with-zlib' 
'--with-db2' '--with-db3' '--with-gdbm' '--enable-debugger' '--enable-magic-quotes' 
'--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' 
'--enable-track-vars' '--enable-yp' '--enable-ftp' '--enable-wddx' '--without-mysql' 
'--without-oracle' '--without-oci8' '--with-xml' 

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9844&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Andi 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 
> > 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 
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

[Jason Greene]

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 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] feature request

[Andi 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 
>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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9844: MIME type gets added to variable using POST method

[roy]

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 7 
PHP version:  4.0.4pl1
PHP Bug Type: *Directory/Filesystem functions
Bug description:  MIME type gets added to variable using POST method

Every time I try to use POST to submit variables or files to a form it seems to add 
the mimetype to the variable. (GET seems to work fine, but then I can't upload files)

If I upload a Jpeg file, it adds "Content-Type: image/jpeg" to the variable. or if I 
submit a "TEXT AREA" to the script it adds "Content-Type: application/octet-stream" to 
the variable.

I also noticed that a normal TEXT variable gets some extra whitespace added to it in 
the script, so I had to use trim() to remove that.

I found a workaround for the file-upload bug somewhere :

function fix_php_upload_bug($tmp) { 
$infile=fopen($tmp,"r"); // Open the file for the copy 
$outfile=fopen("$tmp.new","w"); // create a new temp file 
$header=fgets($infile,255); //get the 1st line (netscape sometimes doesn't add 
a Content-type line) 
//if its more than just a \r\n sequence then 
if (strlen($header)>2) $header=fgets($infile,255); //get next line also 
while(!feof($infile)) { // Loop through the remaining file 
$temp=fread($infile,128); 
fwrite($outfile,$temp,strlen($temp)); //copying contents to new temp file 
} 
fclose($outfile); 
fclose($infile); 
copy("$tmp.new","$tmp"); //replace the original with our new bug fixed file 
unlink("$tmp.new"); //and delete the new file 
return filesize($tmp); //return a true file size 
} 


Configure Command : './configure' '--prefix=/usr' '--with-config-file-path=/etc' 
'--disable-debug' '--enable-pic' '--enable-shared' '--enable-inline-optimization' 
'--with-apxs=/usr/sbin/apxs' '--with-exec-dir=/usr/bin' '--with-regex=system' 
'--with-gettext' '--with-gd' '--with-jpeg-dir=/usr' '--with-png' '--with-zlib' 
'--with-db2' '--with-db3' '--with-gdbm' '--enable-debugger' '--enable-magic-quotes' 
'--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' 
'--enable-track-vars' '--enable-yp' '--enable-ftp' '--enable-wddx' '--without-mysql' 
'--without-oracle' '--without-oci8' '--with-xml' 


-- 
Edit Bug report at: http://bugs.php.net/?id=9844&edit=1



-- 
PHP Development Mailing List 
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

[Phil Driscoll]

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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9843 Updated: Decrement Operator

[hholzgra]

ID: 9843
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Assigned To: 
Comments:

theese are typical rounding errors that
occure when dealing with decimal fractions
on binary based machines

Previous Comments:
---

[2001-03-19 14:46:12] [EMAIL PROTECTED]
I believe there is a problem with the decrement operator.

http://www.artemisgroup.com/test.php

$percentchange = .30;
while ($percentchange > -1){
  $percentchange -= .01;
  echo $percentchange;
}

zero is returned as -1.422473250301E-16 and 0.01 is returned as 0.0099. 
This seems incorrect to me.

Thanks

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9843&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9390 Updated: PHPSESSID adds itself to $HTTP_POST_VARS

[sniper]

ID: 9390
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Session related
Assigned To: 
Comments:

I suggest you check that they REALLY are identical.
And I guess you're trying with same scripts? :)

--Jani


Previous Comments:
---

[2001-03-19 14:43:01] [EMAIL PROTECTED]
Jani,

That is correct,
I did explicitly stop and start the web server
(prod and dev) using the ./apachectl stop ... start.

Dev works fine.

Aaron.

---

[2001-03-19 14:39:43] [EMAIL PROTECTED]

both production and development environments
are using identical versions and configurations 
of apache web server 1.3.14 and php 4.0.4 pl1,
php.ini config is also identical.

---

[2001-03-19 14:38:49] [EMAIL PROTECTED]
Stupid question: did you restart your apache after
adding that php.ini directive? And did your restart it 
like this:

./apachectl stop
./apachectl start

(I'm just guessing here.. :)

And does it work on your development environment or not?
(the 'no ill effects'?)

--Jani


---

[2001-03-19 14:24:42] [EMAIL PROTECTED]
Woops!

No it still doesnt work.

Aaron.

---

[2001-03-19 14:16:04] [EMAIL PROTECTED]

both production and development environments
are using identical versions and configurations 
of apache web server 1.3.14 and php 4.0.4 pl1,
php.ini config is also identical.

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9390&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9843: Decrement Operator

[jplock]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.4pl1
PHP Bug Type: Scripting Engine problem
Bug description:  Decrement Operator

I believe there is a problem with the decrement operator.

http://www.artemisgroup.com/test.php

$percentchange = .30;
while ($percentchange > -1){
  $percentchange -= .01;
  echo $percentchange;
}

zero is returned as -1.422473250301E-16 and 0.01 is returned as 0.0099. 
This seems incorrect to me.

Thanks


-- 
Edit Bug report at: http://bugs.php.net/?id=9843&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9390 Updated: PHPSESSID adds itself to $HTTP_POST_VARS

[aaron . lake]

ID: 9390
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: *Session related
Description: PHPSESSID adds itself to $HTTP_POST_VARS

Jani,

That is correct,
I did explicitly stop and start the web server
(prod and dev) using the ./apachectl stop ... start.

Dev works fine.

Aaron.

Previous Comments:
---

[2001-03-19 14:39:43] [EMAIL PROTECTED]

both production and development environments
are using identical versions and configurations 
of apache web server 1.3.14 and php 4.0.4 pl1,
php.ini config is also identical.

---

[2001-03-19 14:38:49] [EMAIL PROTECTED]
Stupid question: did you restart your apache after
adding that php.ini directive? And did your restart it 
like this:

./apachectl stop
./apachectl start

(I'm just guessing here.. :)

And does it work on your development environment or not?
(the 'no ill effects'?)

--Jani


---

[2001-03-19 14:24:42] [EMAIL PROTECTED]
Woops!

No it still doesnt work.

Aaron.

---

[2001-03-19 14:16:04] [EMAIL PROTECTED]

both production and development environments
are using identical versions and configurations 
of apache web server 1.3.14 and php 4.0.4 pl1,
php.ini config is also identical.

---

[2001-03-19 14:13:42] [EMAIL PROTECTED]
Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=9390


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9390 Updated: PHPSESSID adds itself to $HTTP_POST_VARS

[aaron . lake]

ID: 9390
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: *Session related
Description: PHPSESSID adds itself to $HTTP_POST_VARS


both production and development environments
are using identical versions and configurations 
of apache web server 1.3.14 and php 4.0.4 pl1,
php.ini config is also identical.

Previous Comments:
---

[2001-03-19 14:38:49] [EMAIL PROTECTED]
Stupid question: did you restart your apache after
adding that php.ini directive? And did your restart it 
like this:

./apachectl stop
./apachectl start

(I'm just guessing here.. :)

And does it work on your development environment or not?
(the 'no ill effects'?)

--Jani


---

[2001-03-19 14:24:42] [EMAIL PROTECTED]
Woops!

No it still doesnt work.

Aaron.

---

[2001-03-19 14:16:04] [EMAIL PROTECTED]

both production and development environments
are using identical versions and configurations 
of apache web server 1.3.14 and php 4.0.4 pl1,
php.ini config is also identical.

---

[2001-03-19 14:13:42] [EMAIL PROTECTED]
Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





---

[2001-03-19 14:12:47] [EMAIL PROTECTED]
Both environments run same php.ini? Same version of PHP?
Same configure line used on building both PHP's?

--Jani


---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=9390


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9390 Updated: PHPSESSID adds itself to $HTTP_POST_VARS

[sniper]

ID: 9390
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Session related
Assigned To: 
Comments:

Stupid question: did you restart your apache after
adding that php.ini directive? And did your restart it 
like this:

./apachectl stop
./apachectl start

(I'm just guessing here.. :)

And does it work on your development environment or not?
(the 'no ill effects'?)

--Jani


Previous Comments:
---

[2001-03-19 14:24:42] [EMAIL PROTECTED]
Woops!

No it still doesnt work.

Aaron.

---

[2001-03-19 14:16:04] [EMAIL PROTECTED]

both production and development environments
are using identical versions and configurations 
of apache web server 1.3.14 and php 4.0.4 pl1,
php.ini config is also identical.

---

[2001-03-19 14:13:42] [EMAIL PROTECTED]
Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





---

[2001-03-19 14:12:47] [EMAIL PROTECTED]
Both environments run same php.ini? Same version of PHP?
Same configure line used on building both PHP's?

--Jani


---

[2001-03-19 14:05:53] [EMAIL PROTECTED]
Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9390&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9390 Updated: PHPSESSID adds itself to $HTTP_POST_VARS

[aaron . lake]

ID: 9390
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: *Session related
Description: PHPSESSID adds itself to $HTTP_POST_VARS

Woops!

No it still doesnt work.

Aaron.

Previous Comments:
---

[2001-03-19 14:16:04] [EMAIL PROTECTED]

both production and development environments
are using identical versions and configurations 
of apache web server 1.3.14 and php 4.0.4 pl1,
php.ini config is also identical.

---

[2001-03-19 14:13:42] [EMAIL PROTECTED]
Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





---

[2001-03-19 14:12:47] [EMAIL PROTECTED]
Both environments run same php.ini? Same version of PHP?
Same configure line used on building both PHP's?

--Jani


---

[2001-03-19 14:05:53] [EMAIL PROTECTED]
Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





---

[2001-03-16 17:46:41] [EMAIL PROTECTED]
In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

--Jani


---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=9390


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] feature request

[Andi 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 
> > >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 
> > 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 
>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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Zend build

[Andrei Zmievski]

On Mon, 19 Mar 2001, Alexander Bokovoy wrote:
> PHP4 has no means except AC_OUTPUT() to replace variables in header
> files through templates in modules. If I'm using PHP_SUBST and PHP_OUTPUT
> then php_midgard.h didn't generated from php_midgard.in. The only way
> to generate it is to use AC_OUTPUT and AC_SUBST (which is called in PHP_SUBST_OLD).
> 
> I treat it as a bug in PHP4 building environment.

Then file a bug in the bug system.

-Andrei

Commitment, n.:
Commitment can be illustrated by a breakfast of ham and eggs. The chicken
was involved, the pig was committed.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Zend build

[Alexander Bokovoy]

On Mon, Mar 19, 2001 at 01:12:05PM -0600, Andrei Zmievski wrote:
> On Mon, 19 Mar 2001, [EMAIL PROTECTED] wrote:
> > 
> > 
> > > Is there something wrong with build of Zend as of this morning?
> > > 
> > > I get:
> > > 
> > > $ make
> > > Making all in Zend
> > > make[1]: Entering directory `/data/src/cvs-php/Zend'
> > > make[1]: *** No rule to make target `@MAINTAINER_MODE_TRUE@', needed by
> > > `Makefile.in'.  Stop.
> > > make[1]: Leaving directory `/data/src/cvs-php/Zend'
> > > make: *** [all-recursive] Error 1
> > > 
> > > I tried clean checkout of PHP & Zend, ./buildconf, ./configure, make but got
> > > the exact same error message.
> > 
> > same for me, please fix it ASAP...
> 
> This is due to change made to ext/midgard/config.m4, from version 1.14
> to version 1.15:
> 
[skipped]
>fi
> -  PHP_SUBST(MIDCONFIG_FILE)
> -  PHP_OUTPUT(php_midgard.h)
> +  PHP_SUBST_OLD(MIDCONFIG_FILE)
> +  AC_OUTPUT(php_midgard.h, [], [])
>  fi
> 
> Whoever maintains this module, please fix it.
PHP4 has no means except AC_OUTPUT() to replace variables in header
files through templates in modules. If I'm using PHP_SUBST and PHP_OUTPUT
then php_midgard.h didn't generated from php_midgard.in. The only way
to generate it is to use AC_OUTPUT and AC_SUBST (which is called in PHP_SUBST_OLD).

I treat it as a bug in PHP4 building environment.

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |Aurora R&D team 
Minsk Linux Users Group |www.minsk-lug.net|  www.aurora-linux.com  
ALT Linux Team  |www.alt-linux.org| Architecte Open Source
-- Say something you'll be sorry for, I love receiving apologies.

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9390 Updated: PHPSESSID adds itself to $HTTP_POST_VARS

[aaron . lake]

ID: 9390
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Session related
Description: PHPSESSID adds itself to $HTTP_POST_VARS


both production and development environments
are using identical versions and configurations 
of apache web server 1.3.14 and php 4.0.4 pl1,
php.ini config is also identical.

Previous Comments:
---

[2001-03-19 14:13:42] [EMAIL PROTECTED]
Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





---

[2001-03-19 14:12:47] [EMAIL PROTECTED]
Both environments run same php.ini? Same version of PHP?
Same configure line used on building both PHP's?

--Jani


---

[2001-03-19 14:05:53] [EMAIL PROTECTED]
Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





---

[2001-03-16 17:46:41] [EMAIL PROTECTED]
In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

--Jani


---

[2001-03-16 17:37:13] [EMAIL PROTECTED]
Since you are using the transparent session id feature, the obvious question is: Do 
you use forms with method=POST?

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=9390


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9390 Updated: PHPSESSID adds itself to $HTTP_POST_VARS

[aaron . lake]

ID: 9390
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: *Session related
Description: PHPSESSID adds itself to $HTTP_POST_VARS

Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





Previous Comments:
---

[2001-03-19 14:12:47] [EMAIL PROTECTED]
Both environments run same php.ini? Same version of PHP?
Same configure line used on building both PHP's?

--Jani


---

[2001-03-19 14:05:53] [EMAIL PROTECTED]
Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





---

[2001-03-16 17:46:41] [EMAIL PROTECTED]
In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

--Jani


---

[2001-03-16 17:37:13] [EMAIL PROTECTED]
Since you are using the transparent session id feature, the obvious question is: Do 
you use forms with method=POST?

---

[2001-02-21 20:41:51] [EMAIL PROTECTED]
Problem:

For some reason PHP adds PHPSESSID to $HTTP_POST_VARS

At login, I use:
session_start():
$sid = session_id();
session_register("sid");
etc.

2 pages into the session the var PHPSESSID
appears as the first element in the post array.

My app has been been behaving until I started playing with
gc_probability in php.ini.

My identical dev website with identical code does not
reproduce this problem.

Config INFO:

Compile Directives:
'./configure' '--prefix=/../../php_prod' '--with-config_file_path=/../../php_prod/lib' 
'--with-oci8' '--with-apache=/../../apache_prod' '--enable-track-vars' 
'--enable-trans-sid' '--enable-ftp'


php.ini session config:

[Session]
session.save_handler = files ;
session.save_path=/usr/local/session;   session.use_cookies   
= 0   ; session.name  = PHPSESSID  ;
session.auto_start= 0   ; session.cookie_lifetime=0   ;
   session.cookie_path =  /
session.serialize_handler = php ; session.gc_probability= 1 ; 
session.gc_maxlifetime= 1800; session.referer_check = ; 
session.entropy_length= 0   ; session.entropy_file  = ;  
session.entropy_length= 16
; session.entropy_file  = /dev/urandom
session.cache_limiter= nocache ; ; 
session.cache_expire  = 180 ; session.use_trans_sid = 1   ; 

[EOF]

---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.

Full Bug description available at: http://bugs.php.net/?id=9390


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9390 Updated: PHPSESSID adds itself to $HTTP_POST_VARS

[sniper]

ID: 9390
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Session related
Assigned To: 
Comments:

Both environments run same php.ini? Same version of PHP?
Same configure line used on building both PHP's?

--Jani


Previous Comments:
---

[2001-03-19 14:05:53] [EMAIL PROTECTED]
Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





---

[2001-03-16 17:46:41] [EMAIL PROTECTED]
In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

--Jani


---

[2001-03-16 17:37:13] [EMAIL PROTECTED]
Since you are using the transparent session id feature, the obvious question is: Do 
you use forms with method=POST?

---

[2001-02-21 20:41:51] [EMAIL PROTECTED]
Problem:

For some reason PHP adds PHPSESSID to $HTTP_POST_VARS

At login, I use:
session_start():
$sid = session_id();
session_register("sid");
etc.

2 pages into the session the var PHPSESSID
appears as the first element in the post array.

My app has been been behaving until I started playing with
gc_probability in php.ini.

My identical dev website with identical code does not
reproduce this problem.

Config INFO:

Compile Directives:
'./configure' '--prefix=/../../php_prod' '--with-config_file_path=/../../php_prod/lib' 
'--with-oci8' '--with-apache=/../../apache_prod' '--enable-track-vars' 
'--enable-trans-sid' '--enable-ftp'


php.ini session config:

[Session]
session.save_handler = files ;
session.save_path=/usr/local/session;   session.use_cookies   
= 0   ; session.name  = PHPSESSID  ;
session.auto_start= 0   ; session.cookie_lifetime=0   ;
   session.cookie_path =  /
session.serialize_handler = php ; session.gc_probability= 1 ; 
session.gc_maxlifetime= 1800; session.referer_check = ; 
session.entropy_length= 0   ; session.entropy_file  = ;  
session.entropy_length= 16
; session.entropy_file  = /dev/urandom
session.cache_limiter= nocache ; ; 
session.cache_expire  = 180 ; session.use_trans_sid = 1   ; 

[EOF]

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9390&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Zend build

[Andrei Zmievski]

On Mon, 19 Mar 2001, [EMAIL PROTECTED] wrote:
> 
> 
> > Is there something wrong with build of Zend as of this morning?
> > 
> > I get:
> > 
> > $ make
> > Making all in Zend
> > make[1]: Entering directory `/data/src/cvs-php/Zend'
> > make[1]: *** No rule to make target `@MAINTAINER_MODE_TRUE@', needed by
> > `Makefile.in'.  Stop.
> > make[1]: Leaving directory `/data/src/cvs-php/Zend'
> > make: *** [all-recursive] Error 1
> > 
> > I tried clean checkout of PHP & Zend, ./buildconf, ./configure, make but got
> > the exact same error message.
> 
> same for me, please fix it ASAP...

This is due to change made to ext/midgard/config.m4, from version 1.14
to version 1.15:

Index: ext/midgard/config.m4
===
RCS file: /repository/php4/ext/midgard/config.m4,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- ext/midgard/config.m4  2001/03/19 07:04:56  1.14
+++ ext/midgard/config.m4  2001/03/19 07:37:00  1.15
@@ -1,4 +1,4 @@
-dnl $Id: config.m4,v 1.14 2001/03/19 07:04:56 ab Exp $
+dnl $Id: config.m4,v 1.15 2001/03/19 07:37:00 ab Exp $
 
 dnl  Copyright (C) 1999 Jukka Zitting <[EMAIL PROTECTED]>
 dnl  Copyright (C) 2000 The Midgard Project ry
@@ -72,6 +72,6 @@
   else
 MIDCONFIG_FILE="php_config.h"
   fi
-  PHP_SUBST(MIDCONFIG_FILE)
-  PHP_OUTPUT(php_midgard.h)
+  PHP_SUBST_OLD(MIDCONFIG_FILE)
+  AC_OUTPUT(php_midgard.h, [], [])
 fi

Whoever maintains this module, please fix it.

-Andrei
* We reason deeply, when we forcibly feel. *

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9836 Updated: php unexpectedly ends on too long scripts

[sniper]

ID: 9836
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Bogus
Status: Feedback
Bug Type: Scripting Engine problem
Assigned To: 
Comments:

With that limited information you gave in the first
comments I couldn't know that.

Ok, so it doesn't crash? Just stops?
Computer generated scripts? How big?
And what do they do? 

Could you check that it doesn't crash, ie. run the php
script which 'ends' within gdb:

# gdb php
(gdb) run -f thisscriptendstoosoon.php

--Jani


Previous Comments:
---

[2001-03-19 12:13:53] [EMAIL PROTECTED]
I know of time limit, smart guy.

But I don't have it set to 1 sec -- that is approximately the time in which php 
terminates.

(I hope you mark this problem as closed now -- THAT YOU'VE SOLVED IT).

Damn.

---

[2001-03-19 11:55:37] [EMAIL PROTECTED]
RTFM:

http://www.php.net/manual/en/function.set-time-limit.php



---

[2001-03-19 08:35:04] [EMAIL PROTECTED]
we have some long computer generated scripts on our system. when we run such a long 
script, php suddenly ends without producing any output and reports exit status 1.

I think php exits while parsing the script.

(I can provide an example of such script on demand)

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9836&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9390 Updated: PHPSESSID adds itself to $HTTP_POST_VARS

[aaron . lake]

ID: 9390
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: *Session related
Description: PHPSESSID adds itself to $HTTP_POST_VARS

Thanx Jani,

As suggested:

In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

when i added this conf. directive and bounced the web server, $HTTP_POST_VARS (using 
the POST method) contained
NO elements.

I added this directive to my identical development environment and noticed no ill 
effects.





Previous Comments:
---

[2001-03-16 17:46:41] [EMAIL PROTECTED]
In php.ini:

url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=fakeentry"

Remove the last setting, form=fakeentry.
(or if you don't have this directive in your php.ini,
add it without the last setting.)

--Jani


---

[2001-03-16 17:37:13] [EMAIL PROTECTED]
Since you are using the transparent session id feature, the obvious question is: Do 
you use forms with method=POST?

---

[2001-02-21 20:41:51] [EMAIL PROTECTED]
Problem:

For some reason PHP adds PHPSESSID to $HTTP_POST_VARS

At login, I use:
session_start():
$sid = session_id();
session_register("sid");
etc.

2 pages into the session the var PHPSESSID
appears as the first element in the post array.

My app has been been behaving until I started playing with
gc_probability in php.ini.

My identical dev website with identical code does not
reproduce this problem.

Config INFO:

Compile Directives:
'./configure' '--prefix=/../../php_prod' '--with-config_file_path=/../../php_prod/lib' 
'--with-oci8' '--with-apache=/../../apache_prod' '--enable-track-vars' 
'--enable-trans-sid' '--enable-ftp'


php.ini session config:

[Session]
session.save_handler = files ;
session.save_path=/usr/local/session;   session.use_cookies   
= 0   ; session.name  = PHPSESSID  ;
session.auto_start= 0   ; session.cookie_lifetime=0   ;
   session.cookie_path =  /
session.serialize_handler = php ; session.gc_probability= 1 ; 
session.gc_maxlifetime= 1800; session.referer_check = ; 
session.entropy_length= 0   ; session.entropy_file  = ;  
session.entropy_length= 16
; session.entropy_file  = /dev/urandom
session.cache_limiter= nocache ; ; 
session.cache_expire  = 180 ; session.use_trans_sid = 1   ; 

[EOF]

---


Full Bug description available at: http://bugs.php.net/?id=9390


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9840 Updated: seg fault on apache

[sniper]

ID: 9840
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Apache related
Assigned To: 
Comments:

First get the latest CVS snapshot from http://snaps.php.net/
and then configure it using the same configure line you
have included here but add --enable-debug into it.

And then generate a gdb backtrace of the crash:
http://www.php.net/bugs-generating-backtrace.php

--Jani



Previous Comments:
---

[2001-03-19 11:42:53] [EMAIL PROTECTED]
here is my configure line:
./configure --with-zlib --with-mm --with-mysql=/usr/local/mysql --with-mcal=../libmcal 
--with-imap=../../imap --with-gettext --enable-ftp 
--with-db3=/usr/local/BerkeleyDB.3.2 --with-apache=/usr/local/apache --with-mcrypt

I am using IMP from the HORDE project if you are familiar with it. 

The script that it appears to be failing on is as follows, it is rather long sorry:

 '',
 'timeout' => _("Either you have logged in incorrectly or your login 
has expired. Please login again."),
 'logout'  => sprintf(_("You have been logged out of %s. Thank you for 
using the system. If you wish to log in again, please use the form below."), 
$conf['sitename']),
 'failed'  => _("Login failed for some reason. Most likely your 
username or password was entered incorrectly."));

/* Default to 'login' if no $reason is set. */
$reason = Horde::getFormData('reason', 'login');
$actionID = Horde::getFormData('actionID', NO_ACTION);

/* Initialize the session routines. */
session_name($conf['session_name']);
@session_start();

if (isset($HTTP_SESSION_VARS['imp']) && is_array($HTTP_SESSION_VARS['imp'])) {
if ($reason == 'logout') {
$imp = &$HTTP_SESSION_VARS['imp'];
if (isset($imp['user'])) {
$prefs = Prefs::factory($conf['prefs']['driver'],
$registry->getApp(), $imp['user'],
Secret::read(Secret::getKey('imp'), $imp['pass']),
$conf['prefs']['params']);
$prefs->store();
}
$HTTP_SESSION_VARS['imp'] = null;
session_unregister('imp');
} elseif ($reason == 'failed') {
$HTTP_SESSION_VARS['imp'] = null;
session_unregister('imp');
} else {
/* If there is an existing session, redirect the user to the mailbox. */
if ($actionID == IMP_LOGIN) {
header('Location: ' . Horde::applicationUrl('mailbox.php?actionID=' . 
IMP_LOGIN, true));
exit;
} elseif (($actionID == LOGIN_COMPOSE) || (isset($HTTP_GET_VARS['action']) && 
($HTTP_GET_VARS['action'] == 'compose'))) {
header('Location: ' . Horde::applicationUrl('mailbox.php?actionID=' . 
LOGIN_COMPOSE, true));
exit;
} else {
header('Location: ' . Horde::applicationUrl('mailbox.php', true));
exit;
}
}
}

/* Log the reason if logging is enabled. */
if ($conf['log']['enabled']) {
$log->log($HTTP_SERVER_VARS['REMOTE_ADDR'] . ' ' . $reason, LOG_INFO);
}

/* Redirect the user on logout if redirection is enabled. */
if (($reason == 'logout') && $conf['user']['redirect_on_logout']) {
header('Location: ' . $conf['user']['redirect_on_logout']);
exit;
}

/* Redirect the user if an alternate login page has been specified. */
if ((in_array($reason, array('login', 'failed', 'timeout'))) && 
$conf['user']['alternate_login']) {
header('Location: ' . $conf['user']['alternate_login']);
exit;
}

/* Initialize the password key. */
Secret::setKey('imp');

/* Set the actionID of the login form */
if ((isset($HTTP_GET_VARS['action']) && $HTTP_GET_VARS['action'] == 'compose') ||
($actionID == LOGIN_COMPOSE)) {
$actionID = LOGIN_COMPOSE;
} else {
$actionID = IMP_LOGIN;
}

/* Get the default preferences values. */
$prefs = Prefs::factory('none', $registry->getApp());
$prefs->setDefaults(IMP_BASE . '/config/prefs.php');

/* Grab some default values from the first entry in config/servers.php. */
reset($servers);
$server_key = key($servers);
$server_value = $servers[$server_key]['server'];
$protocol_value = $servers[$server_key]['protocol'];
$port_value = $servers[$server_key]['port'];
$folders_value = $servers[$server_key]['folders'];
$namespace_value = $servers[$server_key]['namespace'];
$maildomain_value = $servers[$server_key]['maildomain'];

/*
 * If the server list is used but should be hidden (for virtual hosting),
 * make sure we output a server name to use.
 */
if ($conf['server']['server_list'] && $conf['server']['server_list_hidden']) {
/*
 * Iterate through the servers in an attempt to locate a "preferred"
 * server for this web server.  If none if found, we default to the
 * first entry in the hash (indicated by the $server_key value set
 * above).
 */
foreach ($servers as $

[PHP-DEV] PHP 4.0 Bug #9842 Updated: Unresolved automake value

[sniper]

ID: 9842
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Compile Problem
Assigned To: 
Comments:

Fixed. 

--Jani


Previous Comments:
---

[2001-03-19 12:16:40] [EMAIL PROTECTED]
Doing a fresh checkout from CVS and then running 'buildconf', 'configure' and trying 
to compile results in this:

Making all in Zend
make[1]: Entering directory `/export/projects/compile/php4/Zend'
make[1]: *** No rule to make target `@MAINTAINER_MODE_TRUE@', needed by `Makefile.in'. 
 Stop.
make[1]: Leaving directory `/export/projects/compile/php4/Zend'
make: *** [all-recursive] Error 1


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9842&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Help required

[julian.chamberlain]

Hi there, i am in need of some help with PHP 
programming. Do you know anyone that can help me or can you?
 
Many thanks
 
Kind regards
Julian Chamberlain

Re: [PHP-DEV] Zend build

[david]

> Is there something wrong with build of Zend as of this morning?
> 
> I get:
> 
> $ make
> Making all in Zend
> make[1]: Entering directory `/data/src/cvs-php/Zend'
> make[1]: *** No rule to make target `@MAINTAINER_MODE_TRUE@', needed by
> `Makefile.in'.  Stop.
> make[1]: Leaving directory `/data/src/cvs-php/Zend'
> make: *** [all-recursive] Error 1
> 
> I tried clean checkout of PHP & Zend, ./buildconf, ./configure, make but got
> the exact same error message.

same for me, please fix it ASAP...

> Edin
> 

--
David


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

RE: [PHP-DEV] feature request

[Andi 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 
> > >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 
> > 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 
>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 
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] GD configure slightly broken.

[Alexander Feldman]

This is not the only problem with the gd extension configuration. On some
platfomrs (FreeBSD) we need the -lm library for this extension when
linking (it is important if you build a dynamic gd.so extension). Also
there is no proper testing for setting the HAVE_GD_XBM constant. I will
fix this when I have time.

-- Alex

On Mon, 19 Mar 2001, Fredrik Ohrn wrote:

> 
> If I do a
> 
>   ./configure --with-gd
> 
> Without actually having GD installed in a standard location the configure
> script decides to statically link it instead of raising an error:
> 
>   checking whether to include GD support... yes (static)
> 
> And then the make will bomb when gcc can't find the gd headers.
> 
> Is this supposed to be or is it a bug?
> 
> 
> Regards,
> Fredrik
> 
> -- 
> Do fish get thirsty?
> 
> Fredrik Öhrn   Chalmers University of Technology
> [EMAIL PROTECTED]  Sweden
> 
> 
> -- 
> PHP Development Mailing List 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] GD configure slightly broken.

[Fredrik Ohrn]

If I do a

  ./configure --with-gd

Without actually having GD installed in a standard location the configure
script decides to statically link it instead of raising an error:

  checking whether to include GD support... yes (static)

And then the make will bomb when gcc can't find the gd headers.

Is this supposed to be or is it a bug?


Regards,
Fredrik

-- 
Do fish get thirsty?

Fredrik Öhrn   Chalmers University of Technology
[EMAIL PROTECTED]  Sweden


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9841 Updated: Undefined Function

[hholzgra]

ID: 9841
Updated by: hholzgra
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: DBM/DBA related
Assigned To: 
Comments:

please have a look at your configure log and phpinfo() output

was [g]dbm support found and activated by configure?

Previous Comments:
---

[2001-03-19 12:09:36] [EMAIL PROTECTED]


./configure 
--with-mysql 
--with-apxs=/var/lib/apache/sbin/apxs
--with-gdbm




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9841&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9842: Unresolved automake value

[andrei]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0 Latest CVS (19/03/2001)
PHP Bug Type: Compile Problem
Bug description:  Unresolved automake value

Doing a fresh checkout from CVS and then running 'buildconf', 'configure' and trying 
to compile results in this:

Making all in Zend
make[1]: Entering directory `/export/projects/compile/php4/Zend'
make[1]: *** No rule to make target `@MAINTAINER_MODE_TRUE@', needed by `Makefile.in'. 
 Stop.
make[1]: Leaving directory `/export/projects/compile/php4/Zend'
make: *** [all-recursive] Error 1



-- 
Edit Bug report at: http://bugs.php.net/?id=9842&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9836 Updated: php unexpectedly ends on too long scripts

[jack]

ID: 9836
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Description: php unexpectedly ends on too long scripts

I know of time limit, smart guy.

But I don't have it set to 1 sec -- that is approximately the time in which php 
terminates.

(I hope you mark this problem as closed now -- THAT YOU'VE SOLVED IT).

Damn.

Previous Comments:
---

[2001-03-19 11:55:37] [EMAIL PROTECTED]
RTFM:

http://www.php.net/manual/en/function.set-time-limit.php



---

[2001-03-19 08:35:04] [EMAIL PROTECTED]
we have some long computer generated scripts on our system. when we run such a long 
script, php suddenly ends without producing any output and reports exit status 1.

I think php exits while parsing the script.

(I can provide an example of such script on demand)

---


Full Bug description available at: http://bugs.php.net/?id=9836


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9841: Undefined Function

[donnaber]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.4pl1
PHP Bug Type: DBM/DBA related
Bug description:  Undefined Function



./configure 
--with-mysql 
--with-apxs=/var/lib/apache/sbin/apxs
--with-gdbm





-- 
Edit Bug report at: http://bugs.php.net/?id=9841&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9838 Updated: PHP crashes with any extensions turned on...

[sniper]

ID: 9838
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Apache related
Assigned To: 
Comments:

Please try the 4.0.5-RC1 from http://www.php4win.de/
as there has been fixes regarding the extension handling
in it.

--Jani


Previous Comments:
---

[2001-03-19 10:17:45] [EMAIL PROTECTED]
i know this has been touched on a number of times, but here goes...

i am trying to config PHP to work with MSSQL 7.0. the webserver is
Apache 1.3.17. the OS is Win2K. 

i've edit the PHP.ini, removing the ; before the php_mssql70.dll
extension, and copied the file to the WINNT directory. i've also
copied the php_mssql70.dll file to the WINNTSystem32 directory.
i did not edit the extensions_dir var as the extension dll is in the
system path.

prior to this configuration change, i've had no issues with the install.
running with this extension, PHP crashes at the end of parsing 
ANY PHP document, not just those with mssql_*** function calls.
Apache stays running, but can no longer parse PHP docs.

is this one of the aforementioned "multitheaded webserver" issues,
or am i missing a step? any advise on this would be greatly
appreciated. tx.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9838&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9830 Updated: There is a problem with HTTP POST method.

[sniper]

ID: 9830
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: HTTP related
Assigned To: 
Comments:

Please try the latest CVS snapshot from 
http://snaps.php.net/ as there have been fixes in the
post handling since 4.0.4pl1 was released.

--Jani


Previous Comments:
---

[2001-03-19 04:03:07] [EMAIL PROTECTED]
Here comes POST request:

>telnet www.spylog.ru 80
-
POST /log_post.phtml HTTP/1.1
Host: www.spylog.ru
Content-Length: 32

12345678901234567890123456789012
-

The answer to this request is random :-) Sometimes 200, sometimes just connection 
close!
But If I use perl - it works fine!

>telnet www.spylog.ru 80
-
POST /cgi-bin/main.pl HTTP/1.1
Host: www.spylog.ru
Content-Length: 32

12345678901234567890123456789012
-



Sometimes it seems that script works, but if I reads info from STDIN to a file - the 
file is empty. The same with Perl work's fine. I think it is a bug.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9830&edit=2


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]