Re: [PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4/ TODO-4.1.txt

[Derick Rethans]

On Thu, 19 Apr 2001, Andi Gutmans wrote:

> Well you know the most permanent things are temporary things such as
> prototypes.
> I also thought it would make much more sense to create something very small
> in C (maybe even Perl as it's installed on all systems) and use that.

PERL isn't installed in all systems, especialy on Windows systems it
isn't.

> I'm not really sure anymore what this installer you are talking about looks
> like. So I think it would be good to get a small update and have a
> discussion of what we need on php-dev@.

regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands
-


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

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: Martin Kaltoft
Email: [EMAIL PROTECTED]
ID: kaltoft
Purpose: PEAR development

-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Alexander Bokovoy]

On Thu, Apr 19, 2001 at 07:21:32AM +0200, Andi Gutmans wrote:
> At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > > >When we're past the prototyping phase and stuff stabilizes, a C
> > > >rewrite may be a good idea, but I don't think it is now.
> > >
> > > Well you know the most permanent things are temporary things such as
> > > prototypes.
> > > I also thought it would make much more sense to create something very small
> > > in C (maybe even Perl as it's installed on all systems) and use that.
> > > I'm not really sure anymore what this installer you are talking about looks
> > > like. So I think it would be good to get a small update and have a
> > > discussion of what we need on php-dev@.
> >
> >I see no issue with writing a prototype in PHP.  The start of such a
> >prototype is in cvs (pear/script/pear)
> >
> >And yes, using XML is pretty much a no-brainer here.  That will allow a
> >lot of different nifty tools to access the package information.
> 
> For a start you don't have PHP installed on most systems. So PHP would need 
> to compile itself and then fetch packages and recompile itself. Seems to me 
> like the no-brainer isn't such a no-brainer.
Seems that you're forgetting main point of PEAR: you don't need to
recompile PHP itself when adding some module via PEAR because more
suitable method exists -- self contained extensions -- which works via
PEAR right now. Of course, there is small number of extensions from /ext
which could be compiled in this mode out-of-the-box right now (mostly
because building environment in PEAR still unreliable), but it exists.
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

-- 
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] script creating root files

[Xia0Taizi]

i have a script which creates directories that belong to root. the problem
is, my apache is running as nobody, nobody is set in the httpd.conf, and
nobody exist in my /etc/passwd.
however, whenever i run a the php script to mkdir or upload a file from my
HD to the server, or copy files from one location to another server on the
server, the resulting file or directory belongs to root. ls -al shows
root.root as the owner of the file.
anyone know why? i thought all files created by the script should be
nobody.nobody, but somehow all the scripts on this particular server creates
root.root files and directories.
any idea how to solve this?

regards





-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4/ TODO-4.1.txt

[Rasmus Lerdorf]

> >If we were to write it in C we would most likely need to provide a
> >statically linked binary anyway for the different platforms as not
> >everyone will have access to a fully functioning development environment.
>
> If they are compiling PHP and PHP extensions we can expect them to be able
> to compile an ANSI C program.

Which means they can also compile a simple PHP instance since we bundle
xml.

> >Despite the pervasiveness of Perl, chances are high that certain Perl
> >modules would be missing and then someone has to go looking for Perl
> >modules to install PHP packages..  Ouch!
>
> You can do this kind of stuff with the Vanilla Perl and don't need extensions.

Doing this sort of thing non-XML doesn't make much sense to me.  It
severely limits the flexibility.  I suppose we could have a stripped down
simple format and also an XML source to keep it really simple and help
bootstrap people.

To start from absolute scratch I can see grabbing a shell script
initially.  lynx -source http://pear.php.net/go | sh
Or simply download the script and run it if the system doesn't have lynx.

This shell script would then determine which OS it is on and figure out
how to procede.  If it sees a PHP binary with XML support, it can use
that.  If it doesn't, it can grab a simple one for that platform.  Or it
kick into Perl if the Perl setup has XML support.  We could also make the
XML simple enough and bundle a little parser in either Perl or PHP that
was smart enough to parse it.  That way we wouldn't depend on external XML
support.

I just think it is a mistake to come up with some proprietary package
description format here.  The packages themselves can just be compressed
tarballs, but the information about each package should be accessible via
XML somehow.  That virtually guarantees a slew of frontend clients almost
instantly as everyone knows how to handle XML data sources these days.

-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: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 09:24 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > > > >When we're past the prototyping phase and stuff stabilizes, a C
> > > > >rewrite may be a good idea, but I don't think it is now.
> > > >
> > > > Well you know the most permanent things are temporary things such as
> > > > prototypes.
> > > > I also thought it would make much more sense to create something 
> very small
> > > > in C (maybe even Perl as it's installed on all systems) and use that.
> > > > I'm not really sure anymore what this installer you are talking 
> about looks
> > > > like. So I think it would be good to get a small update and have a
> > > > discussion of what we need on php-dev@.
> > >
> > >I see no issue with writing a prototype in PHP.  The start of such a
> > >prototype is in cvs (pear/script/pear)
> > >
> > >And yes, using XML is pretty much a no-brainer here.  That will allow a
> > >lot of different nifty tools to access the package information.
> >
> > For a start you don't have PHP installed on most systems. So PHP would need
> > to compile itself and then fetch packages and recompile itself. Seems to me
> > like the no-brainer isn't such a no-brainer.
>
>We need to somehow work out the functionality.  Once it is well-defined
>other clients will come, I am sure.  We can always provide a small
>statically linked installer program which includes a stripped down PHP
>binary and the appropriate Installer class.

Right but if we chose XML this makes it much harder to have C clients (even 
Perl because the module might not be installed). I don't think it will be 
such a complicated format for us to need XML here especially as it limits 
what clients will be created. I think it needs more thought. Having a 
prototype for the functionality is OK but not if you're talking about a 
prototype which sets the standard.


>If we were to write it in C we would most likely need to provide a
>statically linked binary anyway for the different platforms as not
>everyone will have access to a fully functioning development environment.

If they are compiling PHP and PHP extensions we can expect them to be able 
to compile an ANSI C program.


>Despite the pervasiveness of Perl, chances are high that certain Perl
>modules would be missing and then someone has to go looking for Perl
>modules to install PHP packages..  Ouch!

You can do this kind of stuff with the Vanilla Perl and don't need extensions.

Andi


-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4/ TODO-4.1.txt

[Rasmus Lerdorf]

> At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > > >When we're past the prototyping phase and stuff stabilizes, a C
> > > >rewrite may be a good idea, but I don't think it is now.
> > >
> > > Well you know the most permanent things are temporary things such as
> > > prototypes.
> > > I also thought it would make much more sense to create something very small
> > > in C (maybe even Perl as it's installed on all systems) and use that.
> > > I'm not really sure anymore what this installer you are talking about looks
> > > like. So I think it would be good to get a small update and have a
> > > discussion of what we need on php-dev@.
> >
> >I see no issue with writing a prototype in PHP.  The start of such a
> >prototype is in cvs (pear/script/pear)
> >
> >And yes, using XML is pretty much a no-brainer here.  That will allow a
> >lot of different nifty tools to access the package information.
>
> For a start you don't have PHP installed on most systems. So PHP would need
> to compile itself and then fetch packages and recompile itself. Seems to me
> like the no-brainer isn't such a no-brainer.

We need to somehow work out the functionality.  Once it is well-defined
other clients will come, I am sure.  We can always provide a small
statically linked installer program which includes a stripped down PHP
binary and the appropriate Installer class.

If we were to write it in C we would most likely need to provide a
statically linked binary anyway for the different platforms as not
everyone will have access to a fully functioning development environment.

Despite the pervasiveness of Perl, chances are high that certain Perl
modules would be missing and then someone has to go looking for Perl
modules to install PHP packages..  Ouch!

-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: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 09:16 PM 4/18/2001 -0700, Rasmus Lerdorf wrote:
> > >When we're past the prototyping phase and stuff stabilizes, a C
> > >rewrite may be a good idea, but I don't think it is now.
> >
> > Well you know the most permanent things are temporary things such as
> > prototypes.
> > I also thought it would make much more sense to create something very small
> > in C (maybe even Perl as it's installed on all systems) and use that.
> > I'm not really sure anymore what this installer you are talking about looks
> > like. So I think it would be good to get a small update and have a
> > discussion of what we need on php-dev@.
>
>I see no issue with writing a prototype in PHP.  The start of such a
>prototype is in cvs (pear/script/pear)
>
>And yes, using XML is pretty much a no-brainer here.  That will allow a
>lot of different nifty tools to access the package information.

For a start you don't have PHP installed on most systems. So PHP would need 
to compile itself and then fetch packages and recompile itself. Seems to me 
like the no-brainer isn't such a no-brainer.

Andi


-- 
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-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4/ TODO-4.1.txt

[Rasmus Lerdorf]

> >When we're past the prototyping phase and stuff stabilizes, a C
> >rewrite may be a good idea, but I don't think it is now.
>
> Well you know the most permanent things are temporary things such as
> prototypes.
> I also thought it would make much more sense to create something very small
> in C (maybe even Perl as it's installed on all systems) and use that.
> I'm not really sure anymore what this installer you are talking about looks
> like. So I think it would be good to get a small update and have a
> discussion of what we need on php-dev@.

I see no issue with writing a prototype in PHP.  The start of such a
prototype is in cvs (pear/script/pear)

And yes, using XML is pretty much a no-brainer here.  That will allow a
lot of different nifty tools to access the package information.

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

[PHP-DEV] Re: [PHP-CVS] Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 10:03 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:
>["Sean R. Bright" <[EMAIL PROTECTED]>]
> > To continue a tangent... I don't like the idea of having the PEAR
> > fetching/installation mechanism written in PHP (already some base code in
> > PEAR to do this).  It seems to me that it forces the user to download/build
> > PHP and then download and rebuild PHP with any extensions that don't 
> come in
> > the base distribution.  Instead it should be a binary that can be compiled
> > before PHP is built, can download and configure any extensions 
> requested and
> > then build the resulting PHP binary.  We can also build in a dependency
> > mechanism where for example, someone chooses to install a PEAR module 
> (be it
> > PHP or C) and the required extensions would be downloaded as well.
> >
> > Just my $0.02
>
>I see your point, but personally I code 5 times faster in PHP than in
>C, and I want to get this done now, not next year. :-)
>
>When we're past the prototyping phase and stuff stabilizes, a C
>rewrite may be a good idea, but I don't think it is now.

Well you know the most permanent things are temporary things such as 
prototypes.
I also thought it would make much more sense to create something very small 
in C (maybe even Perl as it's installed on all systems) and use that.
I'm not really sure anymore what this installer you are talking about looks 
like. So I think it would be good to get a small update and have a 
discussion of what we need on php-dev@.

Thanks,

Andi


--
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-CVS] cvs: php4 / TODO-4.1.txt

[Rasmus Lerdorf]

It has been in cvs for months.

On Thu, 19 Apr 2001, Andi Gutmans wrote:

> At 06:53 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:
>
> >*BLAM*
> >
> >That's the sound of someone shooting himself in the foot.  The PEAR
> >installer needs the XML extension. :-)
>
> What do you mean? Has work started on this already?
> I'm not quite sure what you mean by the PEAR installer but I think we
> should discuss the util we would need to list/fetch/build C extensions from
> the PEAR repository on php-dev@.
> I think it's a waste of time to decide right now what to remove instead of
> trying to finalizing this utility. Once we see how well it works it'll be
> time to start thinking of what extensions to remove. I think it's just
> putting energy in the wrong place right now :)
>
> Andi
>
>
> --
> 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] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 03:33 AM 4/19/2001 +0300, Zeev Suraski wrote:
>Guys,
>
>Over the years, there's always been a tendency to think about things which 
>are 10 steps ahead.  It never worked, and I don't think it would work here 
>either.  Moreover, I don't see any advantage in discussing this now - on 
>the contrary - we really have no idea what we're talking about.  Whether 
>or not we separate modules *at all* will greatly depend on how good an 
>implementation we end up having.  How many of them we end up separating 
>will also depend on that.  Let's just wait with those discussions until 
>they're somehow connected with reality.
>
>Zeev

Scary... Didn't read this before :)

Andi


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 06:53 PM 4/18/2001 -0400, Stig Sæther Bakken wrote:

>*BLAM*
>
>That's the sound of someone shooting himself in the foot.  The PEAR
>installer needs the XML extension. :-)

