[PHP-DEV] Documentation for How to write php extensions

[Shao Zhang]

Hi,

Where can I find the latest documentation on how to write php extensions? The only
documentation I found is: http://www.zend.com/zend/api.php

But the api documentation is outdated. Thanks for your help very much.

Regards,

Shao.
 
-- 
Shao Zhang  Tel:  (02) 9209 4838
Software Engineer   Fax:  (02) 9209 4992
Redfern Broadband Networks (RBN)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 #12642 Updated: Loading php_oci8 fails

[cynic]

ID: 12642
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: OCI8 related
Operating System: Windows 2000
PHP Version: 4.0.6
New Comment:

I'm sorry to say this, but if the dll is there as you say it is, and you still get 
that message, then that means your Oracle install isn't all that well. It requires 
some Oracle dlls in the %PATH%, and it's your responsibility to have them properly 
installed.

Previous Comments:


[2001-08-09 02:04:48] [EMAIL PROTECTED]

I'm sorry to say this, but I have a complete ORACLE-Installation (Client, Development, 
Administration), instead other Applications won't run and I have to administrate our 
ORACLE Installations. The Do's and Don'ts says nothing about missing PHP-Files like 
PHP_OCI8.DLL within the distribution of the WIndows Installer for IIS. This File won't 
come with ORACLE.
After some looks I'm missing other PHP_*.DLL's within this distribution, too.
Where can I get these files for the PHP.EXE in this distribution. As you can see 
below, the other DLL's (Windows Distribution CGI - Apache) won't work with this PHP.EXE



[2001-08-08 13:03:54] [EMAIL PROTECTED]

You need to have the oracle client installed on your system.
And you need to read bugs-dos-and-donts BEFORE you submit
any 'bug' reports.

--Jani




[2001-08-08 03:55:02] [EMAIL PROTECTED]

I'm using PHP 4.0.6 on a Windows 2000 + IIS 5 Server. I've downloaded the Binary with 
the Installer for Windows with IIS. After Installation there are nor php_*.dll Files.

Now I've downloaded the Windows/Apache Binary. There are php_*.dll's in the extensions 
directory. But when I try to use them (php.ini is setup up!!), I'll get an erro 
Message:

Unable to load dynamic link library 'C:\Program Files\PHP\extensions\php_oci8.dll' The 
specified module could not be found.

But the DLL is there.

Where can I get the correct dll's for the Windows IIS-Binary which are not within the 
installer or what else can I do??

Thanks for your Support





Edit this bug report at http://bugs.php.net/?id=12642&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] Apache 2.0.22 / PHP 4.0.7-dev

[Steeg]

Hi all,

First I'd like to thank Jani for helping me out the last time ;)

Now,
I don't really know if it's an apache bug or php bug, but I can't get a 
hold of any Apache environment varibles like remote host, post variables 
from a form and so on. GET works fine, but none of the others...

Could anybody enlighten me.


Thanks


Regards,
Stig Smelror



-- 
Best regards
The DeadWhale Crew
http://deadwhale.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 #12642 Updated: Loading php_oci8 fails

[Thomas . Seuring]

ID: 12642
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: OCI8 related
Operating System: Windows 2000
PHP Version: 4.0.6
New Comment:

I'm sorry to say this, but I have a complete ORACLE-Installation (Client, Development, 
Administration), instead other Applications won't run and I have to administrate our 
ORACLE Installations. The Do's and Don'ts says nothing about missing PHP-Files like 
PHP_OCI8.DLL within the distribution of the WIndows Installer for IIS. This File won't 
come with ORACLE.
After some looks I'm missing other PHP_*.DLL's within this distribution, too.
Where can I get these files for the PHP.EXE in this distribution. As you can see 
below, the other DLL's (Windows Distribution CGI - Apache) won't work with this PHP.EXE

Previous Comments:


[2001-08-08 13:03:54] [EMAIL PROTECTED]

You need to have the oracle client installed on your system.
And you need to read bugs-dos-and-donts BEFORE you submit
any 'bug' reports.

--Jani




[2001-08-08 03:55:02] [EMAIL PROTECTED]

I'm using PHP 4.0.6 on a Windows 2000 + IIS 5 Server. I've downloaded the Binary with 
the Installer for Windows with IIS. After Installation there are nor php_*.dll Files.

Now I've downloaded the Windows/Apache Binary. There are php_*.dll's in the extensions 
directory. But when I try to use them (php.ini is setup up!!), I'll get an erro 
Message:

Unable to load dynamic link library 'C:\Program Files\PHP\extensions\php_oci8.dll' The 
specified module could not be found.

But the DLL is there.

Where can I get the correct dll's for the Windows IIS-Binary which are not within the 
installer or what else can I do??

Thanks for your Support





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

[Jani Taskinen]

What about HTTP_SESSION_VARS ?? Was it forgotten or is
someone going to make it behave the same way too?

I did this already..and then I scrapped it 'cause I thought it
didn't work..and now I see it did. Unfortunately I already
threw those changes away... :( I need to sleep..

--Jani


On Wed, 8 Aug 2001, Zeev Suraski wrote:

>As those of you who are subscribed to php-cvs may have noticed, Andi and I
>implemented today the functionality I suggested to replace register_globals:
>
>- $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace $HTTP_*_VARS
>(the old vars still remain for downwards compatibility)
>- The new variables are auto-globals - they're available in all function
>contexts - there's no need to import them using the 'global' statement or
>reference them using $GLOBALS.
>- $_REQUEST (this name might change) - includes the data from $_GET,
>$_POST, $_COOKIE and $_FILES, all in one array, for those users who don't
>really care to differentiate between the various types of input.
>
>This change was my last major TODO item for PHP 4.0.7.  At this point, we
>should try to get PHP 4.0.7 out the door soon.  I suggest we branch 4.0.7
>away next Tuesday, and start the QA process.  This should give people
>enough time to make any final changes they want to put into 4.0.7.
>
>One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0
>simultaneously, with the only difference between them being the default
>value for register_globals.  This would create lots of noise and encourage
>people to start actually using the new $_GET&friends features, which can
>otherwise go unnoticed.
>
>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 #12671: Apache runs and slowly starts to "die".

[cbrittain]

From: [EMAIL PROTECTED]
Operating system: Redhat 6.2 (Zoot)
PHP version:  4.0.6
PHP Bug Type: Unknown/Other Function
Bug description:  Apache runs and slowly starts to "die".

Running Apache 1.3.20 and PHP 4.0.6 (but the same thing happens on 4.0.4x
and 4.0.3x) on a newly installed Redhat 6.2 (Kernel 2.2.14-5.0) server.

Compiled PHP following the directions EXACTLY as stated in QUICK INSTALL
(Static) of INSTALL.  Compiled Apache the same way with the exception of
adding --enable-module=rewrite and --enable-module=auth_db.

Apache starts up fine.  According to the error log:

 Apache/1.3.20 (Unix) PHP/4.0.6 configured -- resuming normal operations

Apache runs, but, the number of requests slowly (5-10 minutes) increases to
the MaxClient limit (which is 512, but, it does not matter the number).  No
.php pages will display ...  they time out.

I have tried Apache 1.3.12 and differnet PHP 4 version with the same
results.  I have tried PHP with --without-mysql and Apache without the
rewrite and auth_db modules ... same results.

Without PHP, Apache runs just fine.

Server is an PIII 800 with 512 RAM and 8 gig SCSI drive.  Redhat was
install right off the CD without any indications of errors.

Check all sites (Redhat, Apache and PHP) for similiar problems ... no luck
there.

I am lost!

Thank you for your time.


-- 
Edit bug report at: http://bugs.php.net/?id=12671&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 for #12581, #7374: dbase boolean import error (take 2)

[Lawrence E. Widman]

I have put the patch for this problem in ext/dbase/dbase.c as
diff -u against the CVS of 7 Aug 2001 in
http://www.cardiothink.com/downloads/dbase.diff-u.20010806.patch

RCS Id line in the ext/dbase/dbase.c file in the CVS copy I
used is:
/* $Id: dbase.c,v 1.45 2001/08/06 12:26:55 sniper Exp $ */

The patch is released to the PHP group under the PHP License.
Please edit to fit. The patch is released under the GPL to
anyone else who might want it.  Anyone who doesn't want it
under the GPL may also have it under the PHP License.  Credit
as appropriate would be appreciated. Please let me know if I
can provide any further information.

- Larry Widman (widman at cardiothink.com)

P.S.  Thanks to Andi Gutmans (andi at zend.com) who pointed out
diplomatically that patches to PHP must be released under the
PHP License.  Flames should be directed to me, not to him. - LW

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

[Andi Gutmans]

Cool.

Andi

At 06:25 AM 8/9/2001 +0200, Jani Taskinen wrote:
>On Thu, 9 Aug 2001, Andi Gutmans wrote:
>
> >At 06:10 AM 8/9/2001 +0200, Sascha Schumann wrote:
> >>On Wed, 8 Aug 2001, Jason Greene wrote:
> >>
> >> > If this is done should it occur before or after the branch?
> >>
> >> It should not be done at all.
> >
> >So how do you suggest to fix the current problems?
>
>I'm not 100% if the attached patch would be the correct
>way to fix this but it did remove the warning I had.
>And still I get working DSO. :)
>
>--Jani


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

Re: [PHP-DEV] PHP 4.0.7

[Jani Taskinen]

On Thu, 9 Aug 2001, Andi Gutmans wrote:

>At 06:10 AM 8/9/2001 +0200, Sascha Schumann wrote:
>>On Wed, 8 Aug 2001, Jason Greene wrote:
>>
>> > If this is done should it occur before or after the branch?
>>
>> It should not be done at all.
>
>So how do you suggest to fix the current problems?

I'm not 100% if the attached patch would be the correct
way to fix this but it did remove the warning I had.
And still I get working DSO. :)

--Jani


Index: build/rules_common.mk
===
RCS file: /repository/php4/build/rules_common.mk,v
retrieving revision 1.8
diff -u -r1.8 rules_common.mk
--- build/rules_common.mk   18 May 2001 14:40:02 -  1.8
+++ build/rules_common.mk   9 Aug 2001 04:23:21 -
@@ -22,11 +22,12 @@
 COMMON_FLAGS = $(DEFS) $(INCLUDES) $(EXTRA_INCLUDES) $(CPPFLAGS)
 COMPILE  = $(CC)  $(COMMON_FLAGS) $(CFLAGS) $(EXTRA_CFLAGS)
 CXX_COMPILE  = $(CXX) $(COMMON_FLAGS) $(CXXFLAGS) $(EXTRA_CXXFLAGS)
+LINK_FLAGS   = $(CC)  $(COMMON_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) $(LDFLAGS)
 
 SHARED_COMPILE = $(SHARED_LIBTOOL) --mode=compile $(CC) $(COMMON_FLAGS) 
$(CFLAGS_CLEAN) -prefer-pic $(EXTRA_CFLAGS) -c $< && touch $@
 CXX_SHARED_COMPILE = $(SHARED_LIBTOOL) --mode=compile $(CXX) $(COMMON_FLAGS) 
$(CXXFLAGS_CLEAN) -prefer-pic $(EXTRA_CXXFLAGS) -c $< && touch $@
 
-LINK = $(LIBTOOL) --mode=link $(COMPILE) $(LDFLAGS) -o $@
+LINK = $(LIBTOOL) --mode=link $(LINK_FLAGS) -o $@
 
 mkinstalldirs = $(top_srcdir)/build/shtool mkdir -p
 INSTALL = $(top_srcdir)/build/shtool install -c


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

Re: [PHP-DEV] PHP 4.0.7

[Andi Gutmans]

At 06:10 AM 8/9/2001 +0200, Sascha Schumann wrote:
>On Wed, 8 Aug 2001, Jason Greene wrote:
>
> > If this is done should it occur before or after the branch?
>
> It should not be done at all.

So how do you suggest to fix the current problems?

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

[Sascha Schumann]

On Wed, 8 Aug 2001, Jason Greene wrote:

> If this is done should it occur before or after the branch?

It should not be done at all.

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


-- 
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 #12670 Updated: CGI error

[cynic]

ID: 12670
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: PWS related
Operating System: Win98
PHP Version: 4.0.6
New Comment:

ask support questions in [EMAIL PROTECTED]

not a bug

Previous Comments:


[2001-08-08 23:41:51] [EMAIL PROTECTED]

Hi folks,

After install PHP when I try to open in a URL the address:
http://casa/IISSamples/Default/exemplo.php
I receive the following error:

Error 403 of HTTP
403.1 Forbided: forbided execution access

...

the original message is in portuguese, I've to translate.

PS. The contents of exemplo.php is:



On command line the php.exe -i works.

Thanks for your help.







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

[cprenato]

From: [EMAIL PROTECTED]
Operating system: Win98
PHP version:  4.0.6
PHP Bug Type: PWS related
Bug description:  CGI error

Hi folks,

After install PHP when I try to open in a URL the address:
http://casa/IISSamples/Default/exemplo.php
I receive the following error:

Error 403 of HTTP
403.1 Forbided: forbided execution access

...

the original message is in portuguese, I've to translate.

PS. The contents of exemplo.php is:



On command line the php.exe -i works.

Thanks for your help.


-- 
Edit bug report at: http://bugs.php.net/?id=12670&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] Buildproblems in latest CVS

[Jani Taskinen]

Well, the latest CVS only supports these:

libtool 1.4
autoconf 2.13
automake 1.4

I think you only need to downgrade autoconf.

--Jani

On Thu, 9 Aug 2001, Anders Johannsen wrote:

