Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend.czend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Stig S. Bakken 

A while ago someone just said that they could not see any more Zend API
changes coming.  I said that moving extensions to PEAR could not happen
until Zend's API either stabilizes, or at least tries to be backwards
compatible.

Obviously this won't be the case for a while yet.  How do you propose
fixing this?  Have people define a macro in their code stating which
version of the API they are using?  As of now there are probably a few
extensions out there that will _only_ build with PHP 4.0.4 to 4.0.6 or
something like that, before which they _only_ built with 4.0.3, and now
they will be updated to require 4.0.7.

 - Stig

Zeev Suraski wrote:
> 
> It should be fairly easy to support both codebases by just defining the
> right things depending on the API_NO.  At any rate, whether we call it 4.1
> or 4.0.7 doesn't really matter.  It had to be done, and would involve the
> same kind of issues regardless of the name.
> 
> Zeev
> 
> At 06:47 02/08/2001, Andrei Zmievski wrote:
> >On Thu, 02 Aug 2001, Andrei Zmievski wrote:
> > > I really wish all these TSRM changes were left for 4.1. There are just
> > > way too many functions affected and I guarantee you that all the
> > > standalone extensions will be broken because people will not expect such
> > > breakage from a point release.
> >
> >Oh, as an example PHP-GTK v0.1 now has to require latest PHP CVS or
> >4.0.7 because of this. Not too good.
> >
> >-Andrei
> >
> >"The only true currency in this bankrupt world is what we share with each
> >other when we're uncool." -- Lester Bangs, from the film 'Almost Famous'
> 
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> 
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

Re: [PHP-DEV] include_path with "."

2001-08-02 Thread Andi Gutmans 

I have already commited a change that if I file isn't found in the 
include_path then PHP will check for the file in the running scripts' cwd.

Andi

At 07:36 AM 8/3/2001 +0200, Stig S. Bakken wrote:
>Hi,
>
>I would like to suggest that we change how "." in the include_path is
>treated to being relative to the file doing an include, instead of
>relative to the main script file.  There was some mention of this a few
>weeks ago, and it's a problem for PEAR users using ISPs that won't let
>them change their include_path.
>
>Objections?
>
>  - Stig
>
>--
>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] faster serializer?

2001-08-02 Thread Stig S. Bakken 

PHP needs a faster serializer and deserializer.  It should be possible
to make one that is at least as fast as Zend compiling and executing
code defining the same structure.

Does anyone else want a faster serializer?  Anyone interested in
contributing to a fund so we can set up a prize for the fastest
implementation? :-)

 - Stig

-- 
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 #12542: CGI Error

2001-08-02 Thread vinoo90 

From: [EMAIL PROTECTED]
Operating system: windows98
PHP version:  4.0.4pl1
PHP Bug Type: *General Issues
Bug description:  CGI Error

As per the manual configaration has bean Done 
when i try to acess first.php 
i get the following Error message .
 

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

i will be happy if any onecan help Me on it .

my mail id [EMAIL PROTECTED]  


-- 
Edit bug report at: http://bugs.php.net/?id=12542&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: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.czend_hash.c zend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Jon Parise 

On Thu, Aug 02, 2001 at 10:50:07AM -0700, Rasmus Lerdorf wrote:

> I would pretty much insist on the _GET() stuff, import_globals() and
> register_globals changes being implemented in 4.1.  With these TSRM
> changes, the register_globals changes and hopefully Sterling's XSLT
> changes I think there is enough new stuff and incompatible changes to
> warrant a 4.1
 
In that case, release 4.1 will be considered both an continuation
of the 4.0.x line as well as a "new" standard for development.
That presupposes there will be no 4.0.x maintenance branch or
future 4.0.x releases.

I'm not objecting.  I just think it's worth pointing out the
ramifications of releasing 4.1 now (well, soon) with these
changes.

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

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

[PHP-DEV] Bug #12531 Updated: undefined symbol: mxdriver

2001-08-02 Thread curtis 

ID: 12531
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: IMAP related
Operating System: RedHat 7.1
PHP Version: 4.0.6
New Comment:

uname -a produces the following:
Linux pisces.maurand.com 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown

Syntax error on line 201 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/
libexec/libphp4.so: undefined symbol: mxdriver
/usr/local/apache/bin/apachectl start: httpd could not be started


Previous Comments:


[2001-08-02 16:48:26] [EMAIL PROTECTED]

I'm still unable to reproduce this, even with the
EXACT same rpms you are using. 

--Jani




[2001-08-02 16:14:15] [EMAIL PROTECTED]

what errors exactly are you getting?



[2001-08-02 15:22:03] [EMAIL PROTECTED]

I got them from:

ftp://sunsite.unc.edu/pub/distributions/redhat/updates/7.1/en/os/i386

the src rpm comes from

ftp://sunsite.unc.edu/pub/distributions/redhat/updates/7.1/en/os/SRPMS

However, when you don't call out a directory for imap during configure, PHP
will use its own extensions.  It doesn't matter.  any imap support and I get
undefigned symbol: mxdriver.

I've downloaded the source tarball from UW and I've compiled it.   I have
not had a chance to run a make clean and reconfigured from the PHP directory
yet.  Its still not supposed to be this hard.





[2001-08-02 15:13:50] [EMAIL PROTECTED]