What do you mean? Has work started on this already?
I'm not quite sure what you mean by the PEAR installer but I think we 
should discuss the util we would need to list/fetch/build C extensions from 
the PEAR repository on php-dev@.
I think it's a waste of time to decide right now what to remove instead of 
trying to finalizing this utility. Once we see how well it works it'll be 
time to start thinking of what extensions to remove. I think it's just 
putting energy in the wrong place right now :)

Andi


--
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] Bug #7488 Updated: Pass-by-reference problem

[kalowsky]

ID: 7488
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: ODBC related
PHP Version: 4.0 Latest CVS (27/10/2000)
Assigned To: 
Comments:

tested your supplied patch, and it seems to be working on Windows, so I'm commiting.  
Please have others test too!

Previous Comments:
---

[2001-03-27 15:31:59] [EMAIL PROTECTED]
Yup. Here's a breakdown:

Using & | allow_call_time_pass_by_reference | Works? | Err?
---
  Yes   |  On   |  Yes   | No
  No|  On   |  No| No
  Yes   |  Off  |  Yes   | Yes
  No|  Off  |  No| No

Which is weird. When I get the error telling me that my
arg has been passed by value, it's actually been passed
by reference.

I also think perhaps that it's just generally a bad idea
for a function to depend upon deprecated features of the
language, since at the moment it requires call-time 
pass-by-ref to work.


---

[2001-03-27 10:49:47] [EMAIL PROTECTED]
is this still the case?

---

[2000-10-27 05:07:08] [EMAIL PROTECTED]
When calling odbc_fetch_into() with three arguments, all works as 
expected: the result array is passed by reference and results are 
placed into it. But when using the two-parameter form, the result
array becomes the second parameter, which must be passed like this:

  odbc_fetch_into($rid, &$arr);

in order to have the results placed into $arr. If the & is left out, $arr
is not modified. However, using & results in the large compile-time error
being printed at the beginning of script output unless it's been masked
out in php.ini, since forcing pass-by-ref this way is no longer supported.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7488&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-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

["Sean R. Bright" <[EMAIL PROTECTED]>]
> To continue a tangent... I don't like the idea of having the PEAR
> fetching/installation mechanism written in PHP (already some base code in
> PEAR to do this).  It seems to me that it forces the user to download/build
> PHP and then download and rebuild PHP with any extensions that don't come in
> the base distribution.  Instead it should be a binary that can be compiled
> before PHP is built, can download and configure any extensions requested and
> then build the resulting PHP binary.  We can also build in a dependency
> mechanism where for example, someone chooses to install a PEAR module (be it
> PHP or C) and the required extensions would be downloaded as well.
> 
> Just my $0.02

I see your point, but personally I code 5 times faster in PHP than in
C, and I want to get this done now, not next year. :-)

When we're past the prototyping phase and stuff stabilizes, a C
rewrite may be a good idea, but I don't think it is now.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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] Bug #7779 Updated: ODBC query : select distinct ...

[kalowsky]

ID: 7779
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: ODBC related
PHP Version: 4.0.3pl1
Assigned To: 
Comments:

can you please try this with a more recent version of PHP?  with my limited resources, 
attempting this on win98SE i cannot reproduce the error... so either its been fixed, 
or it may be win2k specific...

Previous Comments:
---

[2000-11-13 05:56:41] [EMAIL PROTECTED]
(PHP Version 4.0.4-dev on Windows 2000 without SP1)

php.exe and the isapi module both crash with a query like:
$query = "select distinct date from datetest";
The query without "distict" works fine.

ISAPI modules says: PHP has encountered an Access Violation at 04C2EA86, php.exe quits 
with no special message.

There is no error message from the ODBC driver when the same query is (successfully) 
issued directly through an odbc client. 


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7779&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] Bug #9397 Updated: odbc_setoption() cannot accept string value (patch included)

[kalowsky]

ID: 9397
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Status: Open
Old-Bug Type: ODBC related
Bug Type: Feature/Change Request
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Changing this to a feature request as it seems to be more a request to update PHP/ODBC 
to ODBC3 compliancy.  

Previous Comments:
---

[2001-03-05 00:37:22] [EMAIL PROTECTED]
Dear kara,

I am sorry for not specifying it clearly last time. SQL_EXTENSION_NAME is used 
specifically for our database, DBMaker.

We are developers for this database and we have also have developed php driver for our 
database. Because of some specific features of our database, we really need to let 
users who use our database be able to set this kind of options. Unfortunately, ODBC 
2.x does not allow setting attributes with string-type values.

Since the ODBC version currently used in php is, as you can see from the source code, 
2.x. We really cannot use SQLSetStmtAttr() provided by ODBC 3.

We didn't use HAVE_DBMAKER ifdefs because we think other databases might be glad to 
see this, too.




---

[2001-02-22 11:35:25] [EMAIL PROTECTED]
In ODBC 2.x it is not possible to pass string values to
SQLSetStmtOption(). It is possible with ODBC 3,
SQLSetStmtAttr() has an additional parameter to specify the
string length. 
By the way: I couldn't find SQL_EXTENSION_NAME as possible
attribute to SQLSetStmtAttr(). What's it's pupose?


---

[2001-02-22 04:55:38] [EMAIL PROTECTED]
When I tried to use odbc_setoption() to set file extension
name:

odbc_setoption($sth, 2, 2001, "JPG"); /*2001 means SQL_EXTENSION_NAME*/

php will hang.

The patch followed:

** BEGIN PATCH ***

--- php_odbc.c.old  Wed Jan  3 23:04:50 2001
+++ php_odbc.c  Thu Feb 22 10:29:52 2001
@@ -2393,6 +2393,7 @@
odbc_result *result;
RETCODE rc;
pval **pv_handle, **pv_which, **pv_opt, **pv_val;
+   UDWORD val;
 
if ( zend_get_parameters_ex(4, &pv_handle, &pv_which, &pv_opt, &pv_val) == 
FAILURE) {
WRONG_PARAM_COUNT;
@@ -2400,7 +2401,20 @@
  
convert_to_long_ex(pv_which);
convert_to_long_ex(pv_opt);
+   switch (Z_TYPE_PP(pv_val)) {
+   case IS_LONG:
convert_to_long_ex(pv_val);
+   val = (*pv_val)->value.lval;
+   break;
+   case IS_STRING:
+   convert_to_string_ex(pv_val); 
+   val = (UDWORD) (*pv_val)->value.str.val;
+   break;
+   default:
+   php_error(E_WARNING, "Unknown param type");
+   RETURN_FALSE;
+   break;
+   }
 
switch ((*pv_which)->value.lval) {
case 1: /* SQLSetConnectOption */
@@ -2409,7 +2423,7 @@
php_error(E_WARNING, "Can't set option for persistent 
connection");
RETURN_FALSE;
}
-   rc = SQLSetConnectOption(conn->hdbc, (unsigned 
short)((*pv_opt)->value.lval), (*pv_val)->value.lval);
+   rc = SQLSetConnectOption(conn->hdbc, (unsigned 
+short)((*pv_opt)->value.lval), val);
if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO) {
odbc_sql_error(conn->henv, conn->hdbc, SQL_NULL_HSTMT, 
"SetConnectOption");
RETURN_FALSE;
@@ -2418,7 +2432,7 @@
case 2: /* SQLSetStmtOption */
ZEND_FETCH_RESOURCE(result, odbc_result *, pv_handle, -1, 
"ODBC result", le_result);

-   rc = SQLSetStmtOption(result->stmt, (unsigned 
short)((*pv_opt)->value.lval), ((*pv_val)->value.lval));
+   rc = SQLSetStmtOption(result->stmt, (unsigned 
+short)((*pv_opt)->value.lval), val);
 
if (rc != SQL_SUCCESS && rc != SQL_SUCCESS_WITH_INFO) {
odbc_sql_error(result->conn_ptr->henv, 
result->conn_ptr->hdbc, result->stmt, "SetStmtOption");


** END PATCH ***

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9397&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] Bug #10392: read in violite.c never times out and causes the httpd proc to get stuck

[michael]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.19
PHP version:  4.0 Latest CVS (18/04/2001)
PHP Bug Type: MySQL related
Bug description:  read in violite.c never times out and causes the httpd proc to get 
stuck

Under the lastest CVS and earlier version of php/zend apache httpd processes get stuck 
for 15-30+ minutes in a read located in violite.c to a MySQL server.
 
Example from apache's scoreboard server-status:

Srv PID Acc M CPU  SS Req Conn Child Slot Client VHost Request  
18-0 14908 0/13/13 W  0.17 509 0 0.0 0.01 0.01  134.126.194.180 www.audiogalaxy.com 
GET /list/artistInfo.php?&r=1478&offset=200 HTTP/1.1 

Pid 14908 has been stuck in the "sending data state" for 509 seconds.  This seems to 
only happen on our sessions database and at the same spot everytime.  There is about 
1000 queries/second coming to this db running MySQL 3.33.36.  This bug appears on less 
than 1% of the apache requests, but eats apache slots for lunch requiring a restart or 
a kill -9 issused for each individual pid that is blocked in the read and never woken 
up by the alarm.  This happens on all 21 webservers running 
linux2.2.19/Apache1.3.19/Php4.0.4 or Php latest CVS


Running gdb and doing a backtrace shows whats going on:
Reading symbols from /lib/libnss_dns.so.2...done.
Loaded symbols for /lib/libnss_dns.so.2
0x2ac68424 in __libc_read () from /lib/libc.so.6
(gdb) bt
#0  0x2ac68424 in __libc_read () from /lib/libc.so.6
#1  0x4 in ?? ()
#2  0x8092d63 in my_real_read (net=0x830311c, complen=0x7fffae80) at net.c:458
#3  0x8093014 in my_net_read (net=0x830311c) at net.c:604
#4  0x808e4cc in net_safe_read (mysql=0x830311c) at libmysql.c:288
#5  0x808fdfb in mysql_real_connect (mysql=0x830311c, host=0x83030fc "64.245.54.128", 
user=0x84b2c54 "private", passwd=0x8302f84 "private", db=0x0, port=1433, 
unix_socket=0x0, 
client_flag=0) at libmysql.c:1350
#6  0x808b914 in php_mysql_do_connect (ht=3, return_value=0x83030dc, this_ptr=0x0, 
return_value_used=1, 
persistent=0) at php_mysql.c:575
#7  0x808ba35 in php_if_mysql_connect (ht=3, return_value=0x83030dc, this_ptr=0x0, 
return_value_used=1)
at php_mysql.c:618
#8  0x811b4d5 in execute (op_array=0x8264b50) at ./zend_execute.c:1494
#9  0x811b692 in execute (op_array=0x82c4278) at ./zend_execute.c:1534
#10 0x811b692 in execute (op_array=0x82649d8) at ./zend_execute.c:1534
#11 0x80e7cde in call_user_function_ex (function_table=0x8205440, object_pp=0x0, 
function_name=0x8302304, retval_ptr_ptr=0x7798, param_count=2, 
params=0x84c2a44, 
no_separation=1, symbol_table=0x0) at zend_execute_API.c:464
#12 0x80e76b8 in call_user_function (function_table=0x8205440, object_pp=0x0, 
function_name=0x8302304, 
retval_ptr=0x8264a74, param_count=2, params=0x7810) at zend_execute_API.c:325
#13 0x80a57a9 in ps_call_handler (func=0x8302304, argc=2, argv=0x7810) at 
mod_user.c:59
#14 0x80a5b68 in ps_write_user (mod_data=0x81da130, key=0x82bf1fc 
"privateprivateprivateprivatepriv", 
val=0x84c36c4 "privateprivateprivate...session stuff", vallen=335) at 
mod_user.c:147
#15 0x80a3096 in php_session_save_current_state () at session.c:609
#16 0x80a50b5 in php_session_flush () at session.c:1439
#17 0x80a50d7 in php_rshutdown_session (type=1, module_number=14) at session.c:1454
#18 0x80ee695 in module_registry_cleanup (module=0x82280e8) at zend_API.c:785
#19 0x80f1247 in zend_hash_apply (ht=0x81ef400, apply_func=0x80ee668 
)
at zend_hash.c:692
#20 0x80eda39 in zend_deactivate_modules () at zend.c:522
---Type  to continue, or q  to quit---
#21 0x807effa in php_request_shutdown (dummy=0x0) at main.c:657
#22 0x807d073 in php_apache_request_shutdown ()
#23 0x8125c24 in run_cleanups ()
#24 0x81244de in ap_clear_pool ()
#25 0x812455e in ap_destroy_pool ()
#26 0x81244ca in ap_clear_pool ()
#27 0x8133c35 in child_main ()
#28 0x81342eb in make_child ()
#29 0x813439c in startup_children ()
#30 0x81349eb in standalone_main ()
#31 0x8135207 in main ()
#32 0x2abb0f31 in __libc_start_main (main=0x8134e70 , argc=1, ubp_av=0x7b54, 
init=0x8065590 <_init>, fini=0x8168fbc <_fini>, rtld_fini=0x2aab9274 <_dl_fini>, 
stack_end=0x7b4c) at ../sysdeps/generic/libc-start.c:129
(gdb) 
(gdb) up
#1  0x4 in ?? ()
(gdb) up
#2  0x8092d63 in my_real_read (net=0x830311c, complen=0x7fffae80) at net.c:458
458 if ((int) (length=vio_read(net->vio,(char*) pos,remain)) <= 0L)
(gdb) print remain
$1 = 4
(gdb) 