>I'am experiencing problems building PHP from the latest cvs. The errors
>occur when running 'buildconf'. The box is a Debian/unstable. Autoconf,
>automake and libtool versions seems to suffice.
>
>aj@uranos% ./buildconf
>buildconf: checking installation...
>buildconf: autoconf version 2.52 (ok)
>buildconf: automake version 1.4-p4 (ok)
>buildconf: libtool version 1.4b
>
>1996, (ok)
>rebuilding Makefile templates
>automake: configure.in: installing `Zend/ylwrap'
>rebuilding configure
>./aclocal.m4:943: error: m4_defn: undefined macro: _m4_divert_diversion
>./aclocal.m4:472: PHP_SUBST is expanded from...
>./aclocal.m4:943: the top level
>rebuilding acconfig.h
>rebuilding main/php_config.h.in
>./aclocal.m4:943: error: m4_defn: undefined macro: _m4_divert_diversion
>./aclocal.m4:472: PHP_SUBST is expanded from...
>./aclocal.m4:943: the top level
>autoconf2.50: tracing failed
>aj@uranos%
>
>Any help is much appreciated.
>
>/A
>
>


-- 
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 #12669: Utterly Global Variables - What Zeev was talkin about

[btanner]

From: [EMAIL PROTECTED]
Operating system: All
PHP version:  4.0.6
PHP Bug Type: Feature/Change Request
Bug description:  Utterly Global Variables - What Zeev was talkin about

"The new variables are auto-globals - they're available in all function
contexts" - Zeev

How hard would it be to allow a construct so that a developer could
indicate that one or more variables was available in all scope.

I have a big "Enviroment" class that does everything from data processing,
security, access control, page rendering, etc, etc, etc.  Its a huge pain
to pass around a handle to my "$Env" variable all the time.  If the access
control list needs to check something about the user, or the page needs to
know which template it should be rendering, I need to traverse my heirarchy
via this handle.  I'm tired of having references to it stored everywhere
;)

Any chance of getting this?
-- 
Edit bug report at: http://bugs.php.net/?id=12669&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 #12666 Updated: undefined symbol: mxdriver when I start apache

[sniper]

ID: 12666
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Old Bug Type: *Compile Issues
Bug Type: IMAP related
Operating System: Red Hat 7.1
PHP Version: 4.0.6
New Comment:

This should be fixed in CVS now. Try the latest snapshot:

http://snaps.php.net/


--Jani


Previous Comments:


[2001-08-08 18:24:56] [EMAIL PROTECTED]

try reading

http://php.net/bugs.php?id=10759

tell me if this helps.



[2001-08-08 18:16:56] [EMAIL PROTECTED]

I'm having a problem when I try to compile APACHE + PHP + IMAP .

The OS that I using is:
2.4.2-SGI_XFS_1.0 #1 Fri Apr 27 19:30:49 CDT 2001 i
686 unknown
apache 1.3.20
php 4.0.6
imap-4.7c / imap-4.7a / imap-2001.BETA.SNAP-0107221451

Here is the problem

When I try to compile doing this: (here is the exact commands)
Firts I compile the apache with all modules (just in case)
cd apache_1.3.20
./configure --prefix=/usr/local/apache --enable-module=all
make
make install

and php with this
./configure --with-apxs --with-imap=../imap-4.7c --with-mysql --with-ldap
make
make install
/usr/local/apache/bin/apachectl start

Syntax error on line 762 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/php-4.0.6/libs/libphp4.so into server: 
/usr/local/php-4.0.6/libs/libphp4.so: undefined symbol: mxdriver
./apachectl start: httpd could not be started


I tried this with a lot a diferents source imap and still make me the same.

I trie puting that and still doesn't work
export LDFLAGS="-L/usr/kerberos/lib -lkrb5 -lgssapi_krb5 -lpam" 
ldconfig BEFOR compiling Apache. 

Any assistance would be of great help! 

Thank 

Sebastian
[EMAIL PROTECTED]







Edit this bug report at http://bugs.php.net/?id=12666&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 #12668: unexpected behavior of preg_replace

[chuck]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.0
PHP version:  4.0.6
PHP Bug Type: PCRE related
Bug description:  unexpected behavior of preg_replace

Simple problem - the script:



should produce one plain single-quote, but instead it produces an escaped
single-quote.

No other character seems to exhibit this behavior.

Configuration:
 './configure' '--prefix=/usr/local/php4' '--with-mysql'
'--with-apxs=/usr/local/sbin/apxs' '--enable-track-vars'
'--with-gd=/usr/local' '--with-zlib-dir=shared' '--with-ttf'
'--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local'
'--with-tiff-dir=/usr/local' '--with-mcrypt' '--with-pdflib'

No other unusual configuration setups

-- 
Edit bug report at: http://bugs.php.net/?id=12668&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] Buildproblems in latest CVS

[Anders Johannsen]

I'am experiencing problems building PHP from the latest cvs. The errors
occur when running 'buildconf'. The box is a Debian/unstable. Autoconf,
automake and libtool versions seems to suffice.

aj@uranos% ./buildconf
buildconf: checking installation...
buildconf: autoconf version 2.52 (ok)
buildconf: automake version 1.4-p4 (ok)
buildconf: libtool version 1.4b

1996, (ok)
rebuilding Makefile templates
automake: configure.in: installing `Zend/ylwrap'
rebuilding configure
./aclocal.m4:943: error: m4_defn: undefined macro: _m4_divert_diversion
./aclocal.m4:472: PHP_SUBST is expanded from...
./aclocal.m4:943: the top level
rebuilding acconfig.h
rebuilding main/php_config.h.in
./aclocal.m4:943: error: m4_defn: undefined macro: _m4_divert_diversion
./aclocal.m4:472: PHP_SUBST is expanded from...
./aclocal.m4:943: the top level
autoconf2.50: tracing failed
aj@uranos%  

Any help is much appreciated.

/A

-- 
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 #12661 Updated: MYSQL_NUMROWS no longer returns a value in PHP 4.0.6

[sniper]

ID: 12661
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: MySQL related
Operating System: Linux
PHP Version: 4.0.6
New Comment:

Works for me just fine. And mysql_numrows() is deprecated
anyway and only exists as an alias for mysql_num_rows().

Closed this as if (which I doubt) it didn't work somewhere,
we're not gonna do anything about it. Use mysql_num_rows().

--Jani



Previous Comments:


[2001-08-08 16:29:07] [EMAIL PROTECTED]

I have a short script that displays the number of rows from a mysql_query using 
mysql_numrows. It lives in my windows taskbar and refreshes every hour while I'm on 
the computer.

Today my hosting company upgraded to PHP 4.0.6 from 4.0.5 and the mysql_numrows is no 
longer returning a value. Using mysql_num_rows solves the problem.

A basic version of my script is:
";
?>

I do not control the webserver, so the hosting company may have used different command 
line options when they upgraded.





Edit this bug report at http://bugs.php.net/?id=12661&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 #12667: Memory Hole Problems

[j . alberti]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.16
PHP version:  4.0.6
PHP Bug Type: IMAP related
Bug description:  Memory Hole Problems

DEAR PHP TEAM, MANY THANKS AND "YOU HAVE DONE GREAT WORK". I'm sure you
know ;-). But i have (found) a problem. ;-) Please give me a feedback,
Thanks.

#!/usr/sbin/php

 
'./configure' ('--with-apache=../apache_1.3.12' this one is is not a
module, is running as a cron job) '--enable-ftp' '--with-mysql=/usr/local/'
'--with-pdflib' '--with-jpeg-dir' '--with-png-dir' '--with-tiff-dir'
'--with-zlib' '--with-imap=/usr/src/packages/SOURCES/imap-4.7/c-client/'

The Memory usage percentage growth and growth while loop is running. Please
give me a feedback.

I workaround the problem, now with base64_encode and little scripting for
header of parts (about 30 lines)// email me if you want it ;-), and the
memory usage with a 2MB file is stable at 1.1 % with imap_mail_compose it
starts with about 8% and the VM kills it after 70 loops sending mail not
only generate at about 80%, my computer does have 192M RAM.

Best regards,

Johannes
-- 
Edit bug report at: http://bugs.php.net/?id=12667&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] Current CVS crash (latest Zend changes)

[Simon Roberts]

Aiee!  I'd just done that, when I got your message. I'd deleted my
entire php4 source dir, downloaded from CVS, rebuilt, and it appears to be
working. Aiee.  I'll keep an eye on it.

Bugger

(Sorry Zeev)

- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "Simon Roberts" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 09, 2001 11:28 AM
Subject: Re: [PHP-DEV] Current CVS crash (latest Zend changes)


> On Thu, 09 Aug 2001, Simon Roberts wrote:
> > Seems like the Zend changes that were just committed broke something -
all
> > scripts are causing a segfault.  I'm looking at what changed now.
> >
> >
> > Script:
> > 
> >
> > Configure:
> > ./configure \
> > --with-apxs \
> > --without-midgard   \
> > --without-pgsql \
> > --enable-debug; \
>
> Do a completely clean build and try again. I had that happen to me too,
> but it disappeared after I rebuilt everything. Make sure to delete
> zend_language_scanner.c and zend_language_parser.c so that they are
> regenerated.
>
> -Andrei
>
> --
> 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] Current CVS crash (latest Zend changes)

[Andrei Zmievski]

On Thu, 09 Aug 2001, Simon Roberts wrote:
> Seems like the Zend changes that were just committed broke something - all
> scripts are causing a segfault.  I'm looking at what changed now.
> 
> 
> Script:
> 
> 
> Configure:
> ./configure \
> --with-apxs \
> --without-midgard   \
> --without-pgsql \
> --enable-debug; \

Do a completely clean build and try again. I had that happen to me too,
but it disappeared after I rebuilt everything. Make sure to delete
zend_language_scanner.c and zend_language_parser.c so that they are
regenerated.

-Andrei

-- 
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: Bug #12245 Updated: gettype(true && true) returns "integer"!

[Jeroen van Wolffelaar]

Patch attached
- Original Message -
From: <[EMAIL PROTECTED]>
Newsgroups: php.dev
To: <[EMAIL PROTECTED]>
Sent: Thursday, August 09, 2001 1:12 AM
Subject: Bug #12245 Updated: gettype(true && true) returns "integer"!


> ID: 12245
> Updated by: jeroen
> Reported By: [EMAIL PROTECTED]
> Old Status: Open
> Status: Assigned
> Bug Type: Variables related
> Operating System: Solaris
> PHP Version: 4.0.6
> New Comment:
>
> KISS example:
>
> var_dump(TRUE || TRUE) -> int(1)
> var_dump(FALSE && FALSE) -> int(0)
>
> Patch awaiting to be committed, will be fixed in 4.0.7
>
>
>
> Previous Comments:
> 
>
> [2001-07-19 05:56:38] [EMAIL PROTECTED]
>
> The && operator (and ||) returns an integer value even when both arguments
are boolean. Thus the following code:
>
> function is_true($val)
> {
>return (is_bool($val) && $val);
> }
>
> echo (is_true(true) ? 'T' : 'F'),"\n";
> echo (is_true(is_true(true)) ? 'T' : 'F'),"\n";
>
> gives
>
> T
> F
>
> -- Nick
>
>
>
> 
>
>
>
> Edit this bug report at http://bugs.php.net/?id=12245&edit=1
>

 fix12245.diff

-- 
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 #12245 Updated: gettype(true && true) returns "integer"!

[jeroen]

ID: 12245
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Assigned
Bug Type: Variables related
Operating System: Solaris
PHP Version: 4.0.6
New Comment:

KISS example:

var_dump(TRUE || TRUE) -> int(1)
var_dump(FALSE && FALSE) -> int(0)

Patch awaiting to be committed, will be fixed in 4.0.7



Previous Comments:


[2001-07-19 05:56:38] [EMAIL PROTECTED]

The && operator (and ||) returns an integer value even when both arguments are 
boolean. Thus the following code:

function is_true($val)
{
   return (is_bool($val) && $val);
}

echo (is_true(true) ? 'T' : 'F'),"\n";
echo (is_true(is_true(true)) ? 'T' : 'F'),"\n";

gives

T
F

-- Nick







Edit this bug report at http://bugs.php.net/?id=12245&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 #12243 Updated: Large numbers not behaving as doubles

[jeroen]

ID: 12243
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Variables related
Operating System: FreeBSD 4.1.1-STABLE
PHP Version: 4.0.6
New Comment:

So you say that 

var_dump(50) -> int(2147483647)
And not, as expected:
float(50)

PHP uses some system routines for that, this isn't coded in PHP.


Zend/zend_language_scanner.l:line_1000:
(...)
errno = 0;
/*long*/ lval = strtol(the_digit_as_a_string, NULL, 0);
if (errno == ERANGE) { /* overflow */
(...)

If strtol is doing his job right, there is no bug here...
Are you sure this didn't happen with the older PHP-version, on the same box? Or is it 
just another pentium-bug (j/k)

It would help if you try to execute these lines in C, and see wether ERANGE is set 
correctly. If it is, I'm lost.


By the way, please try also some other values than 5 billion, some really huge values, 
and also some really negative values. Please use var_dump on them.

Previous Comments:


[2001-07-19 01:59:05] [EMAIL PROTECTED]

at your service



[2001-07-19 00:23:14] [EMAIL PROTECTED]

Absolutely. I've written just one test script with just those 2 lines in it.  I copied 
this same file to 3 servers now - the 2 that I've already mentioned plus another 
FreeBSD server (identical in hardware and OS config to the other) running 4.03PL1.  
The only one of these servers that prints out 2147483647 is the FreeBSD server running 
4.06 (also did it with 4.05).  The other 2 servers print out 50.  I also 
remember another location in my site that was affected by this bug, and I can 
GUARANTEE that it did not occur on the affected server until I updated it to 4.05. 
Please change the status of this bug report back to open.



[2001-07-19 00:15:34] [EMAIL PROTECTED]

are you sure you don't initialize the variable with 5 Million on the Linux box?



[2001-07-19 00:03:32] [EMAIL PROTECTED]

If this is strictly hardware related, then how come when I run the exact same 2 lines 
on another box running linux, I get the correct 5 billion number displayed?  The linux 
box is using an AMD 450 Mhz K6, and the FreeBSD box is using a Pentium 3-600.  I am 
not able to back up to 4.03PL1 on the FreeBSD box, but I am quite sure that this 
problem did not occur back when it was loaded.



[2001-07-18 23:52:41] [EMAIL PROTECTED]

1) longlong != double
2) the scale is HW-dependant, i. e. you need a 64-bit HW to get native support for 
64-bit numbers. that's how it's always been in PHP. there was no change WIRT this.

5,000,000,000 is clearly more than your HW can take, so it's clipped to the closest 
possible value.



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


Edit this bug report at http://bugs.php.net/?id=12243&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] Current CVS crash (latest Zend changes)

[Simon Roberts]

Yeah, it looks like language_scanner_globals isn't ready for this function
yet

(gdb) display language_scanner_globals
5: language_scanner_globals = {zendin = 0x0, zendout = 0x0, yy_leng = 0,
yy_text = 0x0,
current_buffer = 0x0, c_buf_p = 0x0, init = 1, start = 0}

So it's dereferencing a null pointer by -1 and -2 :)   Time for some more
snooping, but I expect someone to fix this before I figure out how it
works...

- Original Message -
From: "Simon Roberts" <[EMAIL PROTECTED]>
To: "Zeev Suraski" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 09, 2001 10:32 AM
Subject: Re: [PHP-DEV] Current CVS crash (latest Zend changes)


> Yes, the absolute latest - I saw the Zend changes come past "cvs update".
> The change looks to be a broken fix in r214 of zend_compile.c - Zend
itself
> is new to me (and fun :)

- Original Message -
From: "Simon Roberts" <[EMAIL PROTECTED]>
To: "Zeev Suraski" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 09, 2001 10:32 AM
Subject: Re: [PHP-DEV] Current CVS crash (latest Zend changes)


> Yes, the absolute latest - I saw the Zend changes come past "cvs update".
> The change looks to be a broken fix in r214 of zend_compile.c - Zend
itself
> is new to me (and fun :)
>
>
> @@ -2374,6 +2379,10 @@
> retval = zendlex(zendlval TSRMLS_CC);
> break;
> case T_CLOSE_TAG:
> +   if (LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-1]=='\n'
> +   ||
> (LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-2]=='\r' &&
> LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-1])) {
> +   CG(increment_lineno) = 1;
> +   }
> retval = ';'; /* implicit ; */
> break;
> case T_OPEN_TAG_WITH_ECHO:
>
>
>
> - Original Message -
> From: "Zeev Suraski" <[EMAIL PROTECTED]>
> To: "Simon Roberts" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, August 09, 2001 10:19 AM
> Subject: Re: [PHP-DEV] Current CVS crash (latest Zend changes)
>
>
> > Are you *sure* you're running the very current CVS, and not some
snapshot?
> >
> > Zeev
> >
> >
> > At 01:16 09-08-01, Simon Roberts wrote:
> > >Seems like the Zend changes that were just committed broke something -
> all
> > >scripts are causing a segfault.  I'm looking at what changed now.
> > >
> > >
> > >Script:
> > >
> > >
> > >Configure:
> > > ./configure \
> > > --with-apxs \
> > > --without-midgard   \
> > > --without-pgsql \
> > > --enable-debug; \
> > >
> > >Backtrace:
> > >Program received signal SIGSEGV, Segmentation fault.
> > >0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
> > >(gdb) bt
> > >#0  0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
> > >#1  0x403afef9 in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2393
> > >#2  0x403a79cb in zendparse () at /usr/lib/bison.simple:432
> > >#3  0x403cc57e in compile_file (file_handle=0xb2f0, type=2) at
> > >zend_language_scanner.l:364
> > >#4  0x403c29cf in zend_execute_scripts (type=8, file_count=3) at
> zend.c:803
> > >#5  0x403d587b in php_execute_script (primary_file=0xb2f0) at
> > >main.c:1304
> > >#6  0x403d1a5e in apache_php_module_main (r=0x80dacf0,
> > >display_source_mode=0) at sapi_apache.c:90
> > >#7  0x403d253a in send_php (r=0x80dacf0, display_source_mode=0,
> > >filename=0x0) at mod_php4.c:575
> > >#8  0x403d258e in send_parsed_php (r=0x80dacf0) at mod_php4.c:590
> > >#9  0x8054e8d in ap_invoke_handler () at eval.c:41
> > >#10 0x806708c in ap_some_auth_required () at eval.c:41
> > >#11 0x8067103 in ap_process_request () at eval.c:41
> > >#12 0x805f6d7 in ap_child_terminate () at eval.c:41
> > >#13 0x805f87a in ap_child_terminate () at eval.c:41
> > >#14 0x805f9bd in ap_child_terminate () at eval.c:41
> > >#15 0x805ffde in ap_child_terminate () at eval.c:41
> > >#16 0x80608a3 in main () at eval.c:41
> > >#17 0x4010918e in __libc_start_main (main=0x8060420 , argc=45,
> > >ubp_av=0xb754, init=0x804fa3c <_init>, fini=0x808a53c <_fini>,
> > >rtld_fini=0x4000cf08 <_dl_fini>, stack_end=0xb74c) at
> > >../sysdeps/generic/libc-start.c:129
> > >(gdb)
> > >
> > >
> > >--
> > >PHP Development Mailing List 
> > >To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >For additional commands, e-mail: [EMAIL PROTECTED]
> > >To contact the list administrators, e-mail:
[EMAIL PROTECTED]
> >
> > --
> > Zeev Suraski <[EMAIL PROTECTED]>
> > CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> >
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>