I got them from:

ftp://sunsite.unc.edu/pub/distributions/redhat/updates/7.1/en/os/i386

the src rpm comes from

ftp://sunsite.unc.edu/pub/distributions/redhat/updates/7.1/en/os/SRPMS

However, when you don't call out a directory for imap during configure, PHP
will use its own extensions.  It doesn't matter.  any imap support and I get
undefigned symbol: mxdriver.

I've downloaded the source tarball from UW and I've compiled it.   I have
not had a chance to run a make clean and reconfigured from the PHP directory
yet.  Its still not supposed to be this hard.





[2001-08-02 12:28:32] [EMAIL PROTECTED]

I just tried this with RH 7.1:

1. Installed imap-* rpms from RedHat distribution
2. Installed apache 1.3.20 with DSO support
3. Got the 4.0.6 sources and did these steps:

# tar zxfv php-4.0.6.tar.gz
# cd php-4.0.6
# ./configure \
--prefix=/www/apache \
--with-apxs=/www/apache/bin/apxs \ --with-mysql=/usr/local/mysql \
--with-zlib \
--with-imap \
--with-imap-ssl=/usr \
--with-kerberos \
--with-openssl

# make ; make install
# /www/apache/bin/apachectl start

And no problems at all..so my next question is:

WHERE did you get those imap-rpms from??

--Jani




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=12531


Edit this bug report at http://bugs.php.net/?id=12531&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: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.czend_hash.czend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Rasmus Lerdorf 

> Zeev Suraski wrote:
> > - For the register_globals default change, I believe a major
> >   version bump is a very good idea, as it's exactly the kind of
> >   heads-up message we want to send to all of the users.
>
>   Why not combine the two for a 4.1 release? How much work would be
> required to do the register_globals default change now?

I would pretty much insist on the _GET() stuff, import_globals() and
register_globals changes being implemented in 4.1.  With these TSRM
changes, the register_globals changes and hopefully Sterling's XSLT
changes I think there is enough new stuff and incompatible changes to
warrant a 4.1

-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] Bug #12531 Updated: undefined symbol: mxdriver

2001-08-02 Thread curtis 

ID: 12531
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating System: RedHat 7.1
PHP Version: 4.0.6
New Comment:

One more thing.  The RedHat php-imap package works.  However, it does not have gd 
support which is the first thing that I'm after even before I work on the webmail 
project that needs to get done.

Previous Comments:


[2001-08-02 22:07:00] [EMAIL PROTECTED]

 A little further information.  This was a stock RedHat 7.0 install that I upgraded to 
7.1.  I've tried compiling PHP against the stock redhat distribution of apache and now 
the 1.3.20 source that i downloaded.  

Apache compiled fine and it runs with PHP4 compiled without imap support.

I've installed most of the updates that are available at your favorite mirror site 
including glibc updates.  

The hardware is a K6II-233 IDE drive system with a 3Com 3c905 and 128MB of RAM.  Its a 
workhorse machine and just gets it done.  Its been very stable and hasn't burped while 
I've been playing around with all of this.  I've also got the server running on Port 
8000.  That said, I had the same problem with the stock apache and it runs on port 80.

Hope this is helpful.  If you need more details, ask.






[2001-08-02 21:57:35] [EMAIL PROTECTED]

uname -a produces the following:
Linux pisces.maurand.com 2.4.2-2 #1 Sun Apr 8 19:37:14 EDT 2001 i586 unknown

Syntax error on line 201 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/
libexec/libphp4.so: undefined symbol: mxdriver
/usr/local/apache/bin/apachectl start: httpd could not be started




[2001-08-02 16:48:26] [EMAIL PROTECTED]

I'm still unable to reproduce this, even with the
EXACT same rpms you are using. 

--Jani




[2001-08-02 16:14:15] [EMAIL PROTECTED]

what errors exactly are you getting?



[2001-08-02 15:22:03] [EMAIL PROTECTED]

I got them from:

ftp://sunsite.unc.edu/pub/distributions/redhat/updates/7.1/en/os/i386

the src rpm comes from

ftp://sunsite.unc.edu/pub/distributions/redhat/updates/7.1/en/os/SRPMS

However, when you don't call out a directory for imap during configure, PHP
will use its own extensions.  It doesn't matter.  any imap support and I get
undefigned symbol: mxdriver.

I've downloaded the source tarball from UW and I've compiled it.   I have
not had a chance to run a make clean and reconfigured from the PHP directory
yet.  Its still not supposed to be this hard.





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=12531


Edit this bug report at http://bugs.php.net/?id=12531&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 #11846 Updated: AL EJECUTAR MAKE MARCA ERROR

2001-08-02 Thread andy 

ID: 11846
Updated by: andy
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Compile Failure
Operating System: NCR WM 4300 unix systema V MP-RA
PHP Version: 4.0.6
New Comment:

no user feedback.

Previous Comments:


[2001-07-03 16:38:43] [EMAIL PROTECTED]

Input from the MySQL team:

The MySQL code does assume that INT_MAX and INT_MIN are defined
somewhere.  We include  if it is found, and it should
have those macros defined in it.

It may be a communication problem between the PHP configure and
the MySQL code; if for some reason HAVE_LIMITS_H is not being
defined, then we won't include .  But it looks like
PHP is using HAVE_LIMITS_H in several places itself, so that
shouldn't be the case.  Also, INT_MAX is used in the pcrelib and
oci8 extensions, so I don't think it's strictly a MySQL issue.