Configure script for php:
./configure --with-mysql --enable-track-vars --with-zlib --with-apache=$apachedir 
--with-gd=$gddir --with-jpeg-dir=$gddir 
--with-config-file-path=/common/globalconfig/php --enable-memory-limit --enable-static

Hope this helps - thanks!


-- 
Edit Bug report at: http://bugs.php.net/?id=10392&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] Bug #10250 Updated: UnixODBC can make use of SQLDriverConnect functionality too

[kalowsky]

ID: 10250
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: ODBC related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

have you tried this fix with an older version of UnixODBC?

Previous Comments:
---

[2001-04-09 15:15:59] [EMAIL PROTECTED]
In ext/odbc/php_odbc.c: odbc_sqlconnect(), only Openlink
and Empress can make use of the SQLDriverConnect function.

UnixODBC can use SQLDriverConnect as well, and in the case
of some Easysoft ODBC connections, it *must* be able to use
the SQLDriverConnect format in order to actually connect to
the database.

I have tried changing the 
  #ifdef HAVE_EMPRESS
to
  #if defined(HAVE_EMPRESS) || defined(HAVE_UNIXODBC)
and everything worked fine, giving full access to the
SQLDriverConnect method of calling odbc_connect and
odbc_pconnect.  If this could be incorporated into a later
release, it would be very useful.

(BTW, this was tested with UnixODBC 2.0.5)



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10250&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] Bug #10302 Updated: odbc_tables()

[kalowsky]

ID: 10302
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: ODBC related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

can you please provide a sample script on how to reproduce this?

Previous Comments:
---

[2001-04-12 10:47:08] [EMAIL PROTECTED]
I think this may have been an issue in a previous release but I am still having it in 
this version.

after calling odbc_tables() I can not get the results using odbc_fetch_row() or 
odbc_result_all(), but odbc_num_rows() does return the number of tables in the 
database.

The system is using the precomplied version downloaded from zend with the default 
php.ini file. Oh and in ISAPI mode!

Thanks

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10302&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] Bug #10391: regardless of having pdflib 3.03, pdflib extension requires at least pdflib 3.x

[mordru]

From: [EMAIL PROTECTED]
Operating system: SuSe Linux 7.1
PHP version:  4.0.4pl1
PHP Bug Type: *Install and Config
Bug description:  regardless of having pdflib 3.03, pdflib extension requires at least 
pdflib 3.x

./configure --with-mysql --with-apxs --with-pdflib




-- 
Edit Bug report at: http://bugs.php.net/?id=10391&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: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Sean R. Bright]

To continue a tangent... I don't like the idea of having the PEAR
fetching/installation mechanism written in PHP (already some base code in
PEAR to do this).  It seems to me that it forces the user to download/build
PHP and then download and rebuild PHP with any extensions that don't come in
the base distribution.  Instead it should be a binary that can be compiled
before PHP is built, can download and configure any extensions requested and
then build the resulting PHP binary.  We can also build in a dependency
mechanism where for example, someone chooses to install a PEAR module (be it
PHP or C) and the required extensions would be downloaded as well.

Just my $0.02

> -Original Message-
> From: Ron Chmara [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, April 18, 2001 8:53 PM
> To: Zeev Suraski
> Cc: Frank M. Kromann; Sterling Hughes; Stig Sather Bakken; php-dev
> mailinglist; Stig Sather Bakken
> Subject: Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt
>
>
> On Wednesday, April 18, 2001, at 05:33  PM, Zeev Suraski wrote:
> > Guys,
> > Over the years, there's always been a tendency to think
> about things
> > which are 10 steps ahead.  It never worked, and I don't
> think it would
> > work here either.
>
> Well, a program spec (or idea) is certainly not the reality
> of the final
> codebase.
>
> But if we don't think a few steps ahead, (or at least know where it's
> going), it's kind of hard to determine the steps to take here
> and now,
> or know where it's really going. I posted a list, and we
> discovered that
> PEAR already has dependancies on some /ext's, and (by
> implication) that
> if this continues in PEAR, eventually many of the minor ext's
> may need
> to be built to run PEAR in which case we may want to
> leave the /ext
> directory out of PEAR entirely.
>
> If something is going to be a possibility, it should probably be
> considered before we build ourselves into a corner, and
> implementing it
> becomes impossible.
>
> >  Whether or not we separate modules *at all* will greatly
> depend on how
> > good an implementation we end up having.
>
> Agreed 100%.
> But that implementation, as it happens requires some feedback and
> discussion, doesn't it?
>
> >  How many of them we end up separating will also depend on
> that.  Let's
> > just wait with those discussions until they're somehow
> connected with
> > reality.
>
> Counterpoint to this, of course, is that if we _would_ be doing this
> with a PEAR scheme, we'd need to design that into PEAR, preferrably
> without having to re-write PEAR from scratch to accomodate
> this idea. :-)
>
>
> -Ronabop
>
> --
> 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] Bug #10390: PHP CGI with AOLServer displays shebang

[rfinnie]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 3.2
PHP version:  4.0 Latest CVS (18/04/2001)
PHP Bug Type: Other web server
Bug description:  PHP CGI with AOLServer displays shebang

This bug seems related to 9475.  When using perl, sh, etc on aolserver as a cgi, the 
output is normal.  However, if I use PHP compiled as a CGI (with #!/path/to/php as the 
first line), the shebang is displayed as the first line of the response after the 
headers are sent.

Configure line:
'./configure' '--prefix=/usr/local/rf_php' 
'--with-config-file-path=/usr/local/rf_php/lib' 
'--with-exec-dir=/usr/local/rf_php/bin' '--with-imap' '--with-gd=/usr/local' 
'--with-mysql=/usr/local/mysql' '--with-db' '--enable-discard-path'

Ryan Finnie


-- 
Edit Bug report at: http://bugs.php.net/?id=10390&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: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Ron Chmara]

On Wednesday, April 18, 2001, at 05:33  PM, Zeev Suraski wrote:
> Guys,
> Over the years, there's always been a tendency to think about things 
> which are 10 steps ahead.  It never worked, and I don't think it would 
> work here either.

Well, a program spec (or idea) is certainly not the reality of the final 
codebase.

But if we don't think a few steps ahead, (or at least know where it's 
going), it's kind of hard to determine the steps to take here and now, 
or know where it's really going. I posted a list, and we discovered that 
PEAR already has dependancies on some /ext's, and (by implication) that 
if this continues in PEAR, eventually many of the minor ext's may need 
to be built to run PEAR in which case we may want to leave the /ext 
directory out of PEAR entirely.

If something is going to be a possibility, it should probably be 
considered before we build ourselves into a corner, and implementing it 
becomes impossible.

>  Whether or not we separate modules *at all* will greatly depend on how 
> good an implementation we end up having.

Agreed 100%.
But that implementation, as it happens requires some feedback and 
discussion, doesn't it?

>  How many of them we end up separating will also depend on that.  Let's 
> just wait with those discussions until they're somehow connected with 
> reality.

Counterpoint to this, of course, is that if we _would_ be doing this 
with a PEAR scheme, we'd need to design that into PEAR, preferrably 
without having to re-write PEAR from scratch to accomodate this idea. :-)


-Ronabop

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Ron Chmara]

On Wednesday, April 18, 2001, at 03:53  PM, Stig Sæther Bakken wrote:
> [Ron Chmara <[EMAIL PROTECTED]>]
>> "Frank M. Kromann" wrote:
>>> Is there a list of modules that stays ?
>> A proposed list where it "cuts close to the bone":
>> (since nobody seems to want to be the 'bad guy', I'll start...)
>> M= Main
>> P= Pear
>> (To show/expose any personal bias, items marked with a "*" are ones 
>> that
>> I use on most servers.)
>>

Major Snip_>

>> pcre P
> PCRE should be in the main distribution, a lot of PEAR code relies on
> it.

Snip Again _>

>> xml P
> *BLAM*
> That's the sound of someone shooting himself in the foot.  The PEAR
> installer needs the XML extension. :-)

LOL!

Well, so we've established that for PEAR-based-extensions to work, we 
_must_
have some of the /ext's included in the main distribution, as well as 
some form
of dependancy checking and resolution.

Looks like we're morping into a PEAR design discussion, in some ways. :-)

>> Which would mean that the main distro would have:
>> apache
>> ftp
> Why ftp, when for example curl is out?

My mental approach was to ask myself what the basic, internet-related,
extensions were, the things likely to be used by a beginner before they
grasped more advanced concepts, so they wouldn't have to learn PEAR
interactions to get started with  the bare basics.. That's why I picked
fairly well-known names, packages, and databases. While cURL can
do a _lot_ of things, a newbie trying to ftp, get ldap entires, etc. 
might
be more likely to look for functions directly associated with their end
goal.

That was my reasoning. Not neccesarrily the best reasoning, tho. :-)
It assumes a learning curve for PEAR, etc.

Of course, if we have sockets, we don't actually "need" ftp, imap,
ldap... well, just about anything that writes or reads :-)  but that 
makes the
learning curve a bit steeper. Clifflike, even.

>> mssql
>> mysql
>> pgsql
> I'm willing to bet my best cap that oci8 is much more used than mssql.

The reason that I wound up with these three is that I was looking for the
"top two". To compensate for our Win32 users, I added mssql, because
IIRC the pg port was pretty much a cygwin-kind-of-kludgy-thing...

(Of course, the WIn32 users do add a whole new dimension to this)

Hmmm it sure would be nice to have some actual metrics on extension 
use,
regardless of what gets put into PEAR.

Do we have any logs on www.php.net/manual page views? Could we use
that in some form  to determine extension use (by how frequently an 
extensions'
pages get looked up)? It's not survey based, and it's passive enough that
timeframes that we were collecting data on could be hidden from 
poll-slamming.