-- 
PHP Development Mailing List 

Re: [PHP-DEV] Current CVS crash (latest Zend changes)

[Simon Roberts]

It's as quoted in the original message :

---

---

with a \n after the ?>

# hexdump -cb phpinfo.php
000   <   ?   p   h   p   p   h   p   i   n   f   o   (   )   ;
000 074 077 160 150 160 040 160 150 160 151 156 146 157 050 051 073
010   ?   >  \n
010 040 077 076 012
014

Attached as .gz so mail transports don't mess with cr/lf etc.


- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Simon Roberts" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 09, 2001 10:35 AM
Subject: Re: [PHP-DEV] Current CVS crash (latest Zend changes)


> Can you send me the file that causes this crash?
>
> At 01:32 09-08-01, Simon Roberts wrote:
> >Yes, the absolute latest - I saw the Zend changes come past "cvs update".
> >The change looks to be a broken fix in r214 of zend_compile.c - Zend
itself
> >is new to me (and fun :)
> >
> >
> >@@ -2374,6 +2379,10 @@
> > retval = zendlex(zendlval TSRMLS_CC);
> > break;
> > case T_CLOSE_TAG:
> >+   if
(LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-1]=='\n'
> >+   ||
> >(LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-2]=='\r' &&
> >LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-1])) {
> >+   CG(increment_lineno) = 1;
> >+   }
> > retval = ';'; /* implicit ; */
> > break;
> > case T_OPEN_TAG_WITH_ECHO:
> >
> >
> >
> >- Original Message -
> >From: "Zeev Suraski" <[EMAIL PROTECTED]>
> >To: "Simon Roberts" <[EMAIL PROTECTED]>
> >Cc: <[EMAIL PROTECTED]>
> >Sent: Thursday, August 09, 2001 10:19 AM
> >Subject: Re: [PHP-DEV] Current CVS crash (latest Zend changes)
> >
> >
> > > Are you *sure* you're running the very current CVS, and not some
snapshot?
> > >
> > > Zeev
> > >
> > >
> > > At 01:16 09-08-01, Simon Roberts wrote:
> > > >Seems like the Zend changes that were just committed broke
something -
> >all
> > > >scripts are causing a segfault.  I'm looking at what changed now.
> > > >
> > > >
> > > >Script:
> > > >
> > > >
> > > >Configure:
> > > > ./configure \
> > > > --with-apxs \
> > > > --without-midgard   \
> > > > --without-pgsql \
> > > > --enable-debug; \
> > > >
> > > >Backtrace:
> > > >Program received signal SIGSEGV, Segmentation fault.
> > > >0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
> > > >(gdb) bt
> > > >#0  0x403aff0c in zendlex (zendlval=0xbfffd1e0) at
zend_compile.c:2396
> > > >#1  0x403afef9 in zendlex (zendlval=0xbfffd1e0) at
zend_compile.c:2393
> > > >#2  0x403a79cb in zendparse () at /usr/lib/bison.simple:432
> > > >#3  0x403cc57e in compile_file (file_handle=0xb2f0, type=2) at
> > > >zend_language_scanner.l:364
> > > >#4  0x403c29cf in zend_execute_scripts (type=8, file_count=3) at
> >zend.c:803
> > > >#5  0x403d587b in php_execute_script (primary_file=0xb2f0) at
> > > >main.c:1304
> > > >#6  0x403d1a5e in apache_php_module_main (r=0x80dacf0,
> > > >display_source_mode=0) at sapi_apache.c:90
> > > >#7  0x403d253a in send_php (r=0x80dacf0, display_source_mode=0,
> > > >filename=0x0) at mod_php4.c:575
> > > >#8  0x403d258e in send_parsed_php (r=0x80dacf0) at mod_php4.c:590
> > > >#9  0x8054e8d in ap_invoke_handler () at eval.c:41
> > > >#10 0x806708c in ap_some_auth_required () at eval.c:41
> > > >#11 0x8067103 in ap_process_request () at eval.c:41
> > > >#12 0x805f6d7 in ap_child_terminate () at eval.c:41
> > > >#13 0x805f87a in ap_child_terminate () at eval.c:41
> > > >#14 0x805f9bd in ap_child_terminate () at eval.c:41
> > > >#15 0x805ffde in ap_child_terminate () at eval.c:41
> > > >#16 0x80608a3 in main () at eval.c:41
> > > >#17 0x4010918e in __libc_start_main (main=0x8060420 , argc=45,
> > > >ubp_av=0xb754, init=0x804fa3c <_init>, fini=0x808a53c <_fini>,
> > > >rtld_fini=0x4000cf08 <_dl_fini>, stack_end=0xb74c) at
> > > >../sysdeps/generic/libc-start.c:129
> > > >(gdb)
>

 phpinfo.php.gz

-- 
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: Bug #12666 Updated: undefined symbol: mxdriver when I start apache

[Sebastian Navarro]

no, went I try to do what it say in this help , when I do the make for the
php return this

make[1]: Entering directory `/usr/local/php-4.0.6/main'
make[2]: Entering directory `/usr/local/php-4.0.6/main'
/bin/sh /usr/local/php-4.0.6/libtool --silent --mode=link
gcc  -I. -I/usr/local/php-4.0.6/main -I/usr/local/php-4.0.6/main -I/usr/loca
l/php-4.0.6 -I/usr/include/apache -I/usr/local/php-4.0.6/Zend -I/usr/include
/imap -I/usr/local/php-4.0.6/ext/mysql/libmysql -I/usr/local/php-4.0.6/ext/x
ml/expat/xmltok -I/usr/local/php-4.0.6/ext/xml/expat/xmlparse -I/usr/local/p
hp-4.0.6/TSRM  -DLINUX=22 -DMOD_SSL=208101 -DEAPI -DEAPI_MM -DUSE_EXPAT -DSU
PPORT_UTF8 -DXML_BYTE_ORDER=12 -g -O2  -L/usr/kerberos/lib -lkrb5 -lgssapi_k
rb5
libtool: link: you must specify an output file
Try `libtool --help --mode=link' for more information.
make[2]: *** [libmain.la] Error 1
make[2]: Leaving directory `/usr/local/php-4.0.6/main'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/php-4.0.6/main'
make: *** [all-recursive] Error 1




-Mensaje original-
De: Bug Database [mailto:[EMAIL PROTECTED]]
Enviado el: Miércoles, 08 de Agosto de 2001 07:25 p.m.
Para: [EMAIL PROTECTED]
Asunto: Bug #12666 Updated: undefined symbol: mxdriver when I start
apache


ID: 12666
Updated by: alindeman
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: *Compile Issues
Operating System: Red Hat 7.1
PHP Version: 4.0.6
New Comment:

try reading

http://php.net/bugs.php?id=10759

tell me if this helps.

Previous Comments:


[2001-08-08 18:16:56] [EMAIL PROTECTED]

I'm having a problem when I try to compile APACHE + PHP + IMAP .

The OS that I using is:
2.4.2-SGI_XFS_1.0 #1 Fri Apr 27 19:30:49 CDT 2001 i
686 unknown
apache 1.3.20
php 4.0.6
imap-4.7c / imap-4.7a / imap-2001.BETA.SNAP-0107221451

Here is the problem

When I try to compile doing this: (here is the exact commands)
Firts I compile the apache with all modules (just in case)
cd apache_1.3.20
./configure --prefix=/usr/local/apache --enable-module=all
make
make install

and php with this
./configure --with-apxs --with-imap=../imap-4.7c --with-mysql --with-ldap
make
make install
/usr/local/apache/bin/apachectl start

Syntax error on line 762 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/php-4.0.6/libs/libphp4.so into server:
/usr/local/php-4.0.6/libs/libphp4.so: undefined symbol: mxdriver
./apachectl start: httpd could not be started


I tried this with a lot a diferents source imap and still make me the same.

I trie puting that and still doesn't work
export LDFLAGS="-L/usr/kerberos/lib -lkrb5 -lgssapi_krb5 -lpam"
ldconfig BEFOR compiling Apache.

Any assistance would be of great help!

Thank

Sebastian
[EMAIL PROTECTED]







ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=12666&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] Current CVS crash (latest Zend changes)

[Zeev Suraski]

Can you send me the file that causes this crash?

At 01:32 09-08-01, Simon Roberts wrote:
>Yes, the absolute latest - I saw the Zend changes come past "cvs update".
>The change looks to be a broken fix in r214 of zend_compile.c - Zend itself
>is new to me (and fun :)
>
>
>@@ -2374,6 +2379,10 @@
> retval = zendlex(zendlval TSRMLS_CC);
> break;
> case T_CLOSE_TAG:
>+   if (LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-1]=='\n'
>+   ||
>(LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-2]=='\r' &&
>LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-1])) {
>+   CG(increment_lineno) = 1;
>+   }
> retval = ';'; /* implicit ; */
> break;
> case T_OPEN_TAG_WITH_ECHO:
>
>
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: "Simon Roberts" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Thursday, August 09, 2001 10:19 AM
>Subject: Re: [PHP-DEV] Current CVS crash (latest Zend changes)
>
>
> > Are you *sure* you're running the very current CVS, and not some snapshot?
> >
> > Zeev
> >
> >
> > At 01:16 09-08-01, Simon Roberts wrote:
> > >Seems like the Zend changes that were just committed broke something -
>all
> > >scripts are causing a segfault.  I'm looking at what changed now.
> > >
> > >
> > >Script:
> > >
> > >
> > >Configure:
> > > ./configure \
> > > --with-apxs \
> > > --without-midgard   \
> > > --without-pgsql \
> > > --enable-debug; \
> > >
> > >Backtrace:
> > >Program received signal SIGSEGV, Segmentation fault.
> > >0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
> > >(gdb) bt
> > >#0  0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
> > >#1  0x403afef9 in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2393
> > >#2  0x403a79cb in zendparse () at /usr/lib/bison.simple:432
> > >#3  0x403cc57e in compile_file (file_handle=0xb2f0, type=2) at
> > >zend_language_scanner.l:364
> > >#4  0x403c29cf in zend_execute_scripts (type=8, file_count=3) at
>zend.c:803
> > >#5  0x403d587b in php_execute_script (primary_file=0xb2f0) at
> > >main.c:1304
> > >#6  0x403d1a5e in apache_php_module_main (r=0x80dacf0,
> > >display_source_mode=0) at sapi_apache.c:90
> > >#7  0x403d253a in send_php (r=0x80dacf0, display_source_mode=0,
> > >filename=0x0) at mod_php4.c:575
> > >#8  0x403d258e in send_parsed_php (r=0x80dacf0) at mod_php4.c:590
> > >#9  0x8054e8d in ap_invoke_handler () at eval.c:41
> > >#10 0x806708c in ap_some_auth_required () at eval.c:41
> > >#11 0x8067103 in ap_process_request () at eval.c:41
> > >#12 0x805f6d7 in ap_child_terminate () at eval.c:41
> > >#13 0x805f87a in ap_child_terminate () at eval.c:41
> > >#14 0x805f9bd in ap_child_terminate () at eval.c:41
> > >#15 0x805ffde in ap_child_terminate () at eval.c:41
> > >#16 0x80608a3 in main () at eval.c:41
> > >#17 0x4010918e in __libc_start_main (main=0x8060420 , argc=45,
> > >ubp_av=0xb754, init=0x804fa3c <_init>, fini=0x808a53c <_fini>,
> > >rtld_fini=0x4000cf08 <_dl_fini>, stack_end=0xb74c) at
> > >../sysdeps/generic/libc-start.c:129
> > >(gdb)
> > >
> > >
> > >--
> > >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]

--
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 #12665 Updated: mktime() is strange

[jeroen]

ID: 12665
Updated by: jeroen
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: *General Issues
Operating System: Linux & Windows
PHP Version: 4.0.6
New Comment:

08 is octal, write 8.

See section on integers

(phpdoc / language / types / integers)

Previous Comments:


[2001-08-08 18:17:54] [EMAIL PROTECTED]

wierd...

your script says they are the same, but remove the 0's in front
of the 8 and 9 like

mktime (0,0,0,8,8,2001) (instead of mktime(0,0,0,08,08,2001))

it works as planed (not equal)

supposed to happen?? second opinion, please...





[2001-08-08 18:06:02] [EMAIL PROTECTED]

Hi all,



The result of both - mktime(0,0,0,08,08,2001) and mktime(0,0,0,08,09,2001) - is 
975538800.

Whats wrong?


Bye,
Oliver





Edit this bug report at http://bugs.php.net/?id=12665&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] Current CVS crash (latest Zend changes)

[Simon Roberts]

Yes, the absolute latest - I saw the Zend changes come past "cvs update".
The change looks to be a broken fix in r214 of zend_compile.c - Zend itself
is new to me (and fun :)


@@ -2374,6 +2379,10 @@
retval = zendlex(zendlval TSRMLS_CC);
break;
case T_CLOSE_TAG:
+   if (LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-1]=='\n'
+   ||
(LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-2]=='\r' &&
LANG_SCNG(yy_text)[LANG_SCNG(yy_leng)-1])) {
+   CG(increment_lineno) = 1;
+   }
retval = ';'; /* implicit ; */
break;
case T_OPEN_TAG_WITH_ECHO:



- Original Message -
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Simon Roberts" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, August 09, 2001 10:19 AM
Subject: Re: [PHP-DEV] Current CVS crash (latest Zend changes)


> Are you *sure* you're running the very current CVS, and not some snapshot?
>
> Zeev
>
>
> At 01:16 09-08-01, Simon Roberts wrote:
> >Seems like the Zend changes that were just committed broke something -
all
> >scripts are causing a segfault.  I'm looking at what changed now.
> >
> >
> >Script:
> >
> >
> >Configure:
> > ./configure \
> > --with-apxs \
> > --without-midgard   \
> > --without-pgsql \
> > --enable-debug; \
> >
> >Backtrace:
> >Program received signal SIGSEGV, Segmentation fault.
> >0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
> >(gdb) bt
> >#0  0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
> >#1  0x403afef9 in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2393
> >#2  0x403a79cb in zendparse () at /usr/lib/bison.simple:432
> >#3  0x403cc57e in compile_file (file_handle=0xb2f0, type=2) at
> >zend_language_scanner.l:364
> >#4  0x403c29cf in zend_execute_scripts (type=8, file_count=3) at
zend.c:803
> >#5  0x403d587b in php_execute_script (primary_file=0xb2f0) at
> >main.c:1304
> >#6  0x403d1a5e in apache_php_module_main (r=0x80dacf0,
> >display_source_mode=0) at sapi_apache.c:90
> >#7  0x403d253a in send_php (r=0x80dacf0, display_source_mode=0,
> >filename=0x0) at mod_php4.c:575
> >#8  0x403d258e in send_parsed_php (r=0x80dacf0) at mod_php4.c:590
> >#9  0x8054e8d in ap_invoke_handler () at eval.c:41
> >#10 0x806708c in ap_some_auth_required () at eval.c:41
> >#11 0x8067103 in ap_process_request () at eval.c:41
> >#12 0x805f6d7 in ap_child_terminate () at eval.c:41
> >#13 0x805f87a in ap_child_terminate () at eval.c:41
> >#14 0x805f9bd in ap_child_terminate () at eval.c:41
> >#15 0x805ffde in ap_child_terminate () at eval.c:41
> >#16 0x80608a3 in main () at eval.c:41
> >#17 0x4010918e in __libc_start_main (main=0x8060420 , argc=45,
> >ubp_av=0xb754, init=0x804fa3c <_init>, fini=0x808a53c <_fini>,
> >rtld_fini=0x4000cf08 <_dl_fini>, stack_end=0xb74c) at
> >../sysdeps/generic/libc-start.c:129
> >(gdb)
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
>


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