It looks like maybe the user's limits.h is defective.  Or maybe
the compiler is not installed correctly, or something.  It would
be up to the user, I think, to track down what happened to
INT_MAX on his system.  I suppose we could add a test for it in
our config stuff, but I really think that's the wrong fix.

Tim



Can you take a look at your limits.h file?

Derick



[2001-07-03 09:44:42] [EMAIL PROTECTED]

again error in other lines
command compile

$./configure --with-informix=yes --with-apache=/admvos/apache/apache_1.3.19 
--enable-sysvsem --enable-sysvshm --without-mysql
   LAST LINES 
cc  -I. -I/admvos/sistgczo/php-4.0.6/ext/posix 
-I/admvos/sistgczo/php-4.0.6/main -I/admvos/sistgczo/php-4.0.6 
-I/admvos/apache/apache_1.3.19/src/include -I/admvos/apache/apache_1.3.19/src/os/unix 
-I/admvos/sistgczo/php-4.0.6/Zend -I/usr/informix/incl/esql 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmltok 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmlparse -I/admvos/sistgczo/php-4.0.6/TSRM  
-DSUPPORT_UTF8 -DXML_BYTE_ORDER=12   -c posix.c && touch posix.lo
NCR High Performance C Compiler R3.0c
(c) Copyright 1994-97, NCR Corporation
(c) Copyright 1987-97, MetaWare Incorporated
w "/admvos/sistgczo/php-4.0.6/Zend/zend_execute.h",L185/C5(#257):   '=' 
encountered where '==' may have been intended.
w "/admvos/sistgczo/php-4.0.6/Zend/zend_execute.h",L198/C4(#257):   '=' 
encountered where '==' may have been intended.
w "/admvos/sistgczo/php-4.0.6/ext/standard/php_string.h",L125/C5(#257): '=' 
encountered where '==' may have been intended.
E "posix.c",L357/C17(#237): NGROUPS_MAX: Identifier is undeclared.
E "posix.c",L357/C9(#445):  gidlist
|Type of variable is an array of zero length.
E "posix.c",L361/C21(#237): NGROUPS_MAX: Identifier is undeclared.
w (#657):   (info) How referenced files were included:
|File /admvos/sistgczo/php-4.0.6/Zend/zend_execute.h from 
|/admvos/sistgczo/php-4.0.6/Zend/zend_API.h from /admvos/sistgczo/php-4.0.6/main/php.h 
|from posix.c.
|File /admvos/sistgczo/php-4.0.6/ext/standard/php_string.h from posix.c.
3 user errors   4 warnings
*** Error code 3 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.
*** Error code 1 (bu21)

make: fatal error.

THANKS...



[2001-07-03 02:53:35] [EMAIL PROTECTED]

For now you can disable the use of MySQL by adding --withot-mysql to your configire 
line.

./configure --with-informix=yes --with-apache=/admvos/apache/apache_1.3.19
--enable-sysvsem --enable-sysvshm --without-mysql

I reported this to the MySQL folks, as



[2001-07-02 17:43:58] [EMAIL PROTECTED]

THE VERSION installed version at the moment is 3.0.18 without problem. 
not compile with mysql, use to informix database
the procedure is
1.- 
$ cd apache_1.3.19
$ ./configure  # OK NO ERROR
$ cd ../php4.0.6
$ cd php-4.0.6
$ ./configure --with-informix=yes --with-apache=/admvos/apache/apache_1.3.19 
--enable-sysvsem --enable -sysvshm# OK NO ERROR
$ make 
Making all in libmysql
cc  -I. -I/admvos/sistgczo/php-4.0.6/ext/mysql/libmysql 
-I/admvos/sistgczo/php-4.0.6/main -I/admvos/sistgczo/php-4.0.6 
-I/admvos/apache/apache_1.3.19/src/include -I/admvos/apache/apache_1.3.19/src/os/unix 
-I/admvos/sistgczo/php-4.0.6/Zend -I/usr/informix/incl/esql 
-I/admvos/sistgczo/php-4.0.6/ext/mysql/libmysql 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmltok 
-I/admvos/sistgczo/php-4.0.6/ext/xml/expat/xmlparse -I/admvos/sistgczo/php-4.0.6/TSRM  
-DSUPPORT_UTF8 -DXML_BYTE_ORDER=12   -c my_init.c && touch my_init.lo
NCR High Performance C Compiler R3.0c
(c) Copyright 1994-97, NCR Corporation
(c) Copyright 1987-97, MetaWare Incorporated
E "my_init.c",L44/C7(#237): INT_MAX: Identifier is und

Re: [PHP-DEV] Re: Patch for ext/standard/[basic_functions.c|php_math.h|math.c]

2001-08-02 Thread Jesus M. Castagnetto 


--- "Stig S. Bakken" <[EMAIL PROTECTED]> wrote:
[...big snip...]
> If we add a "log" function, does anyone want to
> guess how many scripts
> will break because of it? :-)

Hmm, we have had a natural logarithm function (log)
since back in PHP3, in fact the availability of those
functions is what make me transition from w3-msql
(yeah, I know) to PHP for when I use MiniSQL.

I do not follow the "... many scripts will break bit
..."

> Namespaces would have been nice now, "import log
> from Math;"

Sure, that is what I am dreaming about, something
like:

import Matrix from GSL;

Cheers.

=
--- Jesus M. Castagnetto <[EMAIL PROTECTED]>

__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.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: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Zeev Suraski 

Binary compatibility was broken long ago in 4.0.7.

At 07:09 02/08/2001, [EMAIL PROTECTED] wrote:
> > On Thu, 02 Aug 2001, Zeev Suraski wrote:
> > > zeevThu Aug  2 09:16:20 2001 EDT
> > >
> > >   Modified files:
> > > /Zend   zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c
> > > zend_list.h
> > >   Log:
> > >   Some cleanup
> >
> > I really wish all these TSRM changes were left for 4.1. There are just
> > way too many functions affected and I guarantee you that all the
> > standalone extensions will be broken because people will not expect such
> > breakage from a point release.
>
>It also breaks binary compatibility forcing everyone to release new
>extensions.  The change from
>
>ZEND_API void wrong_param_count()
>
>to
>
>ZEND_API void zend_wrong_param_count(TSRMLS_D)
>
>Makes extensions built for 4.0.6 break against current CVS right now:
>
>PHP Warning:  Unable to load dynamic library
>'/usr/local/lib/php/php_ming.so' - /usr/local/lib/php/php_ming.so:
>undefined symbol: wrong_param_count in Unknown on line 0
>
>-Rasmus

--
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: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Zeev Suraski 

The work which will have to be done is the author, not all of the 
users.  So the 10K number is not all that relevant.

At 10:50 02/08/2001, George Schlossnagle wrote:

> > Yes, I was counting those too...  It's still not a very large number
> > (probably in the range of dozens, or hundreds at the most, compared to
> > hundreds of thousands of users).
>
>Conservative estimates put the APC user community at just below 10,000
>people.  I'm sure it's not the most popular 3rd party php extension out
>there.
>
> >
> > Both binary and source compatibility will have good warnings for
>developers
> > and users (binaries will not load, source will not compile...), so there
> > should be no real obscure-crashes type of problems.
>
>I don't think the obscurity of the crash was at issue, just that a minor
>version bump-up would break an end-users install at all.
>
> >
> > I don't know, it seems to me that bumping a version number because of an
> > API change which is transparent to end users is a bit odd, but if most
> > people think otherwise, it's very much possible...
> >
> > Zeev
> >

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


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

Re: [PHP-DEV] Re: gmp_init with a base argument

2001-08-02 Thread Stanislav Malyshev 

TA>> Does the lack of comments mean that I may commit the patch? (I think
TA>> that I still have CVS access.)

I was pretty busy last week, sorry, so I couldn't look at it thoroughly.
But on the quick glance your patch looks OK.

TA>> By the way:
TA>> I think that the decbin() function should bail out if you pass it a
TA>> value which contains more bits than PHP is able to handle. - Perhaps
TA>> with a hint about using GMP for large numbers.

I'd say "give a warning" istead of "bail out", but that's a good idea,
generally.

-- 
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED]  http://www.zend.com/ +972-3-6139665 ext.115




-- 
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: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.czend_hash.czend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Sterling Hughes 

On Thu, 2 Aug 2001, Rasmus Lerdorf wrote:

> > Zeev Suraski wrote:
> > > - For the register_globals default change, I believe a major
> > >   version bump is a very good idea, as it's exactly the kind of
> > >   heads-up message we want to send to all of the users.
> >
> >   Why not combine the two for a 4.1 release? How much work would be
> > required to do the register_globals default change now?
>
> I would pretty much insist on the _GET() stuff, import_globals() and
> register_globals changes being implemented in 4.1.  With these TSRM
> changes, the register_globals changes and hopefully Sterling's XSLT
> changes I think there is enough new stuff and incompatible changes to
> warrant a 4.1
>
XSLT is working for me now... ;)

it really only needs a bunch of testing and some backends to be
implemented (to my knowledge someone is already working on libxslt
and Xalan backends).

-Sterling




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

[PHP-DEV] Bug #12537: tiwizi

2001-08-02 Thread tiwizi 

From: [EMAIL PROTECTED]
Operating system: win98
PHP version:  4,0,6
PHP Bug Type: Performance problem
Bug description:  tiwizi


MISTER


lorse that I clic with the right button of smiles on the racourci EasyPhp
which on my bar of state I obtien: 
Fichier Log:  > erreur Apach > Ereur MySql

Is what it is normal?


THANK YOU


-- 
Edit bug report at: http://bugs.php.net/?id=12537&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 #12426 Updated: Critical PHP bug while processing big POST data (>10K)

2001-08-02 Thread dk 

ID: 12426
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: HTTP related
Operating System: RedHat Linux 7.0 2.2.16-22smp
PHP Version: 4.0.6
New Comment:

Well, some days ago I had tried to patch PHP myself. No result :-( I have found that 
PHP does not get POST data larger than about 4000 bytes (3996). There is a constant in 
SAPI.h:

#define SAPI_POST_BLOCK_SIZE 4000

I understand that this constant explains the block size, which is used by PHP to read 
data from stdin in function:

SAPI_POST_READER_FUNC(sapi_read_standard_form_data)
in SAPI.c.

It is very VERY weird, but when I set SAPI_POST_BLOCK_SIZE to, for example, 1, 
POST data is cutted by 4000 bytes again (not 1, as I expected)! It looks like 
there is no bug in block-oriented algorythm of POST reading, but then why 4000?..

PS:
you think that it is HTTP-related bug? I don't think so: PHP3 works correctly...

Previous Comments:


[2001-07-27 10:57:49] [EMAIL PROTECTED]

I have configured PHP4 to process POST data less than 800 (phpinfo() reports that, 
see below). When I use the following script and enter a large block of text in the 
form, PHP4 cuts it off. Please test

http://www.dklab.ru/test.php (with phpinfo() call, form at the bottom of the file)
http://dklab.ru/content.txt (the file I am inserting - please test it)

Here is the script:










I have encountered that use of multipart/form-data forms solves this problem, but 
usual POST forms does not work correctly. PHP3 also work correct with such forms.





Edit this bug report at http://bugs.php.net/?id=12426&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: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.czend_hash.czend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Rasmus Lerdorf 

Yes, this wouldn't be a new branch, just the next version.

On Thu, 2 Aug 2001, Jon Parise wrote:

> On Thu, Aug 02, 2001 at 10:50:07AM -0700, Rasmus Lerdorf wrote:
>
> > I would pretty much insist on the _GET() stuff, import_globals() and
> > register_globals changes being implemented in 4.1.  With these TSRM
> > changes, the register_globals changes and hopefully Sterling's XSLT
> > changes I think there is enough new stuff and incompatible changes to
> > warrant a 4.1
>
> In that case, release 4.1 will be considered both an continuation
> of the 4.0.x line as well as a "new" standard for development.
> That presupposes there will be no 4.0.x maintenance branch or
> future 4.0.x releases.
>
> I'm not objecting.  I just think it's worth pointing out the
> ramifications of releasing 4.1 now (well, soon) with these
> changes.
>
>


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

2001-08-02 Thread Thies C. Arntzen 

On Thu, Aug 02, 2001 at 12:24:03PM -0400, George Schlossnagle
wrote:
> On a related note, placing null-bytes in the middle of strings
> (for example
> in the names of the so-called lambda_functions generated from
> create_function()) seems like a pretty questionable practice.

why, this makes sure that function-names generated by
create_function() will never clash with userland code.
i think that makes perfect sense.

tc

-- 
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 #12536 Updated: fread does not look to be working right

2001-08-02 Thread sniper 

ID: 12536
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Performance problem
Operating System: win 98 box
PHP Version: 4.0.4pl1
New Comment:

Have you tried with PHP 4.0.6? And could you also 
add a short example script into this bug report?

--Jani


Previous Comments:


[2001-08-02 17:34:06] [EMAIL PROTECTED]

fread does not look like it is reading the EOF. when i use a large (HUDGE) number to 
tell the fread() how many characters to read, it takes a  l o n g time for this to 
complete this happens even when the file is very short.

i descoverd this when i was trying to read an entire file into a string. is fread the 
best way to do this?? it does not seem to be working very well.

there is also a error reporting problem with fread. after the same number gets too 
big, php stops processing the entire page, (it does check syntax)
there is als no error message when this happens.

Knight





Edit this bug report at http://bugs.php.net/?id=12536&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 #12534: Fatal Error: No definition for inline function: scan_set_error_return

2001-08-02 Thread dkleinh 

From: [EMAIL PROTECTED]
Operating system: Compaq Tru64 UNIX 5.1 patch 3
PHP version:  4.0.6
PHP Bug Type: Compile Failure
Bug description:  Fatal Error: No definition for inline function: scan_set_error_return

cc  -I. -I/usr/local/src/php-4.0.6/ext/standard
-I/usr/local/src/php-4.0.6/main -I/usr/local/src/php-4.0.6
-I/usr/local/src/apache_1.3.19/src/include
-I/usr/local/src/apache_1.3.19/src/os/unix -I/usr/local/src/php-4.0.6/Zend
-I/usr/local/src/imap-2001.BETA.SNAP-0107221451/c-client
-I/usr/local/mysql/include/mysql
-I/usr/local/src/php-4.0.6/ext/xml/expat/xmltok
-I/usr/local/src/php-4.0.6/ext/xml/expat/xmlparse
-I/usr/local/src/php-4.0.6/TSRM  -DSUPPORT_UTF8 -DXML_BYTE_ORDER=12 -O4
-ansi_alias -inline speed -arch host  -c file.c && touch file.lo
cc: Error: scanf.h, line 48: There is no definition for the inline function
named scan_set_error_return in this compilation unit. (noinlfunc)
inline void scan_set_error_return(int numVars,pval **return_value);
^
make[3]: *** [file.lo] Error 1
make[3]: Leaving directory `/usr/local/src/php-4.0.6/ext/standard'
make[2]: *** [all-recursive] Error 1
# uname -a
OSF1 lehrer V5.1 732 alpha
# cc -V
Compaq C V6.3-025 on Compaq Tru64 UNIX V5.1 (Rev. 732)
Compiler Driver V6.3-026 (sys) cc Driver

-- 
Edit bug report at: http://bugs.php.net/?id=12534&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: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.czend_hash.c zend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Zeev Suraski 

The register_globals change must go through one iteration where we have the 
new APIs available, but still haven't changed the default.  So, we can't 
combine these two changes together...

Zeev

At 10:41 02/08/2001, Sebastian Bergmann wrote:
>Zeev Suraski wrote:
> > - For the register_globals default change, I believe a major
> >   version bump is a very good idea, as it's exactly the kind of
> >   heads-up message we want to send to all of the users.
>
>   Why not combine the two for a 4.1 release? How much work would be
>required to do the register_globals default change now?
>
>--
>   Sebastian Bergmann Measure Traffic & Usability
>   http://sebastian-bergmann.de/http://phpOpenTracker.de/

--
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: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Zeev Suraski 

At 10:40 02/08/2001, Jani Taskinen wrote:
>True. So you're saying that the people who write extensions should also
>be following [EMAIL PROTECTED] to know about any major changes?

I guess most of them are;  Those who aren't will bump into these issues as 
soon as they try to upgrade.  It's not something that'll bite them at runtime.

> >- For the register_globals default change, I believe a major version bump
> >is a very good idea, as it's exactly the kind of heads-up message we want
> >to send to all of the users.
>
>Of course. btw. When do we get the nice, short names for the HTTP_*_VARS?

Sometime soon :)

Zeev


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

Re: [PHP-DEV] Re: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Zeev Suraski 

It should be fairly easy to support both codebases by just defining the 
right things depending on the API_NO.  At any rate, whether we call it 4.1 
or 4.0.7 doesn't really matter.  It had to be done, and would involve the 
same kind of issues regardless of the name.

Zeev

At 06:47 02/08/2001, Andrei Zmievski wrote:
>On Thu, 02 Aug 2001, Andrei Zmievski wrote:
> > I really wish all these TSRM changes were left for 4.1. There are just
> > way too many functions affected and I guarantee you that all the
> > standalone extensions will be broken because people will not expect such
> > breakage from a point release.
>
>Oh, as an example PHP-GTK v0.1 now has to require latest PHP CVS or
>4.0.7 because of this. Not too good.
>
>-Andrei
>
>"The only true currency in this bankrupt world is what we share with each
>other when we're uncool." -- Lester Bangs, from the film 'Almost Famous'

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


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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / configure.in

2001-08-02 Thread Andrei Zmievski 

On Thu, 02 Aug 2001, Jani Taskinen wrote:
> Some things seem to be tested many times in same configure run.

I would be against removing config.cache on every configure run. Many
people configure PHP multiple times a day during development and this
slows it down. We should rather see what problems caching presents us
with and try to resolve them.

-Andrei

If you find a job that you love, you'll
never work another day in your life.
 - Mark Jackson

-- 
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: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.czend_hash.c zend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Jani Taskinen 


It's time to break the evil spell on the middle number.
IMO, it does really matter if it is 4.1.0 or 4.0.7..
It's the "HEADS UP!" for people when you change the more significant
version number.

(and also gives a nice backdoor for breaking bc without wtf-factor :)

If someone is afraid of changing it, I can volunteer. ;)

Another thing, I get a segfault when php is configured like this:
./configure --with-crack=/usr/src/cracklib.2.7 --enable-experimental-zts

--Jani

p.s. Zeev, you're only idling on IRC nowadays?


On Thu, 2 Aug 2001, Zeev Suraski wrote:

>It should be fairly easy to support both codebases by just defining the
>right things depending on the API_NO.  At any rate, whether we call it 4.1
>or 4.0.7 doesn't really matter.  It had to be done, and would involve the
>same kind of issues regardless of the name.
>
>Zeev
>
>At 06:47 02/08/2001, Andrei Zmievski wrote:
>>On Thu, 02 Aug 2001, Andrei Zmievski wrote:
>> > I really wish all these TSRM changes were left for 4.1. There are just
>> > way too many functions affected and I guarantee you that all the
>> > standalone extensions will be broken because people will not expect such
>> > breakage from a point release.
>>
>>Oh, as an example PHP-GTK v0.1 now has to require latest PHP CVS or
>>4.0.7 because of this. Not too good.
>>
>>-Andrei
>>
>>"The only true currency in this bankrupt world is what we share with each
>>other when we're uncool." -- Lester Bangs, from the film 'Almost Famous'
>
>--
>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 #11935 Updated: php 4.0.6 doesn't work with solid option

2001-08-02 Thread kalowsky 

ID: 11935
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: ODBC related
Operating System: Linux RedHat 6.2
PHP Version: 4.0.6
New Comment:

no user feedback.  if this bug still exists, please reopen 
the bug.

Previous Comments:


[2001-07-09 12:03:37] [EMAIL PROTECTED]

and what does it stop saying?

the other thing to note, if this is with solid 3.5, you need the latest libraries from 
SolidTech for it to work properly.



[2001-07-06 12:10:37] [EMAIL PROTECTED]

can you please provide more information?

what doesn't work?  and do please try 4.0.5, or even 4.0.6 as there have been changes 
for SOLID in both versions.



[2001-07-06 11:42:21] [EMAIL PROTECTED]

I've install php 4.0.4, but apache doesn't start with solid option "--with-solid=[dir]"





Edit this bug report at http://bugs.php.net/?id=11935&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] Re: [ZEND-ENGINE] cvs: Zend / zend.c zend_execute_API.c zend_hash.c zend_hash.h zend_list.c zend_list.h

2001-08-02 Thread Zeev Suraski 

At 09:05 02/08/2001, Andrei Zmievski wrote:
>On Thu, 02 Aug 2001, Zeev Suraski wrote:
> > It's only going to affect the TS build, so most extensions will be left
> > unharmed.  At any rate, leaving stuff for 4.1 has always been a way of
> > saying 'maniana' in our group...  As far as I'm concerned, we can just
> > release the current code base as 4.1.
>
>No, I had to adjust a number of things in PHP-GTK after your changes,
>even in non-TS build.

Can you elaborate?
One thing that may make sense is keeping the old FETCH macros as 
no-ops.  Other than that, it should pretty much build fine.

Zeev


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

[PHP-DEV] Bug #12528: array_unique function changed

2001-08-02 Thread jinn 

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0.6
PHP Bug Type: Arrays related
Bug description:  array_unique function changed

My ISP recently upgraded from 4.0.3pl1 to 4.0.6 - i have a script that runs
an 'array_unique' on a 2d array.  This used to work previously, but now it
reduces the array down to a single item.

Here is the section of script:
// CLEAN UP DUPLICATES THAT DON'T HAVE THE DESCRIPTION, BUT ARE THE SAME
SECTION
if ( $debug ) echo "CLEAN UP DUPLICATE
SECTIONS
   
 [\$idx,\$count]...";
$count = 0;
for ( $idx = 0; $idx < count($section_result); ++$idx 
) {
$comp1 = strtolower($section_result[$idx][0]);
$comp2 = 
strtolower($section_result[$idx+1][0]);
$comp3 = 
strtolower($section_result[$idx-1][0]);

if ( $comp1 == $comp2 ) {
// IF THIS ENTRY IS THE SAME SECTION AS THE 
NEXT ONE
if ( $section_result[$idx+1][1] != '' 
) {
$section[$count][0] = 
$section_result[$idx+1][0];
$section[$count][1] = 
$section_result[$idx+1][1];
++$count;
} elseif ( $section_result[$idx][1] != 
'' ) {
$section[$count][0] = 
$section_result[$idx][0];
$section[$count][1] = 
$section_result[$idx][1];
++$count;
}
} elseif ( $comp1 != $comp3 ) {
$section[$count][0] = 
$section_result[$idx][0];
$section[$count][1] = 
$section_result[$idx][1];
++$count;
}
if ( $debug ) echo "[$idx,$count] " . 
$section[$count-1][0] . " -- " .
$section[$count-1][1] . "";
} // close for

if ( $debug ) echo "";

$section = array_unique($section);

if ( $debug ) {
echo "UNIQUE 
SECTIONS AFTER
CLEAN-UP";
echo "section count: " . count($section) . " | 
$count";
echo "Work it thru a 'for' loop:";
for ( $idx = 0; $idx < $count; ++$idx ) {
echo $section[$idx][0] . " -- " . 
$section[$idx][1] . "";
}
echo "Work it thru a 'foreach' 
loop:";
foreach ( $section as $message ) {
echo $message[0] . " -- " . 
$message[1] . "";
}
echo "";
echo "UNIQUE 
SECTION_RESULT AFTER
CLEAN-UP";
foreach ( $section_result as $message ) {
echo $message[0] . " -- " . 
$message[1] . "";
}
echo "";
}
-- 
Edit bug report at: http://bugs.php.net/?id=12528&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] [PATCH] Zend/zend_alloc.c

2001-08-02 Thread Walter Franzini 

--- php-4.0.6.ORIG/Zend/zend_alloc.c	Tue Jun 19 20:04:53 2001
+++ php-4.0.6/Zend/zend_alloc.c	Tue Jul 31 10:32:39 2001
@@ -158,12 +158,11 @@
 	HANDLE_BLOCK_INTERRUPTIONS();
 
 	if (!p) {
-		fprintf(stderr,"FATAL:  emalloc():  Unable to allocate %ld bytes\n", (long) size);
+		fprintf(stderr,"FATAL:  emalloc():  Unable to allocate %lu bytes\n", (long unsigned) size);
 #if ZEND_DEBUG && defined(HAVE_KILL) && defined(HAVE_GETPID)
 		kill(getpid(), SIGSEGV);
-#else
-		exit(1);
 #endif
+
 		HANDLE_UNBLOCK_INTERRUPTIONS();
 		return (void *)p;
 	}



-- 
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] [PATCH] 2 patch for ext/odbc/php_odbc.c

2001-08-02 Thread Walter Franzini 

Only in php-4.0.6.ORIG/Zend: zend_alloc.2.c
Only in php-4.0.6.ORIG/Zend: zend_alloc.2.c~
Only in php-4.0.6.ORIG/: cgi_build
Only in php-4.0.6.ORIG/ext/bcmath: number.c
Only in php-4.0.6.ORIG/ext/bcmath: number.h
diff -ur php-4.0.6.ORIG/ext/odbc/php_odbc.c php-4.0.6/ext/odbc/php_odbc.c
--- php-4.0.6.ORIG/ext/odbc/php_odbc.c	Tue Jun 19 19:55:00 2001
+++ php-4.0.6/ext/odbc/php_odbc.c	Thu Aug  2 09:13:00 2001
@@ -565,6 +565,7 @@
 {
 	RETCODE rc;
 int i;
+	long _size=0;
 SWORD   colnamelen; /* Not used */
 	SDWORD  displaysize;
 	ODBCLS_FETCH();
@@ -610,11 +611,18 @@
 break;
 #endif /* HAVE_ADABAS */
 			default:
+_size = result->longreadlen;
 rc = SQLColAttributes(result->stmt, (UWORD)(i+1), SQL_COLUMN_DISPLAY_SIZE,
 	NULL, 0, NULL, &displaysize);
-result->values[i].value = (char *)emalloc(displaysize + 1);
-rc = SQLBindCol(result->stmt, (UWORD)(i+1), SQL_C_CHAR, result->values[i].value,
-			displaysize + 1, &result->values[i].vallen);
+_size = (_size <= displaysize ? _size : displaysize);
+result->values[i].value = (char *)emalloc(_size + 1);
+if (result->values[i].value) {
+rc = SQLBindCol(result->stmt, (UWORD)(i+1), SQL_C_CHAR, 
+result->values[i].value, _size + 1,
+&result->values[i].vallen);
+} else {
+return 0;
+}
 break;
 		}
 }
Only in php-4.0.6/ext/odbc: php_odbc.c~
Only in php-4.0.6.ORIG/: mod_build


--- php-4.0.6.ORIG/ext/odbc/php_odbc.c	Tue Jun 19 19:55:00 2001
+++ php-4.0.6/ext/odbc/php_odbc.c	Mon Jul 30 12:31:33 2001
@@ -363,7 +363,7 @@
 	le_pconn = zend_register_list_destructors_ex(NULL, _close_odbc_pconn, "odbc link persistent", module_number);
 	odbc_module_entry.type = type;
 	
-	REGISTER_STRING_CONSTANT("ODBC_TYPE", PHP_ODBC_TYPE, CONST_CS | CONST_PERSISTENT);
+	REGISTER_STRING_CONSTANT("ODBC_TYPE", estrdup (PHP_ODBC_TYPE), CONST_CS | CONST_PERSISTENT);
 	REGISTER_LONG_CONSTANT("ODBC_BINMODE_PASSTHRU", 0, CONST_CS | CONST_PERSISTENT);
 	REGISTER_LONG_CONSTANT("ODBC_BINMODE_RETURN", 1, CONST_CS | CONST_PERSISTENT);
 	REGISTER_LONG_CONSTANT("ODBC_BINMODE_CONVERT", 2, CONST_CS | CONST_PERSISTENT);



-- 
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 #11649 Updated: Unable to Fork errors

2001-08-02 Thread dbeu 

ID: 11649
Updated by: dbeu
Reported By: [EMAIL PROTECTED]
Old Status: Duplicate
Status: Closed
Bug Type: Program Execution
Operating System: Win98
PHP Version: 4.0.6


Previous Comments:


[2001-07-23 11:44:32] [EMAIL PROTECTED]

did this work with derick's suggestion?



[2001-06-25 05:35:09] [EMAIL PROTECTED]

Try it with the full path to the executable, like this:
exec ("c:\windows\playmp3.exe test.mp3");



[2001-06-25 03:56:26] [EMAIL PROTECTED]

According to the ChangeLog, the inablity to fork issue in the exec family has been 
fixed on Win32 in 4.0.6.  Unfortunately, this is not so.  Calling system(), exec(), or 
passthru() produces the following error msg:

Warning: Unable to fork [test.mp3] in exec.php at line 3

Calling escapeshellcmd() or escapeshellarg() does not give an error or warning 
message, but also does not execute the command.  The above mentions problems occur 
when the functions are called when running PHP as an Apache module, or by executing 
the script from command line.  Below is a description of my setup, please let me know 
if additional information is needed.

OS: Win98 - SE
Processor: AMD K6-2/350
RAM: 192 megs
Apache version: 1.3.20 (run as service)
PHP: 4.0.6 and 4.0.5 (with Zend Optimizer)
Enabled PHP extensions: php_bz2.dll, php_gd.dll, php_imap.dll, php_zlib.dll
Output Buffering: On
PHP-GTK: version 0.0.4





Edit this bug report at http://bugs.php.net/?id=11649&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 #12485 Updated: Exec() doesn't work

2001-08-02 Thread dbeu 

ID: 12485
Updated by: dbeu
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Closed
Bug Type: Program Execution
Operating System: windows 2000
PHP Version: 4.0.6
New Comment:

this issue has already been fixed in cvs, look for exisiting bug reports before 
submitting new!
"dir" isn't a real command, however this is fixed in cvs quite a while ago.
snaps.php.net

Previous Comments:


[2001-08-01 20:23:53] [EMAIL PROTECTED]

Confirmed under Windows 98 w/ PHP 4.0.6



[2001-08-01 19:33:31] [EMAIL PROTECTED]

User comment (gebruik aub het web-formulier):
-
Yes sorry for not mentioning it before:

Something like "cannot fork [dir]"

Regards,

Max
-



[2001-07-31 08:45:10] [EMAIL PROTECTED]

any error messages?



[2001-07-31 08:43:15] [EMAIL PROTECTED]

Exec doesnt work in 4.0.6 in cgi mode.
Installed 4.0.5 now and it is ok.





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