Even if we didn't want to log web hits (in general) for performance 
reasons,
(I have no idea if we do) we could at least get a set of numbers unbiased
by personal use/coding styles/etc. by turning it on for a minute or two,
once an hour, for a few days.

>> pspell
> Why?

I guess I use it often  enough that I associate it with being as 
valuable as any other
form of standard string-validation.

It's the hidden biases (and I guess the above is one of mine) that creep 
into
this

I'd be much happier if we had some metrics on use. Maybe we could also
gather information on number of errata notes for each, opened/closed bugs
for each, and pageviews for each. Those numbers should at least point us
in a few directions, where it gives us an idea of what people are 
actually
working with (as compared to just installing, or a web-poll.) Something 
that
wasn't too geographically based would be nice, as well, because 
application
usage (which interacts with the extensions used) varies from country to
country, timezone to timezone.

-Ronabop

--
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-CVS] cvs: php4 / TODO-4.1.txt

[Zeev Suraski]

Guys,

Over the years, there's always been a tendency to think about things which 
are 10 steps ahead.  It never worked, and I don't think it would work here 
either.  Moreover, I don't see any advantage in discussing this now - on 
the contrary - we really have no idea what we're talking about.  Whether or 
not we separate modules *at all* will greatly depend on how good an 
implementation we end up having.  How many of them we end up separating 
will also depend on that.  Let's just wait with those discussions until 
they're somehow connected with reality.

Zeev

At 00:52 19/4/2001, Ron Chmara wrote:
>"Frank M. Kromann" wrote:
> >
> > Is there a list of modules that stays ?
>
>One of the things I've noticed on this topic is that a few
>folks tend to think that their particular technology should
>be used everywhere, and therefore, it should always be
>installed on machines. Of course, this is how we got into
>this convoluted situation in the first place... sure,
>"XYZ functions" may be touted as a future standard for all
>machines, someday, but quite frankly, many of such "standards"
>aren't even close to widespread use and deployment.
>
>In response to Zeev's point that we don't even know if/how PEAR
>will work, yes, I think this discussion isn't about enforcing the
>future. I'd say it's more about finding some better direction.
>
>A proposed list where it "cuts close to the bone":
>(since nobody seems to want to be the 'bad guy', I'll start...)
>
>M= Main
>P= Pear
>(To show/expose any personal bias, items marked with a "*" are ones that
>I use on most servers.)
>
>apache M *
>aspell P *
>bcmath P *
>bz2 P
>calendar P
>ccvs P
>com P
>cpdf P
>crack P *
>ctype P
>curl P
>cybercash P
>cybermut P
>db P
>dba P
>dbase P
>domxml P
>dotnet P
>exif P
>fdf P
>filepro P
>fribidi P
>ftp M *
>gd P *
>gettext P
>gmp P
>hyperwave P
>icap P
>iconv P
>iisfunc M
>imap M *
>informix P
>ingres_ii P
>interbase P
>ircg P
>java P
>ldap M *
>mcal P
>mcrypt P *
>mhash P *
>midgard P
>ming P
>mnogosearch P
>msql P
>mssql M
>muscat P
>mysql M *
>notes P
>oci8 P *
>odbc P
>openssl P
>oracle P
>ovrimos P
>pcre P
>pdf P
>pfpro P
>pgsql M *
>posix P
>printer P
>pspell M *
>qtdom P
>readline P
>recode P
>sablot P
>satellite P
>session M
>shmop M *
>snmp P *
>sockets M *
>standard M * (duh. :-) )
>swf P
>sybase P
>sybase_ct P
>sysvsem M *
>sysvshm M *
>vpopmail P
>wddx P
>xml P
>yaz P
>yp P
>zlib P
>zziplib P
>
>Which would mean that the main distro would have:
>apache
>ftp
>iisfunc
>imap
>ldap
>mssql
>mysql
>pgsql
>pspell
>session
>shmop
>sockets
>standard
>sysvsem
>sysvshm
>
>This keeps the core system functions, basic database
>services for the most widely used DB's, and the basic
>data exchange services (IMAP, ftp, ldap, etc.)
>
>Another way of looking at it would to leave almost everything
>in some use, and only take out the ones which seem to be for
>special purposes and work environments, such as an XML environment
>pieces, or midgard, or hyperwave
>ccvs P
>com P
>cpdf P
>curl P
>cybercash P
>cybermut P
>domxml P
>dotnet P
>exif P
>fdf P
>fribidi P
>gettext P
>hyperwave P
>icap P
>iconv P
>ircg P
>mcal P
>midgard P
>notes P
>openssl P
>pcre P
>pdf P
>pfpro P
>qtdom P
>readline P
>recode P
>sablot P
>vpopmail P
>wddx P
>xml P
>yaz P
>yp P
>zziplib P
>
>And, adding to the pear discussion, working with blocks of
>these would undoubtedly be easier. So if you wanted to
>get the XML package, it would grab xml, domxml, etc...
>
>-Ronabop
>
>--2D426F70|759328624|00101101011001100111
>Personal:  [EMAIL PROTECTED], 520-326-6109, http://www.opus1.com/ron/
>Work: [EMAIL PROTECTED], 520-546-8993, http://www.pnsinc.com/
>The opinions expressed in this email are not necessarily those of myself,
>my employers, or any of the other little voices in my head.

--
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] Bug #10389 Updated: mysql_query(); returns an invalid result resource

[cnewbill]

ID: 10389
Updated by: cnewbill
Reported By: [EMAIL PROTECTED]
Old-Status: Bogus
Status: Feedback
Bug Type: MySQL related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

My bad...it would not return false.  It's been a long long day.

But it would return false if the table jobsc did not exist or the database ue did not 
exist.

-Chris


Previous Comments:
---

[2001-04-18 20:26:15] [EMAIL PROTECTED]
Your query is not returning any rows, and as such mysql_query returns false.  False of 
course is not a valid mysql result and thus the "Warning".

If you are 100% certain the query returns results then that would be a problem, 
otherwise this is not a bug.

Please check this query from the mysql command line and reopen if there really is a 
problem.

-Chris

---

[2001-04-18 19:45:58] [EMAIL PROTECTED]
Here is the code I am using that produces the error:



on the last line is where the error is generated.  In
any browser, I see:

Warning: Supplied argument is not a valid MySQL result
resource ...

My setup contains apache 1.3.19 with the static PHP 4.0.4pl1
module compiled in.  My configure lines for PHP are:

./configure --with-apache=/home/apache_1.3.19
--with-mysql=/usr/local/mysql

/usr/local/mysql is the install directory for mysql

That is all the information I believe I have, and I'm
relatively sure that PHP is not crashing, per say.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10389&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] Bug #10389 Updated: mysql_query(); returns an invalid result resource

[cnewbill]

ID: 10389
Updated by: cnewbill
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: MySQL related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Your query is not returning any rows, and as such mysql_query returns false.  False of 
course is not a valid mysql result and thus the "Warning".

If you are 100% certain the query returns results then that would be a problem, 
otherwise this is not a bug.

Please check this query from the mysql command line and reopen if there really is a 
problem.

-Chris

Previous Comments:
---

[2001-04-18 19:45:58] [EMAIL PROTECTED]
Here is the code I am using that produces the error:



on the last line is where the error is generated.  In
any browser, I see:

Warning: Supplied argument is not a valid MySQL result
resource ...

My setup contains apache 1.3.19 with the static PHP 4.0.4pl1
module compiled in.  My configure lines for PHP are:

./configure --with-apache=/home/apache_1.3.19
--with-mysql=/usr/local/mysql

/usr/local/mysql is the install directory for mysql

That is all the information I believe I have, and I'm
relatively sure that PHP is not crashing, per say.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10389&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] Bug #10389: mysql_query(); returns an invalid result resource

[pmarks]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.4pl1
PHP Bug Type: MySQL related
Bug description:  mysql_query(); returns an invalid result resource

Here is the code I am using that produces the error:



on the last line is where the error is generated.  In
any browser, I see:

Warning: Supplied argument is not a valid MySQL result
resource ...

My setup contains apache 1.3.19 with the static PHP 4.0.4pl1
module compiled in.  My configure lines for PHP are:

./configure --with-apache=/home/apache_1.3.19
--with-mysql=/usr/local/mysql

/usr/local/mysql is the install directory for mysql

That is all the information I believe I have, and I'm
relatively sure that PHP is not crashing, per say.


-- 
Edit Bug report at: http://bugs.php.net/?id=10389&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] Bug #10388: File to file I/O problems

[rainwave]

From: [EMAIL PROTECTED]
Operating system: Windows 98
PHP version:  4.0.4
PHP Bug Type: *Directory/Filesystem functions
Bug description:  File to file I/O problems

Whenever I read from file and write directly to another, such as in this line:
fwrite($fileout,fread($filein,255));
Any occurances of the byte 0x0A will be replaced by 0x0D0A. If I try to read 
indirectly, like this:
$out = fread($filein,255);
fwrite($fileout,$out);
The file will always be saved as ASCII, even if I add the "b" flag to fopen. Is this a 
bug, or am I making a stupid mistake?
Your time and effort are greatly appreciated.
 ~ Joe Ferris ~
P.S. Magic quotes are off


-- 
Edit Bug report at: http://bugs.php.net/?id=10388&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: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Frank M. Kromann]

> [Ron Chmara <[EMAIL PROTECTED]>]
> > "Frank M. Kromann" wrote:
> > > 
> > > Is there a list of modules that stays ?
> > 
> > One of the things I've noticed on this topic is that a few
> > folks tend to think that their particular technology should
> > be used everywhere, and therefore, it should always be
> > installed on machines. Of course, this is how we got into
> > this convoluted situation in the first place... sure,
> > "XYZ functions" may be touted as a future standard for all
> > machines, someday, but quite frankly, many of such "standards"
> > aren't even close to widespread use and deployment.
> > 
> > In response to Zeev's point that we don't even know if/how PEAR
> > will work, yes, I think this discussion isn't about enforcing the
> > future. I'd say it's more about finding some better direction.
> > 
> > A proposed list where it "cuts close to the bone":
> > (since nobody seems to want to be the 'bad guy', I'll start...)
> > 
> > M= Main
> > P= Pear
> > (To show/expose any personal bias, items marked with a "*" are ones that
> > I use on most servers.)
> > 
> > apache M *
> > aspell P *
> > bcmath P *
> > bz2 P
> > calendar P
> > ccvs P
> > com P
> > cpdf P
> > crack P *
> > ctype P
> > curl P
> > cybercash P
> > cybermut P
> > db P
> > dba P
> 
> I'd like to see dba stay.
> 
> > dbase P
> > domxml P
> > dotnet P
> > exif P
> > fdf P
> > filepro P
> > fribidi P
> > ftp M *
> > gd P *
> > gettext P
> > gmp P
> > hyperwave P
> > icap P
> > iconv P
> 
> The iconv library in itself is useful enough that we should try to
> keep this one within PHP, maybe even integrate it tighter.
> 
> > iisfunc M
> > imap M *
> > informix P
> > ingres_ii P
> > interbase P
> > ircg P
> > java P
> > ldap M *
> > mcal P
> > mcrypt P *
> > mhash P *
> > midgard P
> > ming P
> > mnogosearch P
> > msql P
> > mssql M
> > muscat P
> > mysql M *
> > notes P 
> > oci8 P *
> > odbc P 
> > openssl P
> > oracle P
> > ovrimos P
> > pcre P
> 
> PCRE should be in the main distribution, a lot of PEAR code relies on
> it.
> 
> > pdf P
> > pfpro P
> > pgsql M *
> > posix P
> > printer P
> > pspell M *
> > qtdom P
> > readline P
> > recode P
> > sablot P
> > satellite P
> > session M 
> > shmop M *
> > snmp P *
> > sockets M *
> > standard M * (duh. :-) )
> > swf P
> > sybase P
> > sybase_ct P
> > sysvsem M *
> > sysvshm M *
> > vpopmail P
> > wddx P
> > xml P
> 
> *BLAM*
> 
> That's the sound of someone shooting himself in the foot.  The PEAR
> installer needs the XML extension. :-)
> 
> > yaz P
> > yp P
> > zlib P
> > zziplib P
> > 
> > Which would mean that the main distro would have:
> > apache
> > ftp
> 
> Why ftp, when for example curl is out?
> 
> > iisfunc
> > imap
> > ldap
> > mssql
> > mysql
> > pgsql
> 
> I'm willing to bet my best cap that oci8 is much more used than mssql.