[PHP-DEV] AW: Bug #12665 Updated: mktime() is strange

[Oliver.Siegmar]

Looks like, that PHP just reads the 0's...

mktime(0,0,0,0,0,2001) results the same as mktime(0,0,0,0x,0x,2001)

> -Ursprüngliche Nachricht-
> Von: Bug Database [mailto:[EMAIL PROTECTED]] 
> Gesendet: Donnerstag, 9. August 2001 00:18
> An: [EMAIL PROTECTED]
> Betreff: Bug #12665 Updated: mktime() is strange
> 
> 
> ID: 12665
> Updated by: alindeman
> Reported By: [EMAIL PROTECTED]
> Status: Open
> Bug Type: *General Issues
> Operating System: Linux & Windows
> PHP Version: 4.0.6
> New Comment:
> 
> wierd...
> 
> your script says they are the same, but remove the 0's in 
> front of the 8 and 9 like
> 
> mktime (0,0,0,8,8,2001) (instead of mktime(0,0,0,08,08,2001))
> 
> it works as planed (not equal)
> 
> supposed to happen?? second opinion, please...
> 
> 
> 
> Previous Comments:
> --
> --
> 
> [2001-08-08 18:06:02] [EMAIL PROTECTED]
> 
> Hi all,
> 
>if ((mktime(0,0,0,08,08,2001)) == (mktime 
> (0,0,0,08,09,2001))) echo "Something wrong - I think!"; ?>
> 
> The result of both - mktime(0,0,0,08,08,2001) and 
> mktime(0,0,0,08,09,2001) - is 975538800.
> 
> Whats wrong?
> 
> 
> Bye,
> Oliver
> 
> --
> --
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at 
> http://bugs.php.net/?id=12665&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 #12666 Updated: undefined symbol: mxdriver when I start apache

[alindeman]

ID: 12666
Updated by: alindeman
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: *Compile Issues
Operating System: Red Hat 7.1
PHP Version: 4.0.6
New Comment:

try reading

http://php.net/bugs.php?id=10759

tell me if this helps.

Previous Comments:


[2001-08-08 18:16:56] [EMAIL PROTECTED]

I'm having a problem when I try to compile APACHE + PHP + IMAP .

The OS that I using is:
2.4.2-SGI_XFS_1.0 #1 Fri Apr 27 19:30:49 CDT 2001 i
686 unknown
apache 1.3.20
php 4.0.6
imap-4.7c / imap-4.7a / imap-2001.BETA.SNAP-0107221451

Here is the problem

When I try to compile doing this: (here is the exact commands)
Firts I compile the apache with all modules (just in case)
cd apache_1.3.20
./configure --prefix=/usr/local/apache --enable-module=all
make
make install

and php with this
./configure --with-apxs --with-imap=../imap-4.7c --with-mysql --with-ldap
make
make install
/usr/local/apache/bin/apachectl start

Syntax error on line 762 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/php-4.0.6/libs/libphp4.so into server: 
/usr/local/php-4.0.6/libs/libphp4.so: undefined symbol: mxdriver
./apachectl start: httpd could not be started


I tried this with a lot a diferents source imap and still make me the same.

I trie puting that and still doesn't work
export LDFLAGS="-L/usr/kerberos/lib -lkrb5 -lgssapi_krb5 -lpam" 
ldconfig BEFOR compiling Apache. 

Any assistance would be of great help! 

Thank 

Sebastian
[EMAIL PROTECTED]







Edit this bug report at http://bugs.php.net/?id=12666&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 #12665 Updated: mktime() is strange

[alindeman]

ID: 12665
Updated by: alindeman
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *General Issues
Operating System: Linux & Windows
PHP Version: 4.0.6
New Comment:

wierd...

your script says they are the same, but remove the 0's in front
of the 8 and 9 like

mktime (0,0,0,8,8,2001) (instead of mktime(0,0,0,08,08,2001))

it works as planed (not equal)

supposed to happen?? second opinion, please...



Previous Comments:


[2001-08-08 18:06:02] [EMAIL PROTECTED]

Hi all,



The result of both - mktime(0,0,0,08,08,2001) and mktime(0,0,0,08,09,2001) - is 
975538800.

Whats wrong?


Bye,
Oliver





Edit this bug report at http://bugs.php.net/?id=12665&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 #12666: undefined symbol: mxdriver when I start apache

[snavarro]

From: [EMAIL PROTECTED]
Operating system: Red Hat 7.1
PHP version:  4.0.6
PHP Bug Type: *Compile Issues
Bug description:  undefined symbol: mxdriver when I start apache

I'm having a problem when I try to compile APACHE + PHP + IMAP .

The OS that I using is:
2.4.2-SGI_XFS_1.0 #1 Fri Apr 27 19:30:49 CDT 2001 i
686 unknown
apache 1.3.20
php 4.0.6
imap-4.7c / imap-4.7a / imap-2001.BETA.SNAP-0107221451

Here is the problem

When I try to compile doing this: (here is the exact commands)
Firts I compile the apache with all modules (just in case)
cd apache_1.3.20
./configure --prefix=/usr/local/apache --enable-module=all
make
make install

and php with this
./configure --with-apxs --with-imap=../imap-4.7c --with-mysql --with-ldap
make
make install
/usr/local/apache/bin/apachectl start

Syntax error on line 762 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/php-4.0.6/libs/libphp4.so into server:
/usr/local/php-4.0.6/libs/libphp4.so: undefined symbol: mxdriver
./apachectl start: httpd could not be started


I tried this with a lot a diferents source imap and still make me the
same.

I trie puting that and still doesn't work
export LDFLAGS="-L/usr/kerberos/lib -lkrb5 -lgssapi_krb5 -lpam" 
ldconfig BEFOR compiling Apache. 

Any assistance would be of great help! 

Thank 

Sebastian
[EMAIL PROTECTED]


-- 
Edit bug report at: http://bugs.php.net/?id=12666&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] Current CVS crash (latest Zend changes)

[Zeev Suraski]

Are you *sure* you're running the very current CVS, and not some snapshot?

Zeev


At 01:16 09-08-01, Simon Roberts wrote:
>Seems like the Zend changes that were just committed broke something - all
>scripts are causing a segfault.  I'm looking at what changed now.
>
>
>Script:
>
>
>Configure:
> ./configure \
> --with-apxs \
> --without-midgard   \
> --without-pgsql \
> --enable-debug; \
>
>Backtrace:
>Program received signal SIGSEGV, Segmentation fault.
>0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
>(gdb) bt
>#0  0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
>#1  0x403afef9 in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2393
>#2  0x403a79cb in zendparse () at /usr/lib/bison.simple:432
>#3  0x403cc57e in compile_file (file_handle=0xb2f0, type=2) at
>zend_language_scanner.l:364
>#4  0x403c29cf in zend_execute_scripts (type=8, file_count=3) at zend.c:803
>#5  0x403d587b in php_execute_script (primary_file=0xb2f0) at
>main.c:1304
>#6  0x403d1a5e in apache_php_module_main (r=0x80dacf0,
>display_source_mode=0) at sapi_apache.c:90
>#7  0x403d253a in send_php (r=0x80dacf0, display_source_mode=0,
>filename=0x0) at mod_php4.c:575
>#8  0x403d258e in send_parsed_php (r=0x80dacf0) at mod_php4.c:590
>#9  0x8054e8d in ap_invoke_handler () at eval.c:41
>#10 0x806708c in ap_some_auth_required () at eval.c:41
>#11 0x8067103 in ap_process_request () at eval.c:41
>#12 0x805f6d7 in ap_child_terminate () at eval.c:41
>#13 0x805f87a in ap_child_terminate () at eval.c:41
>#14 0x805f9bd in ap_child_terminate () at eval.c:41
>#15 0x805ffde in ap_child_terminate () at eval.c:41
>#16 0x80608a3 in main () at eval.c:41
>#17 0x4010918e in __libc_start_main (main=0x8060420 , argc=45,
>ubp_av=0xb754, init=0x804fa3c <_init>, fini=0x808a53c <_fini>,
>rtld_fini=0x4000cf08 <_dl_fini>, stack_end=0xb74c) at
>../sysdeps/generic/libc-start.c:129
>(gdb)
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

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


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

[PHP-DEV] Current CVS crash (latest Zend changes)

[Simon Roberts]

Seems like the Zend changes that were just committed broke something - all
scripts are causing a segfault.  I'm looking at what changed now.


Script:


Configure:
./configure \
--with-apxs \
--without-midgard   \
--without-pgsql \
--enable-debug; \

Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
(gdb) bt
#0  0x403aff0c in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2396
#1  0x403afef9 in zendlex (zendlval=0xbfffd1e0) at zend_compile.c:2393
#2  0x403a79cb in zendparse () at /usr/lib/bison.simple:432
#3  0x403cc57e in compile_file (file_handle=0xb2f0, type=2) at
zend_language_scanner.l:364
#4  0x403c29cf in zend_execute_scripts (type=8, file_count=3) at zend.c:803
#5  0x403d587b in php_execute_script (primary_file=0xb2f0) at
main.c:1304
#6  0x403d1a5e in apache_php_module_main (r=0x80dacf0,
display_source_mode=0) at sapi_apache.c:90
#7  0x403d253a in send_php (r=0x80dacf0, display_source_mode=0,
filename=0x0) at mod_php4.c:575
#8  0x403d258e in send_parsed_php (r=0x80dacf0) at mod_php4.c:590
#9  0x8054e8d in ap_invoke_handler () at eval.c:41
#10 0x806708c in ap_some_auth_required () at eval.c:41
#11 0x8067103 in ap_process_request () at eval.c:41
#12 0x805f6d7 in ap_child_terminate () at eval.c:41
#13 0x805f87a in ap_child_terminate () at eval.c:41
#14 0x805f9bd in ap_child_terminate () at eval.c:41
#15 0x805ffde in ap_child_terminate () at eval.c:41
#16 0x80608a3 in main () at eval.c:41
#17 0x4010918e in __libc_start_main (main=0x8060420 , argc=45,
ubp_av=0xb754, init=0x804fa3c <_init>, fini=0x808a53c <_fini>,
rtld_fini=0x4000cf08 <_dl_fini>, stack_end=0xb74c) at
../sysdeps/generic/libc-start.c:129
(gdb)


-- 
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 #12665: mktime() is strange

[Oliver . Siegmar]

From: [EMAIL PROTECTED]
Operating system: Linux & Windows
PHP version:  4.0.6
PHP Bug Type: *General Issues
Bug description:  mktime() is strange

Hi all,



The result of both - mktime(0,0,0,08,08,2001) and mktime(0,0,0,08,09,2001)
- is 975538800.

Whats wrong?


Bye,
Oliver
-- 
Edit bug report at: http://bugs.php.net/?id=12665&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 #12636 Updated: non-linked libpam function?

[scarfboy]

ID: 12636
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Operating System: Linux (SuSE 7.1)
PHP Version: 4.0.6
New Comment:

i should say, after i removed the --with-imap option, 
`configure' worked and i typed `make', it got exactly that 
far. I fiddled with the makefile a little, but couldn't 
fix it. (i don't know anything about yacc..)


Previous Comments:


[2001-08-07 19:59:53] [EMAIL PROTECTED]

However, it doesn't compile. There seems to be a bug in 
the Zend thing. This is as far as it got:


Making all in Zend
make[1]: Entering directory 
`/root/phptmp/php4-200108071635/Zend'
/bin/sh ../libtool --silent --mode=compile gcc 
-DHAVE_CONFIG_H -I. -I. -I../main   -DEAPI_MM 
-DSINGLE_LISTEN_UNSERIALIZED_ACCEPT -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -DHARD_SERVER_LIMIT=2048 
-DDYNAMIC_MODULE_LIMIT=128 -DLINUX=22 -DMOD_SSL=208100 
-DEAPI -DUSE_EXPAT -I../TSRM  -g -O2 -prefer-pic -c 
zend_language_parser.c
/bin/sh ../libtool --silent --mode=compile gcc 
-DHAVE_CONFIG_H -I. -I. -I../main   -DEAPI_MM 
-DSINGLE_LISTEN_UNSERIALIZED_ACCEPT -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -DHARD_SERVER_LIMIT=2048 
-DDYNAMIC_MODULE_LIMIT=128 -DLINUX=22 -DMOD_SSL=208100 
-DEAPI -DUSE_EXPAT -I../TSRM  -g -O2 -prefer-pic -c 
zend_language_scanner.c
zend_language_scanner.c:2697: warning: parameter names 
(without types) in function declaration
yacc -p ini_ -v -d ./zend_ini_parser.y -o zend_ini_parser.c
usage: yacc [-dlrtv] [-b file_prefix] [-p symbol_prefix] 
filename
make[1]: *** [zend_ini_parser.c] Error 1
make[1]: Leaving directory 
`/root/phptmp/php4-200108071635/Zend'
make: *** [all-recursive] Error 1



[2001-08-07 19:51:49] [EMAIL PROTECTED]

ah... last time i tried to use cvs it was so annoying i 
decided it's an unnecessary evil. I was under the 
impression they were patches. well, whatever.

anyhow, in the latest cvs, this problem is caught by the 
makefile. well, sort of. in config.log i see normal 
``undefined reference to `whatever''' lines.. all starting 
with pam_. It can't find the libpam library. Which is 
weird, since it's in my LD_LIBRARY_PATH and all...

The message configure itself gives is:
``configure: error: This c-client library is build with 
SSL support.'', and the message to ``Add 
--with-imap-ssl<=DIR> to your configure line. Check 
config.log for details.''

The relevant part of config.log:
configure:24000: checking for IMAP support
configure:24287: checking for pam_start in -lpam
configure:24306: gcc -o conftest -g -O2  -DEAPI_MM 
-DSINGLE_LISTEN_UNSERIALIZED_ACCEPT 
-D_LARGEF/usr/i486-suse-linux/bin/ld: cannot find -lpam
collect2: ld returned 1 exit status
configure: failed program was:
#line 24295 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error. 
 */
/* We use char because int might match the return type of 
a gcc2
builtin and then its argument prototype would still 
apply.  */
char pam_start();
 
int main() {
pam_start()
; return 0; }
configure:24334: checking for crypt in -lcrypt
configure:24850: gcc -o conftest -g -O2  -DEAPI_MM 
-DSINGLE_LISTEN_UNSERIALIZED_ACCEPT 
-D_LARGEF/usr/lib/libc-client.so: undefined reference to 
`pam_end'
/usr/lib/libc-client.so: undefined reference to 
`pam_authenticate'
/usr/lib/libc-client.so: undefined reference to 
`pam_setcred'
/usr/lib/libc-client.so: undefined reference to 
`pam_acct_mgmt'
/usr/lib/libc-client.so: undefined reference to `pam_start'
collect2: ld returned 1 exit status
configure: failed program was:
#line 24825 "configure"
#include "confdefs.h"
 
  void mm_log(void){}
  void mm_dlog(void){}
  void mm_flags(void){}
  void mm_fatal(void){}
  void mm_critical(void){}
  void mm_nocritical(void){}
  void mm_notify(void){}
  void mm_login(void){}
  void mm_diskerror(void){}
  void mm_status(void){}
  void mm_lsub(void){}
  void mm_list(void){}
  void mm_exists(void){}
  void mm_searched(void){}
  void mm_expunged(void){}
  char mail_open();
  int main() {
mail_open(0,"",0);
return 0;
  }




[2001-08-07 19:21:35] [EMAIL PROTECTED]

Goto snaps.php.net, and get the latest .gz. It works exactly the same as the official 
release, and is lagging no more than 3 hours to CVS - no problem in this case



[2001-08-07 19:19:08] [EMAIL PROTECTED]

Sure. I basically copied it from the phpinfo page that was 
running on the php module that came with SuSE 7.1, and 
tweaked it a bit. Like i removed the things that kept me 
from compiling it, and removed stuff i knew i would

[PHP-DEV] Bug #12664 Updated: displaying list of groups (NNTP) from existing News Server

[alindeman]

ID: 12664
Updated by: alindeman
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: IMAP related
Operating System: windows95
PHP Version: 4.0.6
New Comment:

needs more info...

read bugs-dos-and-don'ts before submitting a bug report.

Previous Comments:


[2001-08-08 17:47:49] [EMAIL PROTECTED]

error message:  stream pointer missing





Edit this bug report at http://bugs.php.net/?id=12664&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 #12664: displaying list of groups (NNTP) from existing News Server

[sanriz]

From: [EMAIL PROTECTED]
Operating system: windows95
PHP version:  4.0.6
PHP Bug Type: IMAP related
Bug description:  displaying list of groups (NNTP) from existing News Server

error message:  stream pointer missing
-- 
Edit bug report at: http://bugs.php.net/?id=12664&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 #12663: %s 'string notator' only grabs a single word, not an entire string.

[vallimar]

From: [EMAIL PROTECTED]
Operating system: Redhat 7.1 kernel 2.4.7
PHP version:  4.0.6
PHP Bug Type: Strings related
Bug description:  %s 'string notator' only grabs a single word, not an entire string.



Execute and you will see that it does not check on strings
and any spaces will foul the results which is not good.

Which means it is only checking at the word level, and
stopping once it hits a space, instead of parsing the
entirety as a string which is what it should be doing.

I have had to switch to using explode() which is problematic
because I may have more then 1 '=' sign in the string and I
only want to split on the first one.

Please get this fixed as it causes problems, headaches and
the need to write crappily inefficent workarounds when a
simple sscanf is all you should need.



Modules.. Hmm, I have no idea really, I installed the RPM.
Goto www.sexorcisto.net/php.php  for the php configuration
output if you need it.
-- 
Edit bug report at: http://bugs.php.net/?id=12663&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] Latest CVS Problem

[Andrew Lindeman formally [EMAIL PROTECTED]]

tested on a linux 2.2.16-22 kernel (Red Hat 7.0)

happens with apache module and on command line.

On Wed, 08 Aug 2001, Zeev Suraski wrote:
> I'm unable to reproduce this under Linux (non thread safe) or Windows 
> (thread safe)...
> 
> At 23:28 08-08-01, Andrew Lindeman formally [EMAIL PROTECTED] wrote:
> >I can't use fopen (file) to get anything off the
> >internet with the latest cvs...
> >
> > >$file=fopen("http://php.net/","r";);
> >fpassthru($file);
> >?>
> >Will produce "Segmentation Fault (core dumped)"
> >
> >No idea why, but it probably needs to be fixed.
> >--
> >-
> >Andy :)
> >"Black holes are where God divided by zero."
> >
> >--
> >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]
-- 
-
Andy :)
"Black holes are where God divided by zero."

-- 
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] Latest CVS Problem

[Zeev Suraski]

I'm unable to reproduce this under Linux (non thread safe) or Windows 
(thread safe)...

At 23:28 08-08-01, Andrew Lindeman formally [EMAIL PROTECTED] wrote:
>I can't use fopen (file) to get anything off the
>internet with the latest cvs...
>
>$file=fopen("http://php.net/","r";);
>fpassthru($file);
>?>
>Will produce "Segmentation Fault (core dumped)"
>
>No idea why, but it probably needs to be fixed.
>--
>-
>Andy :)
>"Black holes are where God divided by zero."
>
>--
>PHP Development Mailing List 
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>To contact the list administrators, e-mail: [EMAIL PROTECTED]

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


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

[PHP-DEV] Bug #12662: Payflow modules

[brent]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.4
PHP version:  4.0.6
PHP Bug Type: Verisign Payflow Pro related
Bug description:  Payflow modules 

Trying to get PayFlowPro going with mod_ssl according to 
the latest thinking on the forums.

I put the PayFlowPro shared library and include in a 
directory as:
> ls -l /home/src/pfpro/lib
> total 676
> -rw-r--r--1 brentusers  683104 Aug  8 15:13 
libpfpro.so
> -rw-r--r--1 brentusers 514 Aug  8 15:13 
pfpro.h

I configure PHP 4.0.6:
> ./configure --with-pgsql \
>   --with-apache=../apache_1.3.20 \
>   --enable-track-vars \
>   --with-pfpro=shared,/home/src/pfpro/lib

Then the apache 1.3.20+mod_ssl config:

> SSL_BASE=../openssl-0.9.6b
> ./configure \
>   --enable-module=ssl \
>   --prefix=/home/apache \
>   --activate-module=src/modules/php4/libphp4.a

Everything configs, compiles and starts up nicely, but 
when I try to use the pfpro functions, I get:

> Fatal error: Call to undefined function: pfpro_version() 
in 

Further clues: in the PHP source directory, the stuff in 
the ext/pfpro is all nicely compiled into the pfpro.o, but 
when I go to the libs directory and do an "ar t libphp4.a 
| grep pfpro", there is no pfpro.o in there. This makes me 
think it's a PHP build problem, not an apache problem.


-- 
Edit bug report at: http://bugs.php.net/?id=12662&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: [PHP-QA] Re: [PHP-DEV] Latest CVS Problem

[Sterling Hughes]

On Thu, 9 Aug 2001, Sterling Hughes wrote:

> On Wed, 8 Aug 2001, Andrew Lindeman formally [EMAIL PROTECTED] wrote:
>
> > I can't use fopen (file) to get anything off the
> > internet with the latest cvs...
> >
> >  > $file=fopen("http://php.net/","r";);
> > fpassthru($file);
> > ?>
> > Will produce "Segmentation Fault (core dumped)"
> >
> > No idea why, but it probably needs to be fixed.
> >
>
> I was able to generate the attached backtrace...
>
> -Sterling
>

Actually, scratch that -- it seems to be fixed with the latest CVS,
I had an old binary lying around.

-Sterling


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

Re: [PHP-DEV] PHP 4.0.7

[Jason Greene]

If this is done should it occur before or after the branch?

-Jason

> At 02:22 PM 8/8/2001 -0500, Jason Greene wrote:
> >Well it's actually libtool 1.4 combined with automake that creates the issue
> >Automake needs the libtool mode=compile prefer-pic,prefer-non-pic flags 
> >added to CFLAGS
> >so that it gets added to the compile line. The problem is that CFLAGS is 
> >passed in linking phase
> >as well.
> >
> >If we moved back to libtool 1.3 and/or removed the pic options everything 
> >would work fine.
> >Do we want to do this though?
> 
> I don't see why not. It's not as if libtool 1.3 was causing us problems (at 
> least not problems I was aware of). We seemed to have just problems after 
> this upgrade.
> 
> 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] Latest CVS Problem

[Sterling Hughes]

On Wed, 8 Aug 2001, Andrew Lindeman formally [EMAIL PROTECTED] wrote:

> I can't use fopen (file) to get anything off the
> internet with the latest cvs...
>
>  $file=fopen("http://php.net/","r";);
> fpassthru($file);
> ?>
> Will produce "Segmentation Fault (core dumped)"
>
> No idea why, but it probably needs to be fixed.
>

I was able to generate the attached backtrace...

-Sterling



Starting program: /usr/local/bin/php tst.php

Program received signal SIGSEGV, Segmentation fault.
0x0808b6a3 in php_sock_fgets_internal (buf=0xbfffded0 "", maxlen=127,
sock=0x824dcac) at fsock.c:553
553 fsock.c: No such file or directory.
in fsock.c
(gdb) bt
#0  0x0808b6a3 in php_sock_fgets_internal (buf=0xbfffded0 "", maxlen=127,
sock=0x824dcac) at fsock.c:553
#1  0x0807fa60 in php_fopen_url_wrap_http (path=0x824cddc "http://php.net/";,
mode=0x824ce54 "r", options=4, issock=0xbfffdfd8, socketd=0xbfffdfdc,
opened_path=0x0) at http_fopen_wrapper.c:191
#2  0x08075302 in php_fopen_url_wrapper (path=0x824cddc "http://php.net/";,
mode=0x824ce54 "r", options=4, issock=0xbfffdfd8, socketd=0xbfffdfdc,
opened_path=0x0) at fopen_wrappers.c:555
#3  0x0808445b in php_if_fopen (ht=2, return_value=0x824ce34, this_ptr=0x0,
return_value_used=1) at file.c:668
#4  0x0810fb51 in execute (op_array=0x824cf54) at ./zend_execute.c:1565
#5  0x080b88dd in zend_execute_scripts (type=8, file_count=3) at zend.c:760
#6  0x08077844 in php_execute_script (primary_file=0xb490) at main.c:1238
#7  0x0807399c in main (argc=2, argv=0xb53c) at cgi_main.c:736
#8  0x400bc0de in __libc_start_main () from /lib/libc.so.6
(gdb)


-- 
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 #12658 Updated: set_error_handler() not working properly (with 'Call to undefined function')

[jmcastagnetto]

ID: 12658
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux, Win2000 sp2
PHP Version: 4.0.6
New Comment:

Using: 

error_reporting("E_ERROR"); 

does not work (same result as E_ALL), even though in Zend/zend_execute.c that is the 
error level raised. 

In Zend/zend.c the zend_error() function hands the error to zend_error_cb, which 
points to one of the utility functions created during zend_startup() (called in 
main/main.c)

I cannot track the chain down more, my C is very rusty.

Previous Comments:


[2001-08-08 16:18:00] [EMAIL PROTECTED]

My mistake, did not understood the bug report correctly.

More testing shows that calls to undefined functions do 
not generate an error level that can be catched by the error handling mechanism. Not 
even when using:

error_reporting(E_ALL);

which just aborts execution of the script and gives the msg:

Fatal error:  Call to undefined function:  whatever() in junk.php on 
line 24

whereas when using:

error_reporting(E_CORE);

just "eats up" the error (i.e. no fatal error msg is generated by the interpreter), 
and the error handling function does not have time to do anything, so the script 
aborts w/o any output.

Two issues need to be addressed:

1) The inconsitent behavior of E_CORE vs E_ALL (PHP 4.0.6), in view of the fact the 
E_ALL includes E_CORE (as per Zend/zend_errors.h)

2) Whether is desirable to allow catching of fatal errors using the 
set_error_handler() and error_reporting() functions

If the answer to (2) is no, then this should be clarified in the manual.




[2001-08-08 15:48:54] [EMAIL PROTECTED]

The assertion "... Seems that PHP cannot redirect 'Call to undefined function' errors 
to a custom error
handler..." is incorrect.

This seems to be a problem w/ the person reporting the bug *not* using the 
error_reporting() function, as it is clearly noted in the manual example, changing the 
code to read:

 ";
print_r ($context);
print "\n";
}
// Set the error handler to the error_handler() function
set_error_handler ('error_handler');
trigger_error ("Some other error"); 

whatever();
?>

The output is:

An error of level 1024 was generated in file bugtest.php on line 20. 


The error message was: Some other error
The following variables were set in the
scope that the error occurred in:  
Array (
[PWD] => /tmp
[... snip ...]
[_] => /usr/local/bin/php
[PHP_SELF] =>
[argv] => Array
(
[0] => bugtest.php
)
 
[argc] => 1
[HTTP_POST_VARS] => Array
(
)
[HTTP_GET_VARS] => Array
[...snip...]

 

This was tested with 4.0.6 on RH 7.1, more information is requested from the person 
reporting the bug, before it is reclassified as bogus.



[2001-08-08 13:23:32] [EMAIL PROTECTED]

Seems that PHP cannot redirect 'Call to undefined function' errors to a custom error 
handler... 

A sample (taken partly from the manual):


 
 ";
print_r ($context); 
print "\n"; 
} 
// Set the error handler to the error_handler() function 
set_error_handler ('error_handler'); 
trigger_error ("Some other error"); 


whatever(); // <- this will crash make the script die without calling the custom 
error_handler

?> 





Edit this bug report at http://bugs.php.net/?id=12658&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 #12661: MYSQL_NUMROWS no longer returns a value in PHP 4.0.6

[ian]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.6
PHP Bug Type: MySQL related
Bug description:  MYSQL_NUMROWS no longer returns a value in PHP 4.0.6

I have a short script that displays the number of rows from a mysql_query
using mysql_numrows. It lives in my windows taskbar and refreshes every
hour while I'm on the computer.

Today my hosting company upgraded to PHP 4.0.6 from 4.0.5 and the
mysql_numrows is no longer returning a value. Using mysql_num_rows solves
the problem.

A basic version of my script is:
";
?>

I do not control the webserver, so the hosting company may have used
different command line options when they upgraded.
-- 
Edit bug report at: http://bugs.php.net/?id=12661&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] Latest CVS Problem

[Andrew Lindeman formally [EMAIL PROTECTED]]

I can't use fopen (file) to get anything off the
internet with the latest cvs...

http://php.net/","r";);
fpassthru($file);
?>
Will produce "Segmentation Fault (core dumped)"

No idea why, but it probably needs to be fixed.
-- 
-
Andy :)
"Black holes are where God divided by zero."

-- 
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 #12658 Updated: set_error_handler() not working properly (with 'Call to undefined function')

[jmcastagnetto]

ID: 12658
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Analyzed
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux, Win2000 sp2
PHP Version: 4.0.6
Old Assigned To: jmcastagnetto
Assigned To: 
New Comment:

My mistake, did not understood the bug report correctly.

More testing shows that calls to undefined functions do 
not generate an error level that can be catched by the error handling mechanism. Not 
even when using:

error_reporting(E_ALL);

which just aborts execution of the script and gives the msg:

Fatal error:  Call to undefined function:  whatever() in junk.php on 
line 24

whereas when using:

error_reporting(E_CORE);

just "eats up" the error (i.e. no fatal error msg is generated by the interpreter), 
and the error handling function does not have time to do anything, so the script 
aborts w/o any output.

Two issues need to be addressed:

1) The inconsitent behavior of E_CORE vs E_ALL (PHP 4.0.6), in view of the fact the 
E_ALL includes E_CORE (as per Zend/zend_errors.h)

2) Whether is desirable to allow catching of fatal errors using the 
set_error_handler() and error_reporting() functions

If the answer to (2) is no, then this should be clarified in the manual.


Previous Comments:


[2001-08-08 15:48:54] [EMAIL PROTECTED]

The assertion "... Seems that PHP cannot redirect 'Call to undefined function' errors 
to a custom error
handler..." is incorrect.

This seems to be a problem w/ the person reporting the bug *not* using the 
error_reporting() function, as it is clearly noted in the manual example, changing the 
code to read:

 ";
print_r ($context);
print "\n";
}
// Set the error handler to the error_handler() function
set_error_handler ('error_handler');
trigger_error ("Some other error"); 

whatever();
?>

The output is:

An error of level 1024 was generated in file bugtest.php on line 20. 


The error message was: Some other error
The following variables were set in the
scope that the error occurred in:  
Array (
[PWD] => /tmp
[... snip ...]
[_] => /usr/local/bin/php
[PHP_SELF] =>
[argv] => Array
(
[0] => bugtest.php
)
 
[argc] => 1
[HTTP_POST_VARS] => Array
(
)
[HTTP_GET_VARS] => Array
[...snip...]

 

This was tested with 4.0.6 on RH 7.1, more information is requested from the person 
reporting the bug, before it is reclassified as bogus.



[2001-08-08 13:23:32] [EMAIL PROTECTED]

Seems that PHP cannot redirect 'Call to undefined function' errors to a custom error 
handler... 

A sample (taken partly from the manual):


 
 ";
print_r ($context); 
print "\n"; 
} 
// Set the error handler to the error_handler() function 
set_error_handler ('error_handler'); 
trigger_error ("Some other error"); 