That depends on the platform I think. MSSQL is Win32 only so far though I'm planning 
an integration with FreeTDS to allow support from Linux/Unix.

iisfunc and printer are other Win32 only extension and should be in PEAR, IMHO.

> 
> > pspell
> 
> Why?
> 
> > session
> > shmop
> > sockets
> > standard
> > sysvsem
> > sysvshm
> > 
> > This keeps the core system functions, basic database
> > services for the most widely used DB's, and the basic
> > data exchange services (IMAP, ftp, ldap, etc.)
> > 
> > Another way of looking at it would to leave almost everything
> > in some use, and only take out the ones which seem to be for
> > special purposes and work environments, such as an XML environment
> > pieces, or midgard, or hyperwave
> > ccvs P
> > com P
> > cpdf P
> > curl P
> > cybercash P
> > cybermut P
> > domxml P
> > dotnet P
> > exif P
> > fdf P
> > fribidi P
> > gettext P
> > hyperwave P
> > icap P
> > iconv P
> > ircg P
> > mcal P
> > midgard P
> > notes P 
> > openssl P
> > pcre P
> > pdf P
> > pfpro P
> > qtdom P
> > readline P
> > recode P
> > sablot P
> > vpopmail P
> > wddx P
> > xml P
> > yaz P
> > yp P
> > zziplib P
> > 
> > And, adding to the pear discussion, working with blocks of these
> > would undoubtedly be easier. So if you wanted to get the XML
> > package, it would grab xml, domxml, etc...
> 
> Well, if you use domxml, you probably wouldn't use xml, because they
> offer two different abstractions/approaches to solve more or less the
> same problem.  But such blocks (or bundles, like CPAN calls them) are
> a good idea.
> 
> It'd be interesting to hear what extension maintainers think.
> 
>  - Stig
> 

I think it is important to make sure all extenstions are in sync with the main php 
repository. Especially on Windows where binary distributions are much used. It is not 
possible to use old versions of the dll's with new versions of the php binaries. 
Making php build with CygWin might be a solution for this. Mebye this should be on the 
to-do list ?

I also think it would be a bad idea to remove some database modules an not others. 
That would be the same as saying that php should be used with one of the databases 
su

[PHP-DEV] Bug #10387: session_register doesn't populate $HTTP_SESSION_VARS

[eoghain]

From: [EMAIL PROTECTED]
Operating system: Solaris 8.0
PHP version:  4.0.4pl1
PHP Bug Type: *Session related
Bug description:  session_register doesn't populate $HTTP_SESSION_VARS

I don't know if this is a bug or that session_register() just doesn't work the way I 
expect.  In a single script if I use session_register() then try to access 
$HTTP_SESSION_VARS["var"] I get a null entry.  I'd expect that as soon as I register a 
variable that I should be able to find it in the $HTTP_SESSION_VARS.




-- 
Edit Bug report at: http://bugs.php.net/?id=10387&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: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Stig Sæther Bakken]

[Ron Chmara <[EMAIL PROTECTED]>]
> "Frank M. Kromann" wrote:
> > 
> > Is there a list of modules that stays ?
> 
> One of the things I've noticed on this topic is that a few
> folks tend to think that their particular technology should
> be used everywhere, and therefore, it should always be
> installed on machines. Of course, this is how we got into
> this convoluted situation in the first place... sure,
> "XYZ functions" may be touted as a future standard for all
> machines, someday, but quite frankly, many of such "standards"
> aren't even close to widespread use and deployment.
> 
> In response to Zeev's point that we don't even know if/how PEAR
> will work, yes, I think this discussion isn't about enforcing the
> future. I'd say it's more about finding some better direction.
> 
> A proposed list where it "cuts close to the bone":
> (since nobody seems to want to be the 'bad guy', I'll start...)
> 
> M= Main
> P= Pear
> (To show/expose any personal bias, items marked with a "*" are ones that
> I use on most servers.)
> 
> apache M *
> aspell P *
> bcmath P *
> bz2 P
> calendar P
> ccvs P
> com P
> cpdf P
> crack P *
> ctype P
> curl P
> cybercash P
> cybermut P
> db P
> dba P

I'd like to see dba stay.

> dbase P
> domxml P
> dotnet P
> exif P
> fdf P
> filepro P
> fribidi P
> ftp M *
> gd P *
> gettext P
> gmp P
> hyperwave P
> icap P
> iconv P

The iconv library in itself is useful enough that we should try to
keep this one within PHP, maybe even integrate it tighter.

> iisfunc M
> imap M *
> informix P
> ingres_ii P
> interbase P
> ircg P
> java P
> ldap M *
> mcal P
> mcrypt P *
> mhash P *
> midgard P
> ming P
> mnogosearch P
> msql P
> mssql M
> muscat P
> mysql M *
> notes P 
> oci8 P *
> odbc P 
> openssl P
> oracle P
> ovrimos P
> pcre P

PCRE should be in the main distribution, a lot of PEAR code relies on
it.

> pdf P
> pfpro P
> pgsql M *
> posix P
> printer P
> pspell M *
> qtdom P
> readline P
> recode P
> sablot P
> satellite P
> session M 
> shmop M *
> snmp P *
> sockets M *
> standard M * (duh. :-) )
> swf P
> sybase P
> sybase_ct P
> sysvsem M *
> sysvshm M *
> vpopmail P
> wddx P
> xml P

*BLAM*

That's the sound of someone shooting himself in the foot.  The PEAR
installer needs the XML extension. :-)

> yaz P
> yp P
> zlib P
> zziplib P
> 
> Which would mean that the main distro would have:
> apache
> ftp

Why ftp, when for example curl is out?

> iisfunc
> imap
> ldap
> mssql
> mysql
> pgsql

I'm willing to bet my best cap that oci8 is much more used than mssql.

> pspell

Why?

> session
> shmop
> sockets
> standard
> sysvsem
> sysvshm
> 
> This keeps the core system functions, basic database
> services for the most widely used DB's, and the basic
> data exchange services (IMAP, ftp, ldap, etc.)
> 
> Another way of looking at it would to leave almost everything
> in some use, and only take out the ones which seem to be for
> special purposes and work environments, such as an XML environment
> pieces, or midgard, or hyperwave
> ccvs P
> com P
> cpdf P
> curl P
> cybercash P
> cybermut P
> domxml P
> dotnet P
> exif P
> fdf P
> fribidi P
> gettext P
> hyperwave P
> icap P
> iconv P
> ircg P
> mcal P
> midgard P
> notes P 
> openssl P
> pcre P
> pdf P
> pfpro P
> qtdom P
> readline P
> recode P
> sablot P
> vpopmail P
> wddx P
> xml P
> yaz P
> yp P
> zziplib P
> 
> And, adding to the pear discussion, working with blocks of these
> would undoubtedly be easier. So if you wanted to get the XML
> package, it would grab xml, domxml, etc...

Well, if you use domxml, you probably wouldn't use xml, because they
offer two different abstractions/approaches to solve more or less the
same problem.  But such blocks (or bundles, like CPAN calls them) are
a good idea.

It'd be interesting to hear what extension maintainers think.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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] possible --extension-dir directive?

[Stig Sæther Bakken]

["Jason Greene" <[EMAIL PROTECTED]>]
> Hi Stig,
> > I changed this to /usr/local/lib/php/ in the patch Sascha
> > reverted, but I'll put that part back.  The APISPEC part should
> > definitely be included, or we'll have a boatload of mails asking why
> > loading module X failed.  If for example some Linux distributions want
> > to skip it (Mandrake cooker does at least), that's up to them.
> >
> > Anyway, the APISPEC will be shortened from "20001222-no-debug-non-zts"
> > to just "20001222", and the "extensions" part of the path is skipped.
> > The PEAR stuff is moved to /usr/local/share/php.  Both of these paths
> > can be set with the --datadir and --libdir configure options.
> >
> > I try to put it back in tomorrow.
> 
> Ok, sounds good.
> What do you think of the possibility of autobuilding a php.ini file
> with extensions installed, similar to apache. If one already exists,
> it could install under a different name?

Adding extension directives to php.in could be done by the PEAR
installer if you install a package with extension files.  Maybe it
should add new extensions commented out by default, or it could be a
config option.  I'll think about it.

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Ron Chmara]

"Frank M. Kromann" wrote:
> 
> Is there a list of modules that stays ?

One of the things I've noticed on this topic is that a few
folks tend to think that their particular technology should
be used everywhere, and therefore, it should always be
installed on machines. Of course, this is how we got into
this convoluted situation in the first place... sure,
"XYZ functions" may be touted as a future standard for all
machines, someday, but quite frankly, many of such "standards"
aren't even close to widespread use and deployment.

In response to Zeev's point that we don't even know if/how PEAR
will work, yes, I think this discussion isn't about enforcing the
future. I'd say it's more about finding some better direction.

A proposed list where it "cuts close to the bone":
(since nobody seems to want to be the 'bad guy', I'll start...)

M= Main
P= Pear
(To show/expose any personal bias, items marked with a "*" are ones that
I use on most servers.)

apache M *
aspell P *
bcmath P *
bz2 P
calendar P
ccvs P
com P
cpdf P
crack P *
ctype P
curl P
cybercash P
cybermut P
db P
dba P
dbase P
domxml P
dotnet P
exif P
fdf P
filepro P
fribidi P
ftp M *
gd P *
gettext P
gmp P
hyperwave P
icap P
iconv P
iisfunc M
imap M *
informix P
ingres_ii P
interbase P
ircg P
java P
ldap M *
mcal P
mcrypt P *
mhash P *
midgard P
ming P
mnogosearch P
msql P
mssql M
muscat P
mysql M *
notes P 
oci8 P *
odbc P 
openssl P
oracle P
ovrimos P
pcre P
pdf P
pfpro P
pgsql M *
posix P
printer P
pspell M *
qtdom P
readline P
recode P
sablot P
satellite P
session M 
shmop M *
snmp P *
sockets M *
standard M * (duh. :-) )
swf P
sybase P
sybase_ct P
sysvsem M *
sysvshm M *
vpopmail P
wddx P
xml P
yaz P
yp P
zlib P
zziplib P

Which would mean that the main distro would have:
apache
ftp
iisfunc
imap
ldap
mssql
mysql
pgsql
pspell
session
shmop
sockets
standard
sysvsem
sysvshm

This keeps the core system functions, basic database
services for the most widely used DB's, and the basic
data exchange services (IMAP, ftp, ldap, etc.)

Another way of looking at it would to leave almost everything
in some use, and only take out the ones which seem to be for
special purposes and work environments, such as an XML environment
pieces, or midgard, or hyperwave
ccvs P
com P
cpdf P
curl P
cybercash P
cybermut P
domxml P
dotnet P
exif P
fdf P
fribidi P
gettext P
hyperwave P
icap P
iconv P
ircg P
mcal P
midgard P
notes P 
openssl P
pcre P
pdf P
pfpro P
qtdom P
readline P
recode P
sablot P
vpopmail P
wddx P
xml P
yaz P
yp P
zziplib P

And, adding to the pear discussion, working with blocks of
these would undoubtedly be easier. So if you wanted to
get the XML package, it would grab xml, domxml, etc...

-Ronabop

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

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

[PHP-DEV] CVS Account Request

[CVS Account Request]

Full name: Thomas Schöfbeck
Email: [EMAIL PROTECTED]
ID: tom
Purpose: Helping Egon with the German Translation.