whatever(); // <- this will crash make the script die without calling the custom 
error_handler

?> 





Edit this bug report at http://bugs.php.net/?id=12658&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 #12656 Updated: strtotime started to malfunction after OS change

[alindeman]

ID: 12656
Updated by: alindeman
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Date/time related
Operating System: Red Hat 7.1
PHP Version: 4.0.6
New Comment:

try...

print strtotime("Tue Aug 7 2001 18:48:28");

Previous Comments:


[2001-08-08 12:48:54] [EMAIL PROTECTED]

Example code :
print strtotime("Tue Aug  7 18:48:28 2001");

This sample code format used to work properly in all PHP releases this year when we 
used Red Hat 6.2. It could give the proper timestamp.

But after upgrading to Red Hat 7.1, this code only gives "-1". I always use the same 
"configure" options when compiling. I run PHP as Apache module.

I have to take the first 11 characters of the etring to calculate the timestamp, but 
it is not precise without time and year information.

What do I do to have this code work properly again?







Edit this bug report at http://bugs.php.net/?id=12656&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: compile fails on html.c (CODESET undeclared)

[Wez Furlong]

On 08/08/01, "Heikki Korpela" <[EMAIL PROTECTED]> wrote:
> On Wed, 8 Aug 2001, Wez Furlong wrote:
> > I suspect this can be fixed by changing line 231 to be
> > #if HAVE_LANGINFO_H && HAVE_LOCALE_H && defined(CODESET)
> Please do, it's repeatable on OpenBSD-current; I haven't reported it because
> I didn't have a fix yet at the time and I've been busy since.
> We have langinfo.h, but no CODESET is defined.

Done.  Please let me know if it doesn't work...

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

[PHP-DEV] Bug #12658 Updated: set_error_handler() not working properly (with 'Call to undefined function')

[jmcastagnetto]

ID: 12658
Updated by: jmcastagnetto
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Red Hat Linux, Win2000 sp2
PHP Version: 4.0.6
Old Assigned To: 
Assigned To: jmcastagnetto
New Comment:

The assertion "... Seems that PHP cannot redirect 'Call to undefined function' errors 
to a custom error
handler..." is incorrect.

This seems to be a problem w/ the person reporting the bug *not* using the 
error_reporting() function, as it is clearly noted in the manual example, changing the 
code to read:

 ";
print_r ($context);
print "\n";
}
// Set the error handler to the error_handler() function
set_error_handler ('error_handler');
trigger_error ("Some other error"); 

whatever();
?>

The output is:

An error of level 1024 was generated in file bugtest.php on line 20. 


The error message was: Some other error
The following variables were set in the
scope that the error occurred in:  
Array (
[PWD] => /tmp
[... snip ...]
[_] => /usr/local/bin/php
[PHP_SELF] =>
[argv] => Array
(
[0] => bugtest.php
)
 
[argc] => 1
[HTTP_POST_VARS] => Array
(
)
[HTTP_GET_VARS] => Array
[...snip...]

 

This was tested with 4.0.6 on RH 7.1, more information is requested from the person 
reporting the bug, before it is reclassified as bogus.

Previous Comments:


[2001-08-08 13:23:32] [EMAIL PROTECTED]

Seems that PHP cannot redirect 'Call to undefined function' errors to a custom error 
handler... 

A sample (taken partly from the manual):


 
 ";
print_r ($context); 
print "\n"; 
} 
// Set the error handler to the error_handler() function 
set_error_handler ('error_handler'); 
trigger_error ("Some other error"); 


whatever(); // <- this will crash make the script die without calling the custom 
error_handler

?> 





Edit this bug report at http://bugs.php.net/?id=12658&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 #12659 Updated: sd

[cynic]

ID: 12659
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: 
PHP Version: 4.0.6


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

[Andi Gutmans]

At 02:22 PM 8/8/2001 -0500, Jason Greene wrote:
>Well it's actually libtool 1.4 combined with automake that creates the issue
>Automake needs the libtool mode=compile prefer-pic,prefer-non-pic flags 
>added to CFLAGS
>so that it gets added to the compile line. The problem is that CFLAGS is 
>passed in linking phase
>as well.
>
>If we moved back to libtool 1.3 and/or removed the pic options everything 
>would work fine.
>Do we want to do this though?

I don't see why not. It's not as if libtool 1.3 was causing us problems (at 
least not problems I was aware of). We seemed to have just problems after 
this upgrade.

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

[Jason Greene]

Well it's actually libtool 1.4 combined with automake that creates the issue
Automake needs the libtool mode=compile prefer-pic,prefer-non-pic flags added to CFLAGS
so that it gets added to the compile line. The problem is that CFLAGS is passed in 
linking phase 
as well. 

If we moved back to libtool 1.3 and/or removed the pic options everything would work 
fine.
Do we want to do this though?

-Jason

- Original Message - 
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; 
"Zeev Suraski" <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 2:18 PM
Subject: Re: [PHP-DEV] PHP 4.0.7


> At 02:01 PM 8/8/2001 -0500, Jason Greene wrote:
> >There is one issue with 4.0.7 that probably should be fixed before branch. 
> >The build
> >system currently adds a libtool flag into CFLAGS whether libtool is in 
> >link or compile mode.
> >Since this option is only valid in compile, it gets passed to the 
> >compiler. This causes a
> >warning with gcc, but for other compilers (a la SUN CC) they fail
> >
> >I emailed Sascha about this, and he said that these options have to be 
> >added to CFLAGS,
> >in order to allow automake to still function correctly. So far it looks 
> >like the only solutions,
> >is to get rid of automake, and if that is done, I would think that it 
> >should occur before branch.
> 
> It used to work. Can't we just rollback to the automake version which worked?
> 
> 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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Zeev Suraski]

At 22:13 08-08-01, Thies C. Arntzen wrote:
>On Wed, Aug 08, 2001 at 09:20:55PM +0300, Zeev Suraski wrote:
> > My top of the list is:
> >
> > $_REQUEST
>
> $_REQ would be even nicer - and less to type without hiding
> the meaning.

I agree with Andrei on this one...

> > $_EVIL (Andi and I think it's really pretty good, but we both figured 
> we'll
> > end up going with a different alternative :)
>
> evil might cause some moral/religious problems for some ppls,
> i don't think anything in PHP should be called like that.

Hmm, interesting point :)

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 #12659: sd

[sdf]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.6
PHP Bug Type: Unknown/Other Function
Bug description:  sd

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

[Andi Gutmans]

At 02:01 PM 8/8/2001 -0500, Jason Greene wrote:
>There is one issue with 4.0.7 that probably should be fixed before branch. 
>The build
>system currently adds a libtool flag into CFLAGS whether libtool is in 
>link or compile mode.
>Since this option is only valid in compile, it gets passed to the 
>compiler. This causes a
>warning with gcc, but for other compilers (a la SUN CC) they fail
>
>I emailed Sascha about this, and he said that these options have to be 
>added to CFLAGS,
>in order to allow automake to still function correctly. So far it looks 
>like the only solutions,
>is to get rid of automake, and if that is done, I would think that it 
>should occur before branch.

It used to work. Can't we just rollback to the automake version which worked?

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

[Jason Greene]

Yes, he said the same thing to me.
The prefer-pic prefer-non-pic options where added in libtool 1.4
so this issue became present as soon as we moved to 1.4 and added those options.

-Jason

- Original Message - 
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 2:11 PM
Subject: Re: [PHP-DEV] PHP 4.0.7


> From what I understand, Sascha doesn't have time to do that in the near 
> future, so waiting for this is probably not the right thing to do.
> Is this a new issue?
> 
> Zeev
> 
> At 22:01 08-08-01, Jason Greene wrote:
> >There is one issue with 4.0.7 that probably should be fixed before branch. 
> >The build
> >system currently adds a libtool flag into CFLAGS whether libtool is in 
> >link or compile mode.
> >Since this option is only valid in compile, it gets passed to the 
> >compiler. This causes a
> >warning with gcc, but for other compilers (a la SUN CC) they fail
> >
> >I emailed Sascha about this, and he said that these options have to be 
> >added to CFLAGS,
> >in order to allow automake to still function correctly. So far it looks 
> >like the only solutions,
> >is to get rid of automake, and if that is done, I would think that it 
> >should occur before branch.
> >
> >-Jason
> >
> >- Original Message -
> >From: "Zeev Suraski" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> >Sent: Wednesday, August 08, 2001 1:48 PM
> >Subject: [PHP-DEV] PHP 4.0.7
> >
> >
> > > As those of you who are subscribed to php-cvs may have noticed, Andi and I
> > > implemented today the functionality I suggested to replace 
> > register_globals:
> > >
> > > - $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace 
> > $HTTP_*_VARS
> > > (the old vars still remain for downwards compatibility)
> > > - The new variables are auto-globals - they're available in all function
> > > contexts - there's no need to import them using the 'global' statement or
> > > reference them using $GLOBALS.
> > > - $_REQUEST (this name might change) - includes the data from $_GET,
> > > $_POST, $_COOKIE and $_FILES, all in one array, for those users who don't
> > > really care to differentiate between the various types of input.
> > >
> > > This change was my last major TODO item for PHP 4.0.7.  At this point, we
> > > should try to get PHP 4.0.7 out the door soon.  I suggest we branch 4.0.7
> > > away next Tuesday, and start the QA process.  This should give people
> > > enough time to make any final changes they want to put into 4.0.7.
> > >
> > > One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0
> > > simultaneously, with the only difference between them being the default
> > > value for register_globals.  This would create lots of noise and encourage
> > > people to start actually using the new $_GET&friends features, which can
> > > otherwise go unnoticed.
> > >
> > > 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]
> > >
> > >
> 
> --
> 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] Re: compile fails on html.c (CODESET undeclared)

[Heikki Korpela]

On Wed, 8 Aug 2001, Wez Furlong wrote:

> Err, that's a little odd.
> I would expect your system to have all of the things required for that
> to work.
> What does the config.log say about HAVE_LOCALE_H and HAVE_LANGINFO_H?

> I suspect this can be fixed by changing line 231 to be
> #if HAVE_LANGINFO_H && HAVE_LOCALE_H && defined(CODESET)

Please do, it's repeatable on OpenBSD-current; I haven't reported it because
I didn't have a fix yet at the time and I've been busy since.

We have langinfo.h, but no CODESET is defined.


-- 
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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Andrei Zmievski]

On Wed, 08 Aug 2001, Thies C. Arntzen wrote:
> On Wed, Aug 08, 2001 at 09:20:55PM +0300, Zeev Suraski wrote:
> > My top of the list is:
> > 
> > $_REQUEST
> 
> $_REQ would be even nicer - and less to type without hiding
> the meaning.

The "Perl meter" is registering non-zero reading here.

> evil might cause some moral/religious problems for some ppls,
> i don't think anything in PHP should be called like that.

you mean like easter_date()?

-Andrei

'Any given program, when running correctly, is obsolete.'
  - First Law of Computer Programming

-- 
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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Thies C. Arntzen]

On Wed, Aug 08, 2001 at 09:20:55PM +0300, Zeev Suraski wrote:
> My top of the list is:
> 
> $_REQUEST

$_REQ would be even nicer - and less to type without hiding
the meaning.

> $_EVIL (Andi and I think it's really pretty good, but we both figured we'll 
> end up going with a different alternative :)

evil might cause some moral/religious problems for some ppls,
i don't think anything in PHP should be called like that.

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]

Re: [PHP-DEV] PHP 4.0.7

[Zeev Suraski]

 From what I understand, Sascha doesn't have time to do that in the near 
future, so waiting for this is probably not the right thing to do.
Is this a new issue?

Zeev

At 22:01 08-08-01, Jason Greene wrote:
>There is one issue with 4.0.7 that probably should be fixed before branch. 
>The build
>system currently adds a libtool flag into CFLAGS whether libtool is in 
>link or compile mode.
>Since this option is only valid in compile, it gets passed to the 
>compiler. This causes a
>warning with gcc, but for other compilers (a la SUN CC) they fail
>
>I emailed Sascha about this, and he said that these options have to be 
>added to CFLAGS,
>in order to allow automake to still function correctly. So far it looks 
>like the only solutions,
>is to get rid of automake, and if that is done, I would think that it 
>should occur before branch.
>
>-Jason
>
>- Original Message -
>From: "Zeev Suraski" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>Sent: Wednesday, August 08, 2001 1:48 PM
>Subject: [PHP-DEV] PHP 4.0.7
>
>
> > As those of you who are subscribed to php-cvs may have noticed, Andi and I
> > implemented today the functionality I suggested to replace 
> register_globals:
> >
> > - $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace 
> $HTTP_*_VARS
> > (the old vars still remain for downwards compatibility)
> > - The new variables are auto-globals - they're available in all function
> > contexts - there's no need to import them using the 'global' statement or
> > reference them using $GLOBALS.
> > - $_REQUEST (this name might change) - includes the data from $_GET,
> > $_POST, $_COOKIE and $_FILES, all in one array, for those users who don't
> > really care to differentiate between the various types of input.
> >
> > This change was my last major TODO item for PHP 4.0.7.  At this point, we
> > should try to get PHP 4.0.7 out the door soon.  I suggest we branch 4.0.7
> > away next Tuesday, and start the QA process.  This should give people
> > enough time to make any final changes they want to put into 4.0.7.
> >
> > One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0
> > simultaneously, with the only difference between them being the default
> > value for register_globals.  This would create lots of noise and encourage
> > people to start actually using the new $_GET&friends features, which can
> > otherwise go unnoticed.
> >
> > 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]
> >
> >

--
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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Wez Furlong]

On 08/08/01, "Jani Taskinen" <[EMAIL PROTECTED]> wrote:
> On Wed, 8 Aug 2001, Cynic wrote:
> >Yeah. And $_SESSION too.
> Nope. It doesn't come from the user.

But it would be useful for $_SESSION to have the same global scope as
these new vars.

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

[PHP-DEV] Re: compile fails on html.c (CODESET undeclared)

[Wez Furlong]