-- 
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] Bug #10386: Uploaded files do not save.

[kyle]

From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version:  4.0.4
PHP Bug Type: HTTP related
Bug description:  Uploaded files do not save.

I am not sure where the fault lies here... (very possibly on me)

All of the variables in $HTTP_POST_FILES are correct, yet the file doesn't actually 
save. I'm running PHP as Administrator, so I don't think it's a problem with 
permissions.

My upload_tmp_dir is set to "c:\windows\temp" and when I upload a file.. it does not 
appear there. I've also tried setting upload_tmp_dir to "\", "\windows\temp" and 
checked $HTTP_POST_FILES["song"]["tmp_name"] to be sure... still no luck.

  
   

 Title: 
 


 Artist: 
 
  
   
  
 

...

 Upload: 
 

   
   
   
   


-- 
Edit Bug report at: http://bugs.php.net/?id=10386&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] Bug #10385: Browser Crashes sometimes if there's an include

[TobiasGutzmann]

From: [EMAIL PROTECTED]
Operating system: Redhat 7
PHP version:  4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description:  Browser Crashes sometimes if there's an include

Hello!

Some browsers (IE specifically) crash sometimes when calling php-pages. We also have 
some ColdFusion-Script on the same server, the problem doesn't occur there.
We tracked down the problem to include's.
I've read about that problem in the bug database several times, however, we have 
apache 1.3.14 , the problem was said to be solved with apache 1.3.9 . 
I don't think it's an apache-problem as ColdFusion doesn't crash the browser...

Any ideas?

Thanks

Tobias


-- 
Edit Bug report at: http://bugs.php.net/?id=10385&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: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 11:55 AM 4/18/2001 +0100, Wez Furlong wrote:
>On 2001-04-17 21:08:15, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > Any chance you can write a small readme file or add some explanations to
> > the .h file to give people like me a small overview of the abstraction so
> > that it will be easier to start diving into the code?
>
>I've just commited README.STREAMS to the php4 root.

I'm glad I asked you to write this document.
It's extremely helpful for getting a good and quick overview of the streams.
Great job and again, this is something I've wanted to see for a long time!

Andi


-- 
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] Bug #10384: read() buffer memory not freed

[rod]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.2
PHP version:  4.0.4pl1
PHP Bug Type: Sockets related
Bug description:  read() buffer memory not freed

Using the  following code:



(The function procMsg() is not relevent as for bug testing is set to return 'test')

Running this script causes memory to be consumed and not released with each 
connection.  I've narrowed the problem down to the read() function as I can affect the 
rate of memory consumption by modifying the length argument.  Evidently the buffer is 
not freed.




-- 
Edit Bug report at: http://bugs.php.net/?id=10384&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] access 97 error messages.

[Derick Rethans]

Erm,

this is not the MCSE support list, but the PHP Development list.

Derick Rethans

On 18 Apr 2001, mark damstra wrote:

> Hi,
>
>
> I am trying to open a database in access 97 written for access 97 in windows 2000. I 
>get access error messages 2950. This is after I have uninstalled office 97 and access 
>97 and then reinstalled them with the "select all" option for both. Do you have any 
>thoughts? Access 20 is also on this machine for the program we are running but I 
>didnt touch it?
> What do you think?
>
> Mark Damstra
> MCSE
>
> --
> Totally Amazing Search Results - Just C4 Yourself!
> http://www.C4.com - Total Search Technology
>
> --
> 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]
>

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands
-


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

[PHP-DEV] Bug #10383: Receiving an HTTP PUT, rather than sending one

[matt]

From: [EMAIL PROTECTED]
Operating system: RH Linux
PHP version:  4.0.3pl1
PHP Bug Type: HTTP related
Bug description:  Receiving an HTTP PUT, rather than sending one

I have been trying to use PUT method support, as described in the PHP manual in the 
section "Handling File Uploads."  The documentation says that when the request type is 
PUT, the body of the request is saved in a temporary file (in the directory specified 
in php.ini), and the name of the file is saved in a variable called $PHP_PUT_FILENAME 
(I tried $PHP_UPLOAD_FILE_NAME too, there is an inconsistency in the documentation, 
but neither worked anyway).

As the documentation says, I put a line in httpd.conf (I am using apache 1.3.12) that 
says:

Script PUT /path/to/myscript.php

This works great...all PUT requests are getting redirected to my script.  I know this, 
because the other parts that don't deal with the file are getting executed, and I was 
able to send HTML back to the client in an "echo" statement.

Now, the value of the variable $PHP_PUT_FILENAME is empty.  I looked at various other 
bugs alluding to this issue, and made sure of a couple things:  in php.ini, 
register_globals is on, and the temporary file directory for uploads is also set (to 
/tmp). I also tried $PHP_UPLOADED_FILE_NAME (which is in the documentation example), 
to no avail.  I am using an HTTP/1.1 PUT, not HTTP/1.0 as someone else did in an 
earlier bug.

Next, I searched through all of the most recent sources for PHP_PUT, PHP_UPLOAD, and 
other such things, and came up with nothing.  Nowhere in the PHP source is there any 
mention of such a variable.

In one of the other bugs mentioning this problem, somebody mentioned cURL as an 
alternative.  cURL, as far as I understand, is a set of functions that allow you to 
*make* PUT requests (and many other types of requests), but do not allow you to 
*receive* PUT requests, which is what I am trying to do.

I next tried to get at the raw data of the PUT directly, figuring perhaps the 
$HTTP_RAW_POST_DATA would have the data or fopen("php://stdin","rb") would, but 
neither worked.  For the latter, PHP already reads all of stdin, so nothing is left 
over to read, and for the former, I'm not sure that the variable ever gets set (I read 
a couple of mailing list posts about trouble with the HTTP_RAW_POST_DATA variable, I 
don't think it exists anymore).  Is there a published workaround somewhere?

For simplicity's sake, I'm not including my php_info() dump in this submission, but 
I'll be happy to give you one if you want it. 

Any insight into this would be much appreciated.  If receiving PUT requests is no 
longer supported, at what point was that support dropped?  It would be cool to have 
the documentation in that section updated if it was in fact dropped.  I know this is 
kind of an obscure problem from the perspective of the WWW, as only a couple browsers 
use PUT, but when developing applications it's a lot easier to use PUT because no 
encoding is involved.

Please let me know if there is any more information you need from me.

-Matt


-- 
Edit Bug report at: http://bugs.php.net/?id=10383&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] access 97 error messages.

[mark damstra]

Hi,


I am trying to open a database in access 97 written for access 97 in windows 2000. I 
get access error messages 2950. This is after I have uninstalled office 97 and access 
97 and then reinstalled them with the "select all" option for both. Do you have any 
thoughts? Access 20 is also on this machine for the program we are running but I didnt 
touch it? 
What do you think?

Mark Damstra
MCSE

--
Totally Amazing Search Results - Just C4 Yourself!
http://www.C4.com - Total Search Technology

-- 
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] Bug #10382: array_multisort() doesn't work as advertised

[mnino]

From: [EMAIL PROTECTED]
Operating system: Linux Redhat 6.2
PHP version:  4.0.4pl1
PHP Bug Type: Documentation problem
Bug description:  array_multisort() doesn't work as advertised

Sorry, I submitted this to the 'add notes' for the online manual thinking that was 
where I might get information.

What I did is  cut-&-pasted the code from documentation for the function 
array_multisort() into a brand new PHP script and added some print_r() calls. The 
function array_multisort() doesn't work as adverstised. :] It generates an error: 
Warning: Argument 3 to array_multisort() is expected to be an array in 
array_multisort.php on line 9 

Here is the PHP file array_multisort.php: 
 
 
 

Can anyone assist?


-- 
Edit Bug report at: http://bugs.php.net/?id=10382&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 #10378 Updated: When script timout occurs PHP crashes with ODBC

[martin]

ID: 10378
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Reproduceable crash
Description: When script timout occurs PHP crashes with ODBC

This timeout is most likely coming from Internet Explorer.

IE will terminate the HTTP session if it has not received a response back from the 
server in 300 seconds.

You can mitigate this problem by doing a:

print "."; flush();

in your loop.

PHP will continue forever (or until the limits defined in php.ini have been met).  
Personally I've had PHP doing some intensive stuff with this - one script runs for 2 
days on a PIII-800 - until I rewrote it in perl so it finishes in 1 hour ;-)

Paul.

Previous Comments:
---

[2001-04-18 09:55:33] [EMAIL PROTECTED]
Does it crash with an Access Violation, or does it just stop?

---

[2001-04-18 09:47:22] [EMAIL PROTECTED]
When script timeout occurs (in my case moving data from a textfile to a database, many 
inserts)
PHP prints out the error message (exceeded 300 sec timeout) and then crashes.

The error does not occur if I do a simple while(forewer) so it must be related to open 
connections.

Sorry that I'm unable to find out further whats cousing this.

---


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


-- 
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] Best non-tackified grip enhancer for golfers,

[aNzGK0A8x]

NO SALES PITCH, NO PRESSURE, NO NOTHING. 

Just the best non-tackified grip enhancer you'll ever use for your golf game, 
GUARANTEED, or your money back.

 From football's #1 specialty product company, SUPAGRIP25 is now available to golf 
enthusiasts everywhere.
 
Click here 
http://www.creativefootball.com
 to see the product that is taking all sports (where a good grip is essential) by 
storm! 

While you're there be sure to check out our "who uses our products" page, what you see 
just might surprise you. 
You really didn't think they make those great catches on talent alone, did you? 


Transmissions to you by the sender of 'this' email will be stopped promptly by sending 
an e-mail with "unsubscribe" in the subject line. Simply hit reply and send and we 
will remove you from our database. Please Note-This is a one time mailing.Thank you.

-- 
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] 4.0.6 and gd 2

[Wez Furlong]

On 2001-04-18 15:25:19, "Kurth Bemis" <[EMAIL PROTECTED]> wrote:
> Now i'm getting all sorts of problems.loook

As a hint, you might want to make sure that you have only one set of gd headers 
installed, and only one libgd.so.

Try setting --with-gd=/path/to/libgd.so

I would like to see the config.log file from the build you described.

If you still have problems, open a bug report.


--Wez.


-- 
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] Bug #10381: array_sum() on an undefined variable kills php

[Adam Wright]

Seems to be fixed in the latest CVS.

adamw

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 18, 2001 3:58 PM
Subject: [PHP-DEV] Bug #10381: array_sum() on an undefined variable kills
php


> From: [EMAIL PROTECTED]
> Operating system: Red Hat Linux 6.2
> PHP version:  4.0.4pl1
> PHP Bug Type: Reproduceable crash
> Bug description:  array_sum() on an undefined variable kills php
>
> Using array_sum() on an undefined causes php to core dump.
>
> uname:
> Linux redbox 2.2.17-14enterprise #1 SMP Mon Feb 5 18:31:31 EST 2001 i686
unknown
>
> configure:
> './configure' '--with-apache=../apache_1.3.19' '--enable-gd-imgstrttf'
'--with-gd' '--with-ttf' '--with-ldap' '--with-mysql=/usr' '--with-readline'
'--enable-sysvsem' '--enable-sysvshm' '--enable-shmop' '--with-zlib'
'--with-imap' '--with-imap-ssl' '--with-kerberos'
'--with-oracle=/opt/oracle/8.1.7' '--with-oci8=/opt/oracle/8.1.7'
'--with-gdbm' '--enable-dbase' '--with-snmp' '--enable-ucd-snmp-hack'
'--with-gettext' '--enable-track-vars' '--enable-versioning' '--enable-ftp'
'--enable-bcmath' '--with-pgsql' '--enable-calendar'
>
> [root@redbox address_book]# ls -l test.php
> -rwxr-xr-x1 root root   50 Apr 18 16:54 test.php
> [root@redbox address_book]# cat test.php
> #!/usr/local/bin/php -q
> 
> [root@redbox address_book]# ./test.php
> Segmentation fault (core dumped)
>
> If $a is defined this doesn't happen:
>
> [root@redbox address_book]# cat test.php
> #!/usr/local/bin/php -q
> 
> [root@redbox address_book]# ./test.php
> 0
>
>
> --
> Edit Bug report at: http://bugs.php.net/?id=10381&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 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-CVS] cvs: php4 / TODO-4.1.txt

[Andi Gutmans]

At 11:55 AM 4/18/2001 +0100, Wez Furlong wrote:
>On 2001-04-17 21:08:15, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > Any chance you can write a small readme file or add some explanations to
> > the .h file to give people like me a small overview of the abstraction so
> > that it will be easier to start diving into the code?
>
>I've just commited README.STREAMS to the php4 root.

Great! I'll read it soon.
We should probably put it in php4/main or create a php4/doc and move docs 
there. The less we clutter the main directory the better.

Andi


-- 
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 #10092 Updated: Socket fgets memory and CPU usage problem

[jakub]

ID: 10092
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Sockets related
Description: Socket fgets memory and CPU usage problem

The code snippet:
test.php:



Test



PHP POP3 Socket Test

 ".\r\n")
{
  if (!($line)) break;

  $length += strlen($line);
} 

echo "Round $i/$round, Transfered $length";
flush();
  }
  
  fclose($socket);
  
  echo "Total bytes received: $length";
?>




Previous Comments:
---

[2001-03-31 17:18:02] [EMAIL PROTECTED]
Please add a self containing short script into this report
which can be used to reproduce this problem.

--Jani


---

[2001-03-31 09:56:39] [EMAIL PROTECTED]
When using the fgets function for large data transmission the data transmitted are 
never freed from memory. When using fgets with files it works fine. The PHP CGI module 
starts to utilize the CPU to 100% and never ends, stops processing and doesn't exit 
the fgets function after few read cycles. This happens only on Windows PHP CGI. We 
tested Apache and that worked fine. Even the previous version of PHP did that. Large 
data I'm talking about is 8MB and above. 

---


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


-- 
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 #10092 Updated: Socket fgets memory and CPU usage problem

[Jakub]

Hi Jani
this is the code that reproduces the bug. I've posted it to the bug db
too
Cheers
Jakub
-



Test



PHP POP3 Socket Test

 ".\r\n")
{
  if (!($line)) break;

  $length += strlen($line);
} 

echo "Round $i/$round, Transfered $length";
flush();
  }
  
  fclose($socket);
  
  echo "Total bytes received: $length";
?>


-
> ID: 10092
> Updated by: sniper
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Feedback
> Bug Type: Sockets related
> Assigned To:
> Comments:
> 
> Please add a self containing short script into this report
> 
> which can be used to reproduce this problem.
> 
> --Jani
> 
> Previous Comments:
> ---
> 
> [2001-03-31 09:56:39] [EMAIL PROTECTED]
> When using the fgets function for large data transmission the data transmitted are 
>never freed from memory. When using fgets with files it works fine. The PHP CGI 
>module starts to utilize the CPU to 100% and never ends, stops processing and doesn't 
>exit the fgets function after few read cycles. This happens only on Windows PHP CGI. 
>We tested Apache and that worked fine. Even the previous version of PHP did that. 
>Large data I'm talking about is 8MB and above.
> 
> ---
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=10092&edit=2

-- 
IceWarp Software
E-mail: [EMAIL PROTECTED]
Web: http://www.icewarp.com
Fax: +1(240)5254912
ICQ: 1255673

-- 
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] Bug #10381: array_sum() on an undefined variable kills php

[pgl]

From: [EMAIL PROTECTED]
Operating system: Red Hat Linux 6.2
PHP version:  4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description:  array_sum() on an undefined variable kills php

Using array_sum() on an undefined causes php to core dump.

uname:
Linux redbox 2.2.17-14enterprise #1 SMP Mon Feb 5 18:31:31 EST 2001 i686 unknown

configure:
'./configure' '--with-apache=../apache_1.3.19' '--enable-gd-imgstrttf' '--with-gd' 
'--with-ttf' '--with-ldap' '--with-mysql=/usr' '--with-readline' '--enable-sysvsem' 
'--enable-sysvshm' '--enable-shmop' '--with-zlib' '--with-imap' '--with-imap-ssl' 
'--with-kerberos' '--with-oracle=/opt/oracle/8.1.7' '--with-oci8=/opt/oracle/8.1.7' 
'--with-gdbm' '--enable-dbase' '--with-snmp' '--enable-ucd-snmp-hack' '--with-gettext' 
'--enable-track-vars' '--enable-versioning' '--enable-ftp' '--enable-bcmath' 
'--with-pgsql' '--enable-calendar'

[root@redbox address_book]# ls -l test.php 
-rwxr-xr-x1 root root   50 Apr 18 16:54 test.php
[root@redbox address_book]# cat test.php 
#!/usr/local/bin/php -q

[root@redbox address_book]# ./test.php 
Segmentation fault (core dumped)

If $a is defined this doesn't happen:

[root@redbox address_book]# cat test.php 
#!/usr/local/bin/php -q

[root@redbox address_book]# ./test.php 
0


-- 
Edit Bug report at: http://bugs.php.net/?id=10381&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] 4.0.6 and gd 2

[Kurth Bemis]

Now i'm getting all sorts of problems.loook

my config line

./configure --with-mysql=/usr/local/mysql 
--with-apache=/usr/src/apache_1.3.19 --enable-ftp --with-gd 
--with-jpeg-dir=/usr/src/jpeg-6b --with-png-dir=/usr/local/lib 
--with-freetype-dir

yields

...
checking whether to enable FTP support... yes
checking whether to enable truetype string function in gd... no
checking for libjpeg (needed by gd-1.8+)... yes
checking for jpeg_read_header in -ljpeg... yes
checking for libpng (needed by gd-2.0)... yes
checking for png_info_init in -lpng... yes
checking for libXpm (needed by gd-1.8+)... no
configure: warning: If configure fails try --with-xpm-dir=
checking for freetype(2) (needed by gd 2.0+)... yes
checking whether to include GD support... yes (static)
checking for compress in -lz... no
checking for png_info_init in -lpng... (cached) yes
checking for gdImageString16 in -lgd... no
checking for gdImagePaletteCopy in -lgd... no
checking for gdImageColorClosestHWB in -lgd... no
checking for gdImageColorResolve in -lgd... no
checking for gdImageCreateFromPng in -lgd... no
checking for gdImageCreateFromGif in -lgd... no
checking for gdImageWBMP in -lgd... no
checking for gdImageCreateFromJpeg in -lgd... no
checking for gdImageCreateFromXpm in -lgd... no
checking for gdImageCreateTrueColor in -lgd... no
checking for gdImageSetTile in -lgd... no
checking for gdImageSetBrush in -lgd... no
checking whether to include FreeType 1.x support... no - FreeType 2.x is to 
be used instead
checking for T1lib support... no
..

lets attempt a make