On 08/08/01, "Marc Boeren" <[EMAIL PROTECTED]> wrote:
> html.c: In function `determine_charset':
> html.c:232: `CODESET' undeclared (first use in this function)
> html.c:232: (Each undeclared identifier is reported only once
> html.c:232: for each function it appears in.)
> make[3]: *** [html.lo] Error 1
> make[3]: Leaving directory `/home/Marc/source/php-cvs/php4/ext/standard'
> 
> The offending (in my eyes, at least) were added in the latest revision
> (1.30) of html.c by Wez Furlong (Wez? Comments?)

Err, that's a little odd.
I would expect your system to have all of the things required for that
to work.
What does the config.log say about HAVE_LOCALE_H and HAVE_LANGINFO_H?

I suspect this can be fixed by changing line 231 to be
#if HAVE_LANGINFO_H && HAVE_LOCALE_H && defined(CODESET)

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

[Jason Greene]

There is one issue with 4.0.7 that probably should be fixed before branch. The build 
system currently adds a libtool flag into CFLAGS whether libtool is in link or compile 
mode.
Since this option is only valid in compile, it gets passed to the compiler. This 
causes a
warning with gcc, but for other compilers (a la SUN CC) they fail

I emailed Sascha about this, and he said that these options have to be added to CFLAGS,
in order to allow automake to still function correctly. So far it looks like the only 
solutions,
is to get rid of automake, and if that is done, I would think that it should occur 
before branch.

-Jason

- Original Message - 
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 1:48 PM
Subject: [PHP-DEV] PHP 4.0.7


> As those of you who are subscribed to php-cvs may have noticed, Andi and I 
> implemented today the functionality I suggested to replace register_globals:
> 
> - $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace $HTTP_*_VARS 
> (the old vars still remain for downwards compatibility)
> - The new variables are auto-globals - they're available in all function 
> contexts - there's no need to import them using the 'global' statement or 
> reference them using $GLOBALS.
> - $_REQUEST (this name might change) - includes the data from $_GET, 
> $_POST, $_COOKIE and $_FILES, all in one array, for those users who don't 
> really care to differentiate between the various types of input.
> 
> This change was my last major TODO item for PHP 4.0.7.  At this point, we 
> should try to get PHP 4.0.7 out the door soon.  I suggest we branch 4.0.7 
> away next Tuesday, and start the QA process.  This should give people 
> enough time to make any final changes they want to put into 4.0.7.
> 
> One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0 
> simultaneously, with the only difference between them being the default 
> value for register_globals.  This would create lots of noise and encourage 
> people to start actually using the new $_GET&friends features, which can 
> otherwise go unnoticed.
> 
> 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 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] PHP 4.0.7

[Zeev Suraski]

At 21:51 08-08-01, Andrei Zmievski wrote:
>On Wed, 08 Aug 2001, Zeev Suraski wrote:
> > As those of you who are subscribed to php-cvs may have noticed, Andi and I
> > implemented today the functionality I suggested to replace 
> register_globals:
> >
> > - $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace 
> $HTTP_*_VARS
> > (the old vars still remain for downwards compatibility)
> > - The new variables are auto-globals - they're available in all function
> > contexts - there's no need to import them using the 'global' statement or
> > reference them using $GLOBALS.
> > - $_REQUEST (this name might change) - includes the data from $_GET,
> > $_POST, $_COOKIE and $_FILES, all in one array, for those users who don't
> > really care to differentiate between the various types of input.
> >
> > This change was my last major TODO item for PHP 4.0.7.  At this point, we
> > should try to get PHP 4.0.7 out the door soon.  I suggest we branch 4.0.7
> > away next Tuesday, and start the QA process.  This should give people
> > enough time to make any final changes they want to put into 4.0.7.
> >
> > One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0
> > simultaneously, with the only difference between them being the default
> > value for register_globals.  This would create lots of noise and encourage
> > people to start actually using the new $_GET&friends features, which can
> > otherwise go unnoticed.
>
>What about the import_globals() function that Rasmus suggested? If we
>turn off register_globals in 4.1, then we'd better have that function
>ready.

Oh yeah, that's still on my TODO list for today :)

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

[Andrei Zmievski]

On Wed, 08 Aug 2001, Zeev Suraski wrote:
> As those of you who are subscribed to php-cvs may have noticed, Andi and I 
> implemented today the functionality I suggested to replace register_globals:
> 
> - $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace $HTTP_*_VARS 
> (the old vars still remain for downwards compatibility)
> - The new variables are auto-globals - they're available in all function 
> contexts - there's no need to import them using the 'global' statement or 
> reference them using $GLOBALS.
> - $_REQUEST (this name might change) - includes the data from $_GET, 
> $_POST, $_COOKIE and $_FILES, all in one array, for those users who don't 
> really care to differentiate between the various types of input.
> 
> This change was my last major TODO item for PHP 4.0.7.  At this point, we 
> should try to get PHP 4.0.7 out the door soon.  I suggest we branch 4.0.7 
> away next Tuesday, and start the QA process.  This should give people 
> enough time to make any final changes they want to put into 4.0.7.
> 
> One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0 
> simultaneously, with the only difference between them being the default 
> value for register_globals.  This would create lots of noise and encourage 
> people to start actually using the new $_GET&friends features, which can 
> otherwise go unnoticed.

What about the import_globals() function that Rasmus suggested? If we
turn off register_globals in 4.1, then we'd better have that function
ready.

-Andrei
* Programming is an art form that fights back. *

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

[Zeev Suraski]

As those of you who are subscribed to php-cvs may have noticed, Andi and I 
implemented today the functionality I suggested to replace register_globals:

- $_GET, $_POST, $_COOKIE, $_FILES, $_ENV and $_SERVER replace $HTTP_*_VARS 
(the old vars still remain for downwards compatibility)
- The new variables are auto-globals - they're available in all function 
contexts - there's no need to import them using the 'global' statement or 
reference them using $GLOBALS.
- $_REQUEST (this name might change) - includes the data from $_GET, 
$_POST, $_COOKIE and $_FILES, all in one array, for those users who don't 
really care to differentiate between the various types of input.

This change was my last major TODO item for PHP 4.0.7.  At this point, we 
should try to get PHP 4.0.7 out the door soon.  I suggest we branch 4.0.7 
away next Tuesday, and start the QA process.  This should give people 
enough time to make any final changes they want to put into 4.0.7.

One other idea I'd like to pitch is releasing 4.0.7 and 4.1.0 
simultaneously, with the only difference between them being the default 
value for register_globals.  This would create lots of noise and encourage 
people to start actually using the new $_GET&friends features, which can 
otherwise go unnoticed.

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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Cynic]

At 20:33 8/8/2001, Jani Taskinen wrote the following:
-- 
>On Wed, 8 Aug 2001, Cynic wrote:
>>Yeah. And $_SESSION too.
>
>Nope. It doesn't come from the user.

Err, you're right.




[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs:php4 / NEWS...)

[Jani Taskinen]

On Wed, 8 Aug 2001, Cynic wrote:

>At 20:14 8/8/2001, Jani Taskinen wrote the following:
>--
>>On Wed, 8 Aug 2001, Cynic wrote:
>>
>>>How about $_DONT_TOUCH_THIS ? :)
>>>Seriously though, I vote for $_REQUEST. After all, it contains
>>>data which is (generally) tied to one particular request...
>>
>>This reminds me that should the $_FILES be included in this
>>data too? As it's also something you shouldn't trust and
>>it's also coming from the user.
>
>Yeah. And $_SESSION too.

Nope. It doesn't come from the user.

--Jani



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

Re: FW: [PHP-DEV] build problem: bison.simple:99: parse error bef ore 'do' -> \r\n or \n...

[Markus Fischer]

On Wed, Aug 08, 2001 at 05:54:34PM +0200, Marc Boeren wrote : 
> 
> > Eek! I didn't notice thatthis was on Winblows.. nevermind then. :)
> 
> Well, it wasn't, it was on a Linux box. But the cvs was checked out on a
> Winbox using cygwin, and then copied to the Linux box (that isn't allowed to
> cvs to the outside world because of the firewall... is there any way to use
> cvs over a http proxy?)
> 
> > (I think there's even a bug report about this..?)
> 
> I couldn't find it (at least, not quickly).
> There probably is a bugreport about tsrm.dsp being \n instead of \r\n,
> because I see that remark around here from time to time. However, I can't
> reach it, so I can't fix it :-)

Yes, bites always too. I don't get it and I'm staggered about my
own stupiditiy. Sometimes its checked out the right way, the
other time its unix \n with the same cvs command without doing
and modifications (using cygwin).

Anyway ... once you know it ;) ..

- Markus

-- 
Markus Fischer,  http://guru.josefine.at/~mfischer/
EMail: [EMAIL PROTECTED]
PGP Public  Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
PGP Fingerprint: D3B0 DD4F E12B F911 3CE1  C2B5 D674 B445 C227 2BD0

-- 
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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Jason Greene]

- Original Message - 
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: "Jani Taskinen" <[EMAIL PROTECTED]>; "Cynic" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 1:20 PM
Subject: Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / 
NEWS...)


> My top of the list is:
> 
> $_REQUEST
> $_EVIL (Andi and I think it's really pretty good, but we both figured we'll 
> end up going with a different alternative :)

What about $_TAINTED ?

-Jason

> 
> Zeev
> 
> At 21:12 08-08-01, Jason Greene wrote:
> >What about using the acronyms in any combination.
> >
> >like $_GPC
> >and $_GC
> >and etc
> >
> >-Jason
> >- Original Message -
> >From: "Cynic" <[EMAIL PROTECTED]>
> >To: "Jani Taskinen" <[EMAIL PROTECTED]>
> >Cc: "Zeev Suraski" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> >Sent: Wednesday, August 08, 2001 1:25 PM
> >Subject: Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: 
> >php4 / NEWS...)
> >
> >
> > > At 20:14 8/8/2001, Jani Taskinen wrote the following:
> > > --
> > > >On Wed, 8 Aug 2001, Cynic wrote:
> > > >
> > > >>How about $_DONT_TOUCH_THIS ? :)
> > > >>Seriously though, I vote for $_REQUEST. After all, it contains
> > > >>data which is (generally) tied to one particular request...
> > > >
> > > >This reminds me that should the $_FILES be included in this
> > > >data too? As it's also something you shouldn't trust and
> > > >it's also coming from the user.
> > > >
> > > >--Jani
> > >
> > > Yeah. And $_SESSION too.
> > >
> > >
> > >
> > > [EMAIL PROTECTED]
> > > -
> > > And the eyes of them both were opened and they saw that their files
> > > were world readable and writable, so they chmoded 600 their files.
> > > - Book of Installation chapt 3 sec 7
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> > >
> 
> --
> Zeev Suraski <[EMAIL PROTECTED]>
> CTO &  co-founder, Zend Technologies Ltd. http://www.zend.com/
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 
> 


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

Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Zeev Suraski]

My top of the list is:

$_REQUEST
$_EVIL (Andi and I think it's really pretty good, but we both figured we'll 
end up going with a different alternative :)

Zeev

At 21:12 08-08-01, Jason Greene wrote:
>What about using the acronyms in any combination.
>
>like $_GPC
>and $_GC
>and etc
>
>-Jason
>- Original Message -
>From: "Cynic" <[EMAIL PROTECTED]>
>To: "Jani Taskinen" <[EMAIL PROTECTED]>
>Cc: "Zeev Suraski" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>Sent: Wednesday, August 08, 2001 1:25 PM
>Subject: Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: 
>php4 / NEWS...)
>
>
> > At 20:14 8/8/2001, Jani Taskinen wrote the following:
> > --
> > >On Wed, 8 Aug 2001, Cynic wrote:
> > >
> > >>How about $_DONT_TOUCH_THIS ? :)
> > >>Seriously though, I vote for $_REQUEST. After all, it contains
> > >>data which is (generally) tied to one particular request...
> > >
> > >This reminds me that should the $_FILES be included in this
> > >data too? As it's also something you shouldn't trust and
> > >it's also coming from the user.
> > >
> > >--Jani
> >
> > Yeah. And $_SESSION too.
> >
> >
> >
> > [EMAIL PROTECTED]
> > -
> > And the eyes of them both were opened and they saw that their files
> > were world readable and writable, so they chmoded 600 their files.
> > - Book of Installation chapt 3 sec 7
> >
> >
> > --
> > 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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Zeev Suraski]

At 21:14 08-08-01, Jani Taskinen wrote:
>On Wed, 8 Aug 2001, Cynic wrote:
>
> >At 20:02 8/8/2001, Zeev Suraski wrote the following:
> >--
> >>At 21:01 08-08-01, Jani Taskinen wrote:
> >>
> >>>[moving this to php-dev]
> >>>
> >>>First: Great! Woohoo! Thanks Zeev!
> >>
> >>Andi helped with it too :)
> >>
> >>I vote for $_EVIL :)
> >
> >How about $_DONT_TOUCH_THIS ? :)
> >Seriously though, I vote for $_REQUEST. After all, it contains
> >data which is (generally) tied to one particular request...
>
>This reminds me that should the $_FILES be included in this
>data too? As it's also something you shouldn't trust and
>it's also coming from the user.

Yep, $_FILES should probably be there too.

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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Jason Greene]

What about using the acronyms in any combination.

like $_GPC
and $_GC
and etc

-Jason
- Original Message - 
From: "Cynic" <[EMAIL PROTECTED]>
To: "Jani Taskinen" <[EMAIL PROTECTED]>
Cc: "Zeev Suraski" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 1:25 PM
Subject: Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / 
NEWS...)


> At 20:14 8/8/2001, Jani Taskinen wrote the following:
> -- 
> >On Wed, 8 Aug 2001, Cynic wrote:
> >
> >>How about $_DONT_TOUCH_THIS ? :)
> >>Seriously though, I vote for $_REQUEST. After all, it contains
> >>data which is (generally) tied to one particular request...
> >
> >This reminds me that should the $_FILES be included in this
> >data too? As it's also something you shouldn't trust and
> >it's also coming from the user.
> >
> >--Jani
> 
> Yeah. And $_SESSION too.
> 
> 
> 
> [EMAIL PROTECTED]
> -
> And the eyes of them both were opened and they saw that their files
> were world readable and writable, so they chmoded 600 their files.
> - Book of Installation chapt 3 sec 7 
> 
> 
> -- 
> 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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Cynic]

At 20:14 8/8/2001, Jani Taskinen wrote the following:
-- 
>On Wed, 8 Aug 2001, Cynic wrote:
>
>>How about $_DONT_TOUCH_THIS ? :)
>>Seriously though, I vote for $_REQUEST. After all, it contains
>>data which is (generally) tied to one particular request...
>
>This reminds me that should the $_FILES be included in this
>data too? As it's also something you shouldn't trust and
>it's also coming from the user.
>
>--Jani

Yeah. And $_SESSION too.



[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Jason Greene]

How about $_COULDCONTAINSHELLCODE?

-jason

- Original Message - 
From: "Jani Taskinen" <[EMAIL PROTECTED]>
To: "Zeev Suraski" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 1:09 PM
Subject: Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / 
NEWS...)


> On Wed, 8 Aug 2001, Zeev Suraski wrote:
> 
> >At 21:01 08-08-01, Jani Taskinen wrote:
> >
> >>[moving this to php-dev]
> >>
> >>First: Great! Woohoo! Thanks Zeev!
> >
> >Andi helped with it too :)
> 
> Ah. Thanks Andi! :)
> 
> >I vote for $_EVIL :)
> 
> I am not kidding. Naming it like that would definately
> be a clear sign for everyone that this stuff is not safe
> to use just as it is.
> 
> --Jani
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 


-- 
PHP 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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs:php4 / NEWS...)

[Jani Taskinen]

On Wed, 8 Aug 2001, Cynic wrote:

>At 20:02 8/8/2001, Zeev Suraski wrote the following:
>--
>>At 21:01 08-08-01, Jani Taskinen wrote:
>>
>>>[moving this to php-dev]
>>>
>>>First: Great! Woohoo! Thanks Zeev!
>>
>>Andi helped with it too :)
>>
>>I vote for $_EVIL :)
>
>How about $_DONT_TOUCH_THIS ? :)
>Seriously though, I vote for $_REQUEST. After all, it contains
>data which is (generally) tied to one particular request...

This reminds me that should the $_FILES be included in this
data too? As it's also something you shouldn't trust and
it's also coming from the user.

--Jani



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

Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs:php4 / NEWS...)

[Jani Taskinen]

On Wed, 8 Aug 2001, Zeev Suraski wrote:

>At 21:01 08-08-01, Jani Taskinen wrote:
>
>>[moving this to php-dev]
>>
>>First: Great! Woohoo! Thanks Zeev!
>
>Andi helped with it too :)

Ah. Thanks Andi! :)

>I vote for $_EVIL :)

I am not kidding. Naming it like that would definately
be a clear sign for everyone that this stuff is not safe
to use just as it is.

--Jani



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

Re: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Cynic]

At 20:02 8/8/2001, Zeev Suraski wrote the following:
-- 
>At 21:01 08-08-01, Jani Taskinen wrote:
>
>>[moving this to php-dev]
>>
>>First: Great! Woohoo! Thanks Zeev!
>
>Andi helped with it too :)
>
>I vote for $_EVIL :)

How about $_DONT_TOUCH_THIS ? :)
Seriously though, I vote for $_REQUEST. After all, it contains
data which is (generally) tied to one particular request...




[EMAIL PROTECTED]
-
And the eyes of them both were opened and they saw that their files
were world readable and writable, so they chmoded 600 their files.
- Book of Installation chapt 3 sec 7 


-- 
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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Jason Greene]

- Original Message - 
From: "Zeev Suraski" <[EMAIL PROTECTED]>
To: "Jani Taskinen" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 1:02 PM
Subject: [PHP-DEV] Re: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)


> At 21:01 08-08-01, Jani Taskinen wrote:
> 
> >[moving this to php-dev]
> >
> >First: Great! Woohoo! Thanks Zeev!
> 
> Andi helped with it too :)
> 
>  I vote for $_EVIL :)

Well that would inspire programmers to be moe security consious with that data : )


> 
> 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 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: The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Zeev Suraski]

At 21:01 08-08-01, Jani Taskinen wrote:

>[moving this to php-dev]
>
>First: Great! Woohoo! Thanks Zeev!

Andi helped with it too :)

I vote for $_EVIL :)

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] The new $_GET/POST/ENV (was: Re: [PHP-CVS] cvs: php4 / NEWS...)

[Jani Taskinen]

[moving this to php-dev]

First: Great! Woohoo! Thanks Zeev!

On Wed, 8 Aug 2001, Zeev Suraski wrote:
>At 20:27 08-08-01, Andrei Zmievski wrote:
>>On Wed, 08 Aug 2001, Zeev Suraski wrote:
>> > Good question, open for debate...  Generally I consider GPC as a group of
>> > data which cannot be trusted, since it's coming from the user.  But I'm

Include cookie data in the $_FORM only if it's renamed to something
else. I wouldn't expect a variable named $_FORM to have anything but
the data which comes from forms.

>I tend to lean towards changing it from $_FORM too.  Andi suggested
>$_CLIENT.  Let's hear some feedback:
>
>- Keep it as $_FORM
>- $_USER

$_USER == $_EVIL

;)

--Jani


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

[PHP-DEV] Bug #12658: set_error_handler() not working properly (with 'Call to undefined function')

[joustin]

From: [EMAIL PROTECTED]
Operating system: Red Hat Linux, Win2000 sp2
PHP version:  4.0.6
PHP Bug Type: Scripting Engine problem
Bug description:  set_error_handler() not working properly (with 'Call to undefined 
function')

Seems that PHP cannot redirect 'Call to undefined function' errors to a
custom error handler... 

A sample (taken partly from the manual):


 
 ";
print_r ($context); 
print "\n"; 
} 
// Set the error handler to the error_handler() function 
set_error_handler ('error_handler'); 
trigger_error ("Some other error"); 


whatever(); // <- this will crash make the script die without calling the
custom error_handler

?> 
-- 
Edit bug report at: http://bugs.php.net/?id=12658&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 #12657 Updated: session problem when run as Apache SAPI

[sniper]

ID: 12657
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Old Bug Type: Apache related
Bug Type: *Configuration Issues
Operating System: win2000
PHP Version: 4.0.6
New Comment:

Your php.ini file you are editing isn't read by PHP.
So it's obviously in wrong place. Not a bug.



Previous Comments:


[2001-08-08 13:05:09] [EMAIL PROTECTED]

I had to run PHP as DLL rather than EXE because I need to override php.ini settings by 
using .htaccess

As an EXE it works properly, but when run as apache DLL I face session problems. 
Although I change session.save_path in php.ini to "c:\\apache\\php\\tmp" (also tried 
"c:\apache\php\tmp") PHP tries to save cookies to /tmp , and for sure it cannot.

I did a session.save_handler = mm  in php.ini, but PHP still tried to save the cookie 
to /tmp.






Edit this bug report at http://bugs.php.net/?id=12657&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 #12657: session problem when run as Apache SAPI

[lecoq_tr]

From: [EMAIL PROTECTED]
Operating system: win2000
PHP version:  4.0.6
PHP Bug Type: Apache related
Bug description:  session problem when run as Apache SAPI

I had to run PHP as DLL rather than EXE because I need to override php.ini
settings by using .htaccess

As an EXE it works properly, but when run as apache DLL I face session
problems. Although I change session.save_path in php.ini to
"c:\\apache\\php\\tmp" (also tried "c:\apache\php\tmp") PHP tries to save
cookies to /tmp , and for sure it cannot.

I did a session.save_handler = mm  in php.ini, but PHP still tried to save
the cookie to /tmp.

-- 
Edit bug report at: http://bugs.php.net/?id=12657&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 #12642 Updated: Loading php_oci8 fails

[sniper]

ID: 12642
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Bogus
Old Bug Type: *Configuration Issues
Bug Type: OCI8 related
Operating System: Windows 2000
PHP Version: 4.0.6
New Comment:

You need to have the oracle client installed on your system.
And you need to read bugs-dos-and-donts BEFORE you submit
any 'bug' reports.

--Jani


Previous Comments:


[2001-08-08 03:55:02] [EMAIL PROTECTED]

I'm using PHP 4.0.6 on a Windows 2000 + IIS 5 Server. I've downloaded the Binary with 
the Installer for Windows with IIS. After Installation there are nor php_*.dll Files.

Now I've downloaded the Windows/Apache Binary. There are php_*.dll's in the extensions 
directory. But when I try to use them (php.ini is setup up!!), I'll get an erro 
Message:

Unable to load dynamic link library 'C:\Program Files\PHP\extensions\php_oci8.dll' The 
specified module could not be found.

But the DLL is there.

Where can I get the correct dll's for the Windows IIS-Binary which are not within the 
installer or what else can I do??

Thanks for your Support





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

[sniper]

ID: 12641
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Arrays related
Operating System: FreeBSD
PHP Version: 4.0.6
New Comment:

Add a short script here which can be used to reproduce this.

--Jani


Previous Comments:


[2001-08-08 01:59:02] [EMAIL PROTECTED]

For want of to sending scripts from the form containing about 1000 fields of a type < 
input type = file > (even empty), PHP 4.0.6 does not work, in 4.0.5 all works 
normally.






Edit this bug report at http://bugs.php.net/?id=12641&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 #12656: strtotime started to malfunction after OS change

[lecoq_tr]

From: [EMAIL PROTECTED]
Operating system: Red Hat 7.1
PHP version:  4.0.6
PHP Bug Type: Date/time related
Bug description:  strtotime started to malfunction after OS change

Example code :
print strtotime("Tue Aug  7 18:48:28 2001");

This sample code format used to work properly in all PHP releases this year
when we used Red Hat 6.2. It could give the proper timestamp.

But after upgrading to Red Hat 7.1, this code only gives "-1". I always use
the same "configure" options when compiling. I run PHP as Apache module.

I have to take the first 11 characters of the etring to calculate the
timestamp, but it is not precise without time and year information.

What do I do to have this code work properly again?


-- 
Edit bug report at: http://bugs.php.net/?id=12656&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 #10800 Updated: File uploads take ~70 times longer than downloading files on Apache/PHP.

[paul]

ID: 10800
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: HTTP related
Operating System: NT 2000
PHP Version: 4.0.5
New Comment:

I'm sorry it took so long in getting back Andy. Your question:

"Could you please include the script that accepts the form 
input and uploads the file (the ACTION param of the form.)"

Here it is:

  if (!$tmp_file = get_cfg_var('upload_tmp_dir')) {
$tmp_file = dirname(tempnam('', ''));
  }
  $tmp_file .= '/' . basename($userfile);
  // Admin may have trailing slash in php.ini...
  // Did it upload? */
  if (ereg_replace('/+', '/', $tmp_file) == $userfile);
copy($userfile, "$basedir/$name");
echo "Success verbage goes here.";
  } else {
echo "Some kind of warning goes here.";
  }

Thanks Andy,

Paul

Previous Comments:


[2001-08-07 12:27:00] [EMAIL PROTECTED]

status -> feedback



[2001-07-21 21:46:17] [EMAIL PROTECTED]

Could you please include the script that accepts the form
input and uploads the file (the ACTION param of the form.)

-Andy



[2001-05-10 17:51:00] [EMAIL PROTECTED]

I logged this prior to PHP 4.0.5 and was told to do it again if it still occurs. 
Please help:

ID: 9294 
Updated by: andi 
Reported By: [EMAIL PROTECTED] 
Old-Status: Open 
Status: Closed 
Bug Type: Performance problem 
PHP Version: 4.0.2 
Assigned To:  
Comments: 
 
Please try PHP 4.0.4pl1 or 4.0.5 which is due out tomorrow and open a new bug report 
if this still happens. 
 
Previous Comments: 
--- 
 
[2001-02-16 03:59:04] [EMAIL PROTECTED] 
Sorry - I'm also using code like this to do the upload: 
 
 
 
Send this file:  
 
 
 
--- 
 
[2001-02-16 03:57:16] [EMAIL PROTECTED] 
When performing a file upload, PHP runs the CPU to 100% and takes 3.5-4 minutes on 
a Pentium III 850MHz CPU to upload a 10MB file when downloading the same file on 
Apache/PHP only takes 3 seconds on the same host and client. It appears the file 
is being parsed when being uploaded. Is there an option to tell PHP to upload the 
data and nothing else? Otherwise, it is roughly 70 times slower to upload a file 
than to download one. 
 
I'm using Nusphere's CD when installing the software. 
 





Edit this bug report at http://bugs.php.net/?id=10800&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] compile fails on html.c (CODESET undeclared)

[Marc Boeren]

Latest cvs fails to compile on Linux (redhat 6.1)
(clean checkout)

./buildconf
./configure --with-mysql --enable-dbx
make

produces...

html.c: In function `determine_charset':
html.c:232: `CODESET' undeclared (first use in this function)
html.c:232: (Each undeclared identifier is reported only once
html.c:232: for each function it appears in.)
make[3]: *** [html.lo] Error 1
make[3]: Leaving directory `/home/Marc/source/php-cvs/php4/ext/standard'