..
Making all in gd
make[2]: Entering directory `/usr/src/php4-200104171745/ext/gd'
make[3]: Entering directory `/usr/src/php4-200104171745/ext/gd'
gcc  -I. -I/usr/src/php4-200104171745/ext/gd 
-I/usr/src/php4-200104171745/main -I/usr/src/php4-200104171745 
-I/usr/src/apache_1.3.19/src/include -I/usr/src/apache_1.3.19/src/os/unix 
-I/usr/src/php4-200104171745/Zend -I/usr/local/include/freetype2/freetype 
-I/usr/local/mysql/include/mysql 
-I/usr/src/php4-200104171745/ext/xml/expat/xmltok 
-I/usr/src/php4-200104171745/ext/xml/expat/xmlparse 
-I/usr/src/php4-200104171745/TSRM  -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -g 
-O2  -c gd.c && touch gd.lo
gd.c:91: conflicting types for `gdIOCtx'
/usr/local/include/gd_io.h:18: previous declaration of `gdIOCtx'
make[3]: *** [gd.lo] Error 1
make[3]: Leaving directory `/usr/src/php4-200104171745/ext/gd'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/usr/src/php4-200104171745/ext/gd'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/php4-200104171745/ext'
make: *** [all-recursive] Error 1
.

any thoughts?  I'm thinking that i may rebuild gd and see if that clears up 
the problem.

~kurth


-- 
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] Bug #10252 Updated: strcat() used on uninitialized string

[kalowsky]

ID: 10252
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: ODBC related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

pssst... Joey... you need to submit the changes to CVS BEFORE you close the bug ;)

Previous Comments:
---

[2001-04-17 23:42:00] [EMAIL PROTECTED]
Closed in CVS. I actually used strlcpy() instead, but same
general concept.

---

[2001-04-16 23:10:35] [EMAIL PROTECTED]
Joey Smith has(had?) a patch he was considering applying that should fix this problem 
as well... waiting to hear back from him currently on it's status...

---

[2001-04-09 15:30:56] [EMAIL PROTECTED]
I was getting intermittent errors connecting to databases. 
Sometimes it would work fine, sometimes my connect string
would turn to gibberish and sometimes the process would
segfault.

On further examination, in
ext/odbc/php_odbc.c:odbc_sqlconnect(), within the
if(strstr(char *)db,";") block, there is a line
"strcat(ldb,db);".  At this point in the code, ldb was just
emalloced, and had uninitialized contents.  I think strcpy()
is more appopriate here, and changing the code to this seems
to have cleared up my errors.

Thank you very much.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10252&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] Bug #10380: dba_*open with mode 'c' problem

[mrobinso]

From: [EMAIL PROTECTED]
Operating system: RedHat 7.0
PHP version:  4.0 Latest CVS (18/04/2001)
PHP Bug Type: DBM/DBA related
Bug description:  dba_*open with mode 'c' problem

db3 support compiled in without problems, all functions
available and working.

apache-1.3.19, php snapshot from today.
db3 3.1.14-6, devel, utils, stock rpm install in rhl-7.0.

database directory is "drwxrwxrwt";

using dba_open or dba_popen, with mode 'c', if the
database doesn't exist, it is created and the function
performs as expected. If the database already exists,
the function should open the database for read/write
access. Instead, it throws:

driver initialization failed...

despite having just created the database itself.

For example:

$dbpath = "/usr/local/db3data/test/testdb3.db3";
$dbmode = "c";
$dbhandler = "db3";

$dbh = dba_popen($dbpath,$dbmode,$dbhandler);
$mykey = "mykey";
$myval = "Hello World";
if (!dba_exists($mykey,$dbh)) {
   echo "Key doesn't exist, adding it.\n";
   dba_insert ($mykey, $myval, $dbh);   
} 
else {
   $storedval = dba_fetch($mykey, $dbh);
   echo $storedval;
}

This snippet will work as expected if the database
doesn't exist. If it does, the error occurs, where
according to the docs it should just open the database
for read write access.

If the database exists and I change the mode to 'w',
expected behaviour occurs.




-- 
Edit Bug report at: http://bugs.php.net/?id=10380&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] Bug #10378 Updated: When script timout occurs PHP crashes with ODBC

[derick]

ID: 10378
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Reproduceable crash
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Does it crash with an Access Violation, or does it just stop?

Previous Comments:
---

[2001-04-18 09:47:22] [EMAIL PROTECTED]
When script timeout occurs (in my case moving data from a textfile to a database, many 
inserts)
PHP prints out the error message (exceeded 300 sec timeout) and then crashes.

The error does not occur if I do a simple while(forewer) so it must be related to open 
connections.

Sorry that I'm unable to find out further whats cousing this.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10378&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] Bug #10377 Updated: PHP forces illegal HTML

[derick]

ID: 10377
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Feature/Change Request
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

1. $HTTP_GET_VARS is an array (try var_dump ($HTTP_GET_VARS));
2. You can get the whole query string: $HTTP_SERVER_VARS["QUERY_STRING"];

and

3. You don't need to use the [], it's up to you how you use it. It merely gives you a 
nice function.

Previous Comments:
---

[2001-04-18 09:44:41] [EMAIL PROTECTED]
$HTTP_GET_VARS and $HTTP_POST_VARS force us to use illegal HTML. This is because we 
have to add "[]" after a checkbox name if we want to access all values.

Suggested fixes:

1. $HTTP_GET_VARS could return an array.
2. Create environment variables $HTTP_GET/POST which includes the parameters in the 
standard way (like "name=value&name2=value2" etc.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10377&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] Bug #10379: ns-httpd crashes on php content.

[ptierney]

From: [EMAIL PROTECTED]
Operating system: Solaris 7
PHP version:  4.0.4pl1
PHP Bug Type: iPlanet related
Bug description:  ns-httpd crashes on php content.

The configure line:
./configure --with-nsapi=/opt/NetScape/server4 --with-oci8=/oracle/OraHome1 
--prefix=/usr/local/php --mandir=/usr/man --srcdir=/usr/src/php-4.0.4pl1 --with-exec
-dir --enable-track-vars --enable-force-cgi-redirect --enable-discard-path 
--with-config-file-path=/opt/NetScape/server4

Using Iplanet 4.1sp6 on Sun 420R, single proc, 1GB ram

We were seeing large numbers of watchdog restarts, whenever php was enabled, as many 
as 100 in 5 minutes.  After much testing, we started to realize larger php files 
appeared to be causing the problem.  We have been able to create a php file that is 
3812 lines long, that will crash the ns-httpd service _every_ time.  It is too long to 
attach here, but I can email it, once I have an address.  It simply consists of the 
following:
===
bombs.php";
print "";
print "There is a file in this directory called BigBigGame.php";
<*REPEAT ABOVE LINE 3805 TIMES*>
 print "";
 ?>


I am unable to obtain a backtrace, as netscape won't start with debug version.



-- 
Edit Bug report at: http://bugs.php.net/?id=10379&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] Bug #10378: When script timout occurs PHP crashes with ODBC

[martin]

From: [EMAIL PROTECTED]
Operating system: Windows 2000 sp1
PHP version:  4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description:  When script timout occurs PHP crashes with ODBC 

When script timeout occurs (in my case moving data from a textfile to a database, many 
inserts)
PHP prints out the error message (exceeded 300 sec timeout) and then crashes.

The error does not occur if I do a simple while(forewer) so it must be related to open 
connections.

Sorry that I'm unable to find out further whats cousing this.


-- 
Edit Bug report at: http://bugs.php.net/?id=10378&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] Bug #10377: PHP forces illegal HTML

[have]

From: [EMAIL PROTECTED]
Operating system: Any
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  PHP forces illegal HTML

$HTTP_GET_VARS and $HTTP_POST_VARS force us to use illegal HTML. This is because we 
have to add "[]" after a checkbox name if we want to access all values.

Suggested fixes:

1. $HTTP_GET_VARS could return an array.
2. Create environment variables $HTTP_GET/POST which includes the parameters in the 
standard way (like "name=value&name2=value2" etc.


-- 
Edit Bug report at: http://bugs.php.net/?id=10377&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] Bug #10375 Updated: odbc_autocommit with one parameter craches

[kalowsky]

ID: 10375
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproduceable crash
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

fixed in cvs, will not be in 4.0.5, but later releases.

Previous Comments:
---

[2001-04-18 08:23:59] [EMAIL PROTECTED]
Documentation tells me that odbc_autocommit can be called with one or two parameters.
(Without the OnOff parameter, this function returns auto-commit status for 
connection_id. )

Calling with two parameters works, with one I get a crash.

I'm using ODBC 3.520.5303.2 against a Access 2000 database with Access ODBC driver 
4.00.5303.01




---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10375&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] Bug #10376: abnormal program termination on imap_body($box,0)

[akul]

From: [EMAIL PROTECTED]
Operating system: Windows 98 SE
PHP version:  4.0.4pl1
PHP Bug Type: IMAP related
Bug description:  abnormal program termination on imap_body($box,0)

if(!$box=imap_open('{localhost/pop3:110}INBOX','mybox','mypassword'))
die('Can\'t Open box!');

// Here is abnormal program termination
// I think returning of NULL is better solution
// imap_header is Ok (warning is generated)
$B=imap_body($box,0);

imap_close($box);

for PHP.INI see the bug #9819



-- 
Edit Bug report at: http://bugs.php.net/?id=10376&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] Bug #10375: odbc_autocommit with one parameter craches

[martin]

From: [EMAIL PROTECTED]
Operating system: Windows 2000 sp1
PHP version:  4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description:  odbc_autocommit with one parameter craches

Documentation tells me that odbc_autocommit can be called with one or two parameters.
(Without the OnOff parameter, this function returns auto-commit status for 
connection_id. )

Calling with two parameters works, with one I get a crash.

I'm using ODBC 3.520.5303.2 against a Access 2000 database with Access ODBC driver 
4.00.5303.01





-- 
Edit Bug report at: http://bugs.php.net/?id=10375&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: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

On 2001-04-17 21:08:15, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> Any chance you can write a small readme file or add some explanations to 
> the .h file to give people like me a small overview of the abstraction so 
> that it will be easier to start diving into the code?

I've just commited README.STREAMS to the php4 root.

--Wez.


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

On 2001-04-17 22:38:00, "Stig Venaas" <[EMAIL PROTECTED]> wrote:
> To do sockets with different families properly I need to store some
> place what family it is when it's created. So I want all sockets in
> PHP to have an associated datastructure with this and perhaps other
> data in it (this is not needed when the socket is created and destroyed
> inside some low level function).

Although I'm currently using stream->abstract to hold the socketd, there is nothing 
stopping us from holding a pointer to a socket info struct to keep that data.

--Wez.


-- 
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] 4.0.6 and gd 2

[Wez Furlong]

On 2001-04-18 06:43:33, "Kurth Bemis" <[EMAIL PROTECTED]> wrote:
> configure: warning: If configure fails try --with-xpm-dir=
> checking for freetype(2) (needed by gd 2.0+)... no
> ...

> heres my config line
> ./configure --with-mysql=/usr/local/mysql 
> --with-apache=/usr/src/apache_1.3.19 --enable-ftp --with-gd 
> --enable-freetype-4bit-antialias-hack --with-jpeg-dir=/usr/src/jpeg-6b 
> --enable-gd-native-ttf --with-png-dir=/usr/local/lib

Try this instead:

./configure --with-mysql=/usr/local/mysql 
 --with-apache=/usr/src/apache_1.3.19 --enable-ftp --with-gd 
 --with-jpeg-dir=/usr/src/jpeg-6b 
 --with-png-dir=/usr/local/lib
 --with-freetype-dir

This implies --enable-gd-native-ttf, so you don't need to specify it.
There is no such option as --enable-freetype-4bit-antialias-hack (anymore).

> checking whether to include FreeType 1.x support... no - FreeType 2.x is to 
> be used instead

I'm concerned by this message.

If this doesn't work for you, please file a bug report at http://bugs.php.net, and 
email me (personally) your config.log.

--Wez.


-- 
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-CVS] cvs: php4 / TODO-4.1.txt

[Wez Furlong]

On 2001-04-17 21:08:15, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> I haven't had much time to go over it but it looks like it's definitely in 
> the right direction. I've wanted to see something like this in PHP for a while.
> Any chance you can write a small readme file or add some explanations to 
> the .h file to give people like me a small overview of the abstraction so 
> that it will be easier to start diving into the code?

Will do.

--Wez.


-- 
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] 4.0.5 and mcrypt

[Derick Rethans]

On Mon, 16 Apr 2001, Colin Viebrock wrote:

> Just curious whether the work Derick has been doing to fix the mcrypt
> functions is going to make it into 4.0.5?

I just merged them.

Regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands
-


-- 
PHP Development Mailing List 
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: Bug in PHP-4.0.5RC6?

[Derick Rethans]

On Wed, 18 Apr 2001, Derick Rethans wrote:

> I'm merging in the mcrypt fix now. Should be done in 30 mins

I'm too stupid to do it, can anybody give me a pointer, or MFH these fixes
for me? (Version: 1.47 / 1.48)

Regards,

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands
-


-- 
PHP Development Mailing List 
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: Bug in PHP-4.0.5RC6?

[Derick Rethans]

On Wed, 18 Apr 2001, Zeev Suraski wrote:

> RC6 is actually not a branch but a tag, so there's no way to merge anything
> into it (other than moving the tag, which is usually not a good idea).
>
> Anything else pending for 4.0.5?  Otherwise I'll put out RC7 and get this
> release over with...

I'm merging in the mcrypt fix now. Should be done in 30 mins

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands
-


-- 
PHP Development Mailing List 
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: Bug in PHP-4.0.5RC6?

[Zeev Suraski]

RC6 is actually not a branch but a tag, so there's no way to merge anything 
into it (other than moving the tag, which is usually not a good idea).

Anything else pending for 4.0.5?  Otherwise I'll put out RC7 and get this 
release over with...

Zeev

At 11:05 18/4/2001, Derick Rethans wrote:
>On Wed, 18 Apr 2001, Alexander Feldman wrote:
>
> > I fixed the pipes problem and commited the fix in the main branch and in
> > the PHP_4_0_5 one. Should I merge it also in php_4_0_5RC6 as well? This
> > merging/branching always inserts happiness in my life...
>
>The RC6 branch has already released, so it's no use to merge it into this
>branch as well.
>
>Derick
>
>-
> PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
>  SRM: Site Resource Manager - www.vl-srm.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]

--
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: Bug in PHP-4.0.5RC6?

[Derick Rethans]

On Wed, 18 Apr 2001, Alexander Feldman wrote:

> I fixed the pipes problem and commited the fix in the main branch and in
> the PHP_4_0_5 one. Should I merge it also in php_4_0_5RC6 as well? This
> merging/branching always inserts happiness in my life...

The RC6 branch has already released, so it's no use to merge it into this
branch as well.

Derick

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.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]

Re: [PHP-DEV] timezones and thread safety

[Derick Rethans]

Hello,

AFIAK, this was needed because of a bug. I suggest you check it out in the
bug DB.

Derick

On Tue, 17 Apr 2001, James L. Pine wrote:

> ok, this is a little more bizarre than I thought it was.
>
> apparently, tzset is called in mktime or when putenv('TZ=foo') are
> called.  so this works, and putenv'ing TZ isn't thread safe already, but
> should the mktime tzset call be taken out?  and maybe some thread safe
> method of setting a timezone for a page should be put in?
>
>
> --jlp
>
>
> --
> 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]
>

Derick Rethans

-
PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
 SRM: Site Resource Manager - www.vl-srm.net
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands
-


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

[PHP-DEV] Bug #10374: Depreciated features or not

[yohgaki]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.4pl1
PHP Bug Type: Documentation problem
Bug description:  Depreciated features or not

There are features/functions that are depreciated or going to be depreciated.
It is nice to see what is depreciated and is going to be depreciated in the PHP 
Manual. (Although, there is "Migrating from " section. List of them would be nice 
and some of them is not docuemented. There aren't many as far as I know especially 
after 4.0.0.)

I guess depreciated feature/function/etc are not on the manual, but it hard to tell 
w/o document if they are just not documented or depreciated and deleted.

It would be also nice to encourage/discourage use of feature/function/etc for 
current/future release.

Examples are:
 - accessing string as array and modify string as array
 -  (It's in NEWS and user could know it's depreciated, though)
 - set_nonblock()
 - Assoc array index without quote. For example,
$str = "This is $arr[element] and you will NOT see warning with E_ALL and this works";
 - track_vars always on for 4.0.3(It's in NEWS, though)
 - magic_quote = off in php.ini for 4.1?




-- 
Edit Bug report at: http://bugs.php.net/?id=10374&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]