The offending (in my eyes, at least) were added in the latest revision
(1.30) of html.c by Wez Furlong (Wez? Comments?)

Cheerio, Marc.

-- 
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 #12655: date-format problem

[thomas . winkler]

From: [EMAIL PROTECTED]
Operating system: Win2k
PHP version:  4.0.6
PHP Bug Type: MSSQL related
Bug description:  date-format problem

webserver: IIS5 (Win2k) 
php-version: php4.0.6 (CGI)
db-server: MS SQL Server 2000

I've run into problems when fetching fields of type datetime from the
database.
When using the MS SQL Query Analyzer I get the dates formated like this out
of the database:
2001-06-08 08:14:40.000
When using php to send my queries (mssql_query) to the database I get the
dates formated like this: 08 06 2001 8:14

In my application I'd need the same format as i get it in the
Query-Analyzer.
-- 
Edit bug report at: http://bugs.php.net/?id=12655&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] about #12645 - xsl:include

[Håvard Dahle]

Marius Andreiana <[EMAIL PROTECTED]>, ons 2001-08-08; 
> I've solved it by using
> 
> 

FWIW, this is how I solve this (php 4.0.6, Sablotron 0.60.1):

In my xslt, i have this statement:



I use xslt_transform() as it lets me use named buffers and pass
parameters to the xslt parser, thusly:

$sablot_buffers = array("/common.xsl" => "file://absolute/path/to/common_xslt",
"/xml_data"   => $an_xml_string);
$sablot_args= array("arg1" => 2,
"arg2" => "three");

xslt_transform("file://$absolute_path_to_main_xslt", "arg:/xml_data", 
"arg:/_result", $sablot_args, $sablot_buffers, $result);

print $result;


Note that using this syntax, the named result buffer "arg:/_result" must
be present.

HTH,

-- 
Håvard Dahle
'We apologize for the inconvenience.'


--
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: FW: [PHP-DEV] build problem: bison.simple:99: parse error bef ore 'do' -> \r\n or \n...

[Marc Boeren]

> Duh! I should have read the email more carefully..I just get
> this odd rash everytime I see anything that even resemple Windows.. :)

I get that, too :)
What is worse, though, is the multitude of stupid cross-platform
incompatibilies, of which the whole EOL \r\n, \r, \n stuff is one of the
most annoying.
I vote we drop all three variant on all platforms now, and use \g instead
:-)

> Anyway, why don't you just use the snapshots? http://snaps.php.net/

That way, it is more difficult to commit the changes I make to dbx once in a
while :-)

The whole \r\n wouldn't be so bad if I just didn't use the built-in MSVS
editor, which can only save \r\n. Give me EditPlus instead...


Cheerio, Marc.

-- 
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 #12654 Updated: File http://www.php.net:8000/distributions/manual_de.chm OK?

[gerhard]

ID: 12654
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Unknown/Other Function
Operating System: Win98SE de IE5.5 HtmlHelp4.74.87
PHP Version: 4.0.6
New Comment:

initial bug-report number is #12638

Previous Comments:


[2001-08-08 11:44:02] [EMAIL PROTECTED]

sorry for starting a new thread, but I did not supply a password and your database 
neither
accepts my reply without a pw nor mails me a generated one, now I know...

If I open it directly in Netscape 4.75, I get plain text in my window so I have
downloaded the file.

When I start it, the error message is:

Microsoft® InfoTech Storage System Library versuchte einen Nullzeiger
(translated: zeropointer used) zu verwenden.

Modul: ITSS.DLL
Beschreibung: Microsoft® InfoTech Storage System Library
Version: 4.72.8085.0
Produkt: Microsoft(R) Windows NT(R) Operating System
Hersteller: Microsoft Corporation

Anwendung: Hh.exe
Beschreibung: Microsoft® HTML Help Executable
Version: 4.74.8875
Produkt: HTML Help
Hersteller: Microsoft Corporation

After that, the CPU is working with 100%, I cannot kill the task (Ctrl+Alt+Del)
or shutdown, but have to switch off my System.

I have updated Hh.exe with the recent update 1.3 available from Microsoft after
I experienced the crashes, but the same result... (above error-message with
already installed update)

If necessary, I can send a DrWatson Snaphot of the crash. (81 kb zipped)

Regards, Gerhard






Edit this bug report at http://bugs.php.net/?id=12654&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: FW: [PHP-DEV] build problem: bison.simple:99: parse error before 'do' -> \r\n or \n...

[Jani Taskinen]

Eek! I didn't notice thatthis was on Winblows.. nevermind then. :)
(I think there's even a bug report about this..?)

--Jani


On Wed, 8 Aug 2001, Marc Boeren wrote:

>
>
>> -Original Message-
>> From: Marc Boeren
>> Sent: Wednesday, August 08, 2001 5:40 PM
>> To: 'Jani Taskinen'
>> Subject: RE: [PHP-DEV] build problem: bison.simple:99: parse error
>> before 'do' -> \r\n or \n...
>>
>>
>>
>> > Works fine for me. Try doing './cvsclean ; ./buildconf'
>> > >bison.simple:99: stray '\' in program
>>
>> I spent some time on it, and just now traced it down to a
>> simple thing: \r\n against \n
>> Four files in the Zend folder ended in \r\n, instead of \n
>> (hence, the line-continuation character \ is not recognized properly)
>> I also have this problem every time I checkout TSRM.dsp, but
>> then in reverse...
>>
>> My situation is this:
>> 1. I use cygwin on my windows box to connect to cvs
>> 2. I use msvs on my windows box to compile
>> 3. I copy my checked-out folder to my linux box to compile
>>
>> 1. no problem
>> 2. any time I check out TSRM.dsp, I have to convert from \n
>> to \r\n for msvs
>> 3. I had to convert zend_language_scanner.c,
>> zend_language_parser.c, zend_ini_parser.c and
>> zend_ini_scanner.c from \r\n to \n
>>
>> What might have happened is that I accidentally opened the
>> files from 3 on my win box and saved 'm (and thus
>> automatically converting them to \r\n).
>> Since my cygwin is set up to handle text files as Unix (\n),
>> the only thing that is actually strange is the TSRM.dsp
>> (since the other .dsp's are not a problem).
>> Could it be that the other .dsp's are marked as binary in
>> cvs, and only TSRM.dsp is marked as text?
>>
>> BTW, this is something that should really be documented
>> somewhere, since the error you actually get is very
>> confusing, and if you open a textfile it is never obvious if
>> it's PC, Mac or Unix mode
>> Or could this simply be designated as a bug in the gcc-compiler?
>>
>> Anyway, all is fine now (although I do get an error in
>> ext/standard/html.c about a CODESET that is undeclared, but
>> at least that is a clear message :-)
>>
>> Cheerio, Marc.
>>
>
>


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