[PHP-DEV] Global variables in extensions
Hi! I have a problem that is driving me crazy. I need to allocate some memory that will be available throughout a session. Firstly a database connection is established, but at the same time I read all relevant information about the db (records, attributes, typedeclarations and such and such). This is a rather lengthy process so I am trying to store these information in memory for later retrieval. This is the part, that doesn't work. Whenever a new page is loaded the information is lost. I have tried using static (global) variables, and I have tried the ZEND_BEGIN/END_MODULE_GLOBALS. About the ZEND_BEGIN/END... approach: the std. skeleton defines these macros: #ifdef ZTS #define RAIMAG(v) (raima_globals-v) #define RAIMALS_FETCH() php_raima_globals *raima_globals=ts_resource(raima_globals_id) #else #define RAIMAG(v) (raima_globals.v) #define RAIMALS_FETCH() #endif How do I utilize ZTS? Where is raima_globals_id defined? I do set a variable in PHP_MINIT_FUNCTION that variable is always set! But any other variables from the ZEND_BEGIN/END_MODULE_GLOBALS section (phew) that is set later do not remember their value??? Why is that? Thanks Thomas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Proper version of PostgreSQL?
For those of you building --with-pgsql, what version of PostgreSQL are you able to build against? I cannot get PHP to build against 6.5.3... Make fails with: pgsql.c: In function `_rollback_transactions': pgsql.c:165: void value not ignored as it ought to be Line 165 of ext/pgsql/pgsql.c: old_notice_hook = PQsetNoticeProcessor(link, _be_quiet, NULL); In /usr/include/postgresql/libpq-fe.h, I have: extern void PQsetNoticeProcessor (PGconn *conn, PQnoticeProcessor proc,void *arg) I looked in the 7.0.3 source, and found that this function now returns a "PQnoticeProcessor". Perhaps once 4.0.5 is out, someone would like to patch pgsql's config.m4 so that it checks version? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Global variables in extensions
How are you loading your extension? If you're using dl(), forget about retaining any type of information in between requests... You must use extension= in php.ini Zeev At 11:58 30/3/2001, Thomas Wentzel wrote: Hi! I have a problem that is driving me crazy. I need to allocate some memory that will be available throughout a session. Firstly a database connection is established, but at the same time I read all relevant information about the db (records, attributes, typedeclarations and such and such). This is a rather lengthy process so I am trying to store these information in memory for later retrieval. This is the part, that doesn't work. Whenever a new page is loaded the information is lost. I have tried using static (global) variables, and I have tried the ZEND_BEGIN/END_MODULE_GLOBALS. About the ZEND_BEGIN/END... approach: the std. skeleton defines these macros: #ifdef ZTS #define RAIMAG(v) (raima_globals-v) #define RAIMALS_FETCH() php_raima_globals *raima_globals=ts_resource(raima_globals_id) #else #define RAIMAG(v) (raima_globals.v) #define RAIMALS_FETCH() #endif How do I utilize ZTS? Where is raima_globals_id defined? I do set a variable in PHP_MINIT_FUNCTION that variable is always set! But any other variables from the ZEND_BEGIN/END_MODULE_GLOBALS section (phew) that is set later do not remember their value??? Why is that? Thanks Thomas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[Fwd: Re: [PHP-DEV] Global variables in extensions]
missed the mailinglist :) Original Message Subject: Re: [PHP-DEV] Global variables in extensions Date: Fri, 30 Mar 2001 13:16:36 +0200 From: Thomas Wentzel [EMAIL PROTECTED] Organization: 2M Electronic A/S To: Zeev Suraski [EMAIL PROTECTED] References: [EMAIL PROTECTED] Hi Zeev, My extension is compiled _into_ php which is loaded as a module in apache! I'm not using the php.ini file at the moment - is it really necessary? Thomas Zeev Suraski wrote: How are you loading your extension? If you're using dl(), forget about retaining any type of information in between requests... You must use extension= in php.ini Zeev At 11:58 30/3/2001, Thomas Wentzel wrote: Hi! I have a problem that is driving me crazy. I need to allocate some memory that will be available throughout a session. Firstly a database connection is established, but at the same time I read all relevant information about the db (records, attributes, typedeclarations and such and such). This is a rather lengthy process so I am trying to store these information in memory for later retrieval. This is the part, that doesn't work. Whenever a new page is loaded the information is lost. I have tried using static (global) variables, and I have tried the ZEND_BEGIN/END_MODULE_GLOBALS. About the ZEND_BEGIN/END... approach: the std. skeleton defines these macros: #ifdef ZTS #define RAIMAG(v) (raima_globals-v) #define RAIMALS_FETCH() php_raima_globals *raima_globals=ts_resource(raima_globals_id) #else #define RAIMAG(v) (raima_globals.v) #define RAIMALS_FETCH() #endif How do I utilize ZTS? Where is raima_globals_id defined? I do set a variable in PHP_MINIT_FUNCTION that variable is always set! But any other variables from the ZEND_BEGIN/END_MODULE_GLOBALS section (phew) that is set later do not remember their value??? Why is that? Thanks Thomas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Global variables in extensions
Ah, no, it's not necessary. I thought you were talking about a dynamic extension. What exactly isn't working? Is something that you're storing in a static/global variable not retained by the time of the next request? A couple of things that are worth mentioning: - You can only set the values for global/static variables during the initial startup (minit). - Changes you make to these values afterwards will only be retained in the context of a single process, because the static/global variables are only global process-wide, whereas Apache has many simultaneous processes. My guess is that you probably considered global variables to be more global than they really are (i.e., across processes). In order to have variables that are shared among all Apache processes, you're going to have to use shared memory or some other type of persistent shared storage. Zeev At 13:16 30/3/2001, Thomas Wentzel wrote: Hi Zeev, My extension is compiled _into_ php which is loaded as a module in apache! I'm not using the php.ini file at the moment - is it really necessary? Thomas Zeev Suraski wrote: How are you loading your extension? If you're using dl(), forget about retaining any type of information in between requests... You must use extension= in php.ini Zeev At 11:58 30/3/2001, Thomas Wentzel wrote: Hi! I have a problem that is driving me crazy. I need to allocate some memory that will be available throughout a session. Firstly a database connection is established, but at the same time I read all relevant information about the db (records, attributes, typedeclarations and such and such). This is a rather lengthy process so I am trying to store these information in memory for later retrieval. This is the part, that doesn't work. Whenever a new page is loaded the information is lost. I have tried using static (global) variables, and I have tried the ZEND_BEGIN/END_MODULE_GLOBALS. About the ZEND_BEGIN/END... approach: the std. skeleton defines these macros: #ifdef ZTS #define RAIMAG(v) (raima_globals-v) #define RAIMALS_FETCH() php_raima_globals *raima_globals=ts_resource(raima_globals_id) #else #define RAIMAG(v) (raima_globals.v) #define RAIMALS_FETCH() #endif How do I utilize ZTS? Where is raima_globals_id defined? I do set a variable in PHP_MINIT_FUNCTION that variable is always set! But any other variables from the ZEND_BEGIN/END_MODULE_GLOBALS section (phew) that is set later do not remember their value??? Why is that? Thanks Thomas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: www.php.net down?
Hartmut Holzgraefe wrote: www.php.net (and so bugs.php.net) seems to be down as i'm not sure if [EMAIL PROTECTED] is handled by this machine i CC this to [EMAIL PROTECTED] too Both are working. BTW CeBIT is over. -Egon -- SIX Offene Systeme GmbH Stuttgart - Berlin Sielminger Strae 63 D-70771 Leinfelden-Echterdingen Fon +49 711 9909164 Fax +49 711 9909199 http://www.six.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Global variables in extensions
Thank you very much for your answer, Zeev. It really helped me understand (to some extend) what is going on. Yes! I considered global variables to be more global than the case being :( Well I guess I should go for the shared memory approach then, but how? Reading about shmget in the man-page revealed to me, that it is necessary to store a key that is used to reference the memory segment, but how is this done! If I could store the key, then I would have no need to use shared memory. Obviously I could allocate a segment in MINIT and use this throughout, but then it wouldn't be possible for me to alter the segment size - which sounds sort of bad... Thomas Zeev Suraski wrote: Ah, no, it's not necessary. I thought you were talking about a dynamic extension. What exactly isn't working? Is something that you're storing in a static/global variable not retained by the time of the next request? A couple of things that are worth mentioning: - You can only set the values for global/static variables during the initial startup (minit). - Changes you make to these values afterwards will only be retained in the context of a single process, because the static/global variables are only global process-wide, whereas Apache has many simultaneous processes. My guess is that you probably considered global variables to be more global than they really are (i.e., across processes). In order to have variables that are shared among all Apache processes, you're going to have to use shared memory or some other type of persistent shared storage. Zeev At 13:16 30/3/2001, Thomas Wentzel wrote: Hi Zeev, My extension is compiled _into_ php which is loaded as a module in apache! I'm not using the php.ini file at the moment - is it really necessary? Thomas Zeev Suraski wrote: How are you loading your extension? If you're using dl(), forget about retaining any type of information in between requests... You must use extension= in php.ini Zeev At 11:58 30/3/2001, Thomas Wentzel wrote: Hi! I have a problem that is driving me crazy. I need to allocate some memory that will be available throughout a session. Firstly a database connection is established, but at the same time I read all relevant information about the db (records, attributes, typedeclarations and such and such). This is a rather lengthy process so I am trying to store these information in memory for later retrieval. This is the part, that doesn't work. Whenever a new page is loaded the information is lost. I have tried using static (global) variables, and I have tried the ZEND_BEGIN/END_MODULE_GLOBALS. About the ZEND_BEGIN/END... approach: the std. skeleton defines these macros: #ifdef ZTS #define RAIMAG(v) (raima_globals-v) #define RAIMALS_FETCH() php_raima_globals *raima_globals=ts_resource(raima_globals_id) #else #define RAIMAG(v) (raima_globals.v) #define RAIMALS_FETCH() #endif How do I utilize ZTS? Where is raima_globals_id defined? I do set a variable in PHP_MINIT_FUNCTION that variable is always set! But any other variables from the ZEND_BEGIN/END_MODULE_GLOBALS section (phew) that is set later do not remember their value??? Why is that? Thanks Thomas -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: www.php.net down?
Quoting "Egon Schmid (@work)" [EMAIL PROTECTED]: Hartmut Holzgraefe wrote: www.php.net (and so bugs.php.net) seems to be down as i'm not sure if [EMAIL PROTECTED] is handled by this machine i CC this to [EMAIL PROTECTED] too Both are working. THey are not working for me either. Derick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: www.php.net down?
Derick Rethans wrote: Quoting "Egon Schmid (@work)" [EMAIL PROTECTED]: Hartmut Holzgraefe wrote: www.php.net (and so bugs.php.net) seems to be down as i'm not sure if [EMAIL PROTECTED] is handled by this machine i CC this to [EMAIL PROTECTED] too Both are working. THey are not working for me either. www.php.net is down toye.php.net is alive Both lists are working -Egon -- SIX Offene Systeme GmbH Stuttgart - Berlin Sielminger Strae 63 D-70771 Leinfelden-Echterdingen Fon +49 711 9909164 Fax +49 711 9909199 http://www.six.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-QA] RC2 reports on various platforms
1.3 is (I think) the official release version. However, we've only upgraded to this in the past couple of days, version 1.2 had exactly the same behaviour. Thanks. I've committed a fix to the main branch which has been tested on Darwin 1.2. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #5595 Updated: ORACLE ODBC ver 8.01.55.00 can't make subselects and funcition odbc_exec
ID: 5595 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: ODBC related Assigned To: Comments: Previous Comments: --- [2000-09-05 03:05:38] [EMAIL PROTECTED] User reported problem still exist with latest CVs. --Jani --- [2000-09-04 20:48:36] [EMAIL PROTECTED] Is this still happening with php4.0.2 ? --Jani --- [2000-07-14 18:18:52] [EMAIL PROTECTED] If You use subselects and odbc_exec functions the browser hangs, and no answer is sended by the server. You have to use odbc_prepare/odbc_execute instead of. Problably something wrong with odbc_exec function. This bug affects all php4x versions --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5595edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9878 Updated: gmmktime is 1 hour off during standard time
ID: 9878
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Date/time related
Description: gmmktime is 1 hour off during standard time
I know there are a lot of open bugs and this one is probably pretty small compared to
most, but the time window to
easily verify this bug and my suggested fix is quickly going
away for 6 months. With the time shift this weekend, it
wil be much more difficult to reproduce this bug, unless you
start subtracting 86400 seconds per day to get back into standard time.
If someone could just look at what I've provided I think
it will be a no-brainer. Even if it doesn't get tagged into
the new release, at least it will saved for the next.
Thanks
Previous Comments:
---
[2001-03-20 14:08:09] [EMAIL PROTECTED]
gmmktime is producing a timestamp 1 hour off when the timezone is standard time. If
you compare a
time() with gmmktime with current settings and a is_dst
value NULL, the results will be one hour off.
I used the following little script to prove this:
?
print ("PRE");
print ("Time function = ".time ());
print ("n");
print ("gmmktime = ".gmmktime (18,25,0,3,20,2001));
print ("n");
print ("mktime = ".mktime(12,25,0,3,20,2001));
print ("n");
print (gmmktime(7,0,0,4,1,2001)." ".mktime(1,0,0,4,1,2001)."n");
print (gmmktime(8,0,0,4,1,2001)." ".mktime(3,0,0,4,1,2001)."n");
?
Currently, the US/Central timezone is -6 hours from GMT.
I believe the problem is in ext/standard/datetime.c, line
186. Judging from the code, "timezone" seems to be a negative seconds value from GMT,
probably of the standard timezone (TZ in standard). So if is_dst == 0, you don't want
to add anything more. I think the like should say:
gmadjust = -(is_dst ? timezone - 3600 : timezone );
And the comment about overcorrecting removed.
My test script works if this line is changed.
---
Full Bug description available at: http://bugs.php.net/?id=9878
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #5594 Updated: Can't connect ORACLE using ORACLE ODBC ver 8.01.55.00
ID: 5594 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Assigned To: Comments: has this been addressed in any of the recent releases since you've last submitted information on this bug? Previous Comments: --- [2000-09-13 18:24:07] [EMAIL PROTECTED] User feedback: - The filename is oraodbc.ini Probably oracle odbc installer changed something in win2k environment and this bug appears. --- --- [2000-09-13 06:58:40] [EMAIL PROTECTED] User feedback 5.9.2000 : -- To be honest this bug is real, but the solution changes sometimes. The first time I saw it I changed blob option and it started to work, last time it happened I renamed one Ora* (something) file on winnt and them de odbc driver started to work. I'll check the file name and e-mail you again. -- Haven't got any mail from you yet.. --Jani --- [2000-09-04 20:49:05] [EMAIL PROTECTED] Is this still happening with php4.0.2 ? --Jani --- [2000-07-14 18:13:29] [EMAIL PROTECTED] You have to disable LOB on ODBC administrator do avoid this crash This bug affects all php4x versions --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5594edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #5594 Updated: Can't connect ORACLE using ORACLE ODBC ver 8.01.55.00
ID: 5594 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: ODBC related Assigned To: Comments: has this been addressed in any of the recent releases since you've last submitted information on this bug? Previous Comments: --- [2001-03-30 10:14:35] [EMAIL PROTECTED] has this been addressed in any of the recent releases since you've last submitted information on this bug? --- [2000-09-13 18:24:07] [EMAIL PROTECTED] User feedback: - The filename is oraodbc.ini Probably oracle odbc installer changed something in win2k environment and this bug appears. --- --- [2000-09-13 06:58:40] [EMAIL PROTECTED] User feedback 5.9.2000 : -- To be honest this bug is real, but the solution changes sometimes. The first time I saw it I changed blob option and it started to work, last time it happened I renamed one Ora* (something) file on winnt and them de odbc driver started to work. I'll check the file name and e-mail you again. -- Haven't got any mail from you yet.. --Jani --- [2000-09-04 20:49:05] [EMAIL PROTECTED] Is this still happening with php4.0.2 ? --Jani --- [2000-07-14 18:13:29] [EMAIL PROTECTED] You have to disable LOB on ODBC administrator do avoid this crash This bug affects all php4x versions --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5594edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PHP 4.0 Bug #5595 Updated: ORACLE ODBC ver 8.01.55.00 can't make subselects and funcition odbc_exec
Hi, Unfortunately I finished this job using OCI8 connections and I can't test this enviroment anymore. Regards Helio Silva At 15:11 30/03/01 +, you wrote: ID: 5595 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: ODBC related Assigned To: Comments: Previous Comments: --- [2000-09-05 03:05:38] [EMAIL PROTECTED] User reported problem still exist with latest CVs. --Jani --- [2000-09-04 20:48:36] [EMAIL PROTECTED] Is this still happening with php4.0.2 ? --Jani --- [2000-07-14 18:18:52] [EMAIL PROTECTED] If You use subselects and odbc_exec functions the browser hangs, and no answer is sended by the server. You have to use odbc_prepare/odbc_execute instead of. Problably something wrong with odbc_exec function. This bug affects all php4x versions --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5595edit=2 Abrao, Hlio S. Silva Iggy Tecnologia e Informao S/C Ltda. Uso Linux : http://www2.uol.com.br/info/aberto/linux Sao Paulo,SP - BRASIL [EMAIL PROTECTED] Tel +55 11 -2889 / 3936-4521/3032 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #7273 Updated: odbc_connect causes a segmentation fault
ID: 7273
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: ODBC related
Assigned To:
Comments:
is this still occuring in a recent release?
Previous Comments:
---
[2000-10-17 06:24:52] [EMAIL PROTECTED]
$conn=odbc_connect("DSN=database;UID=user;PWD=passwd","","");
if (!$conn)
{ echo "NO DATABASE!"; exit; }
When the database is down (or the user is wrong, or anything else is wrong)
odbc_connect causes a segmentation fault.
./configure --with-mysql=no --with-openlink --with-apache=../apache_1.3.12
--enable-track-vars
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7273edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PHP 4.0 Bug #5594 Updated: Can't connect ORACLE using ORACLE ODBC ver 8.01.55.00
No At 15:14 30/03/01 +, you wrote: ID: 5594 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Status: Open Bug Type: ODBC related Assigned To: Comments: has this been addressed in any of the recent releases since you've last submitted information on this bug? Previous Comments: --- [2000-09-13 18:24:07] [EMAIL PROTECTED] User feedback: - The filename is oraodbc.ini Probably oracle odbc installer changed something in win2k environment and this bug appears. --- --- [2000-09-13 06:58:40] [EMAIL PROTECTED] User feedback 5.9.2000 : -- To be honest this bug is real, but the solution changes sometimes. The first time I saw it I changed blob option and it started to work, last time it happened I renamed one Ora* (something) file on winnt and them de odbc driver started to work. I'll check the file name and e-mail you again. -- Haven't got any mail from you yet.. --Jani --- [2000-09-04 20:49:05] [EMAIL PROTECTED] Is this still happening with php4.0.2 ? --Jani --- [2000-07-14 18:13:29] [EMAIL PROTECTED] You have to disable LOB on ODBC administrator do avoid this crash This bug affects all php4x versions --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5594edit=2 Abrao, Hlio S. Silva Iggy Tecnologia e Informao S/C Ltda. Uso Linux : http://www2.uol.com.br/info/aberto/linux Sao Paulo,SP - BRASIL [EMAIL PROTECTED] Tel +55 11 -2889 / 3936-4521/3032 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #5595 Updated: ORACLE ODBC ver 8.01.55.00 can't make subselects and funcition odbc_exec
ID: 5595 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: ODBC related Assigned To: Comments: user feedback: Hi, Unfortunately I finished this job using OCI8 connections and I can't test this enviroment anymore. Regards Helio Silva Previous Comments: --- [2001-03-23 17:02:28] [EMAIL PROTECTED] and again, is this still occuring in the latest CVS? --- [2000-09-05 03:05:38] [EMAIL PROTECTED] User reported problem still exist with latest CVs. --Jani --- [2000-09-04 20:48:36] [EMAIL PROTECTED] Is this still happening with php4.0.2 ? --Jani --- [2000-07-14 18:18:52] [EMAIL PROTECTED] If You use subselects and odbc_exec functions the browser hangs, and no answer is sended by the server. You have to use odbc_prepare/odbc_execute instead of. Problably something wrong with odbc_exec function. This bug affects all php4x versions --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5595edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #5594 Updated: Can't connect ORACLE using ORACLE ODBC ver 8.01.55.00
ID: 5594 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: ODBC related Assigned To: Comments: user feedback: No Previous Comments: --- [2001-03-30 10:14:48] [EMAIL PROTECTED] has this been addressed in any of the recent releases since you've last submitted information on this bug? --- [2001-03-30 10:14:35] [EMAIL PROTECTED] has this been addressed in any of the recent releases since you've last submitted information on this bug? --- [2000-09-13 18:24:07] [EMAIL PROTECTED] User feedback: - The filename is oraodbc.ini Probably oracle odbc installer changed something in win2k environment and this bug appears. --- --- [2000-09-13 06:58:40] [EMAIL PROTECTED] User feedback 5.9.2000 : -- To be honest this bug is real, but the solution changes sometimes. The first time I saw it I changed blob option and it started to work, last time it happened I renamed one Ora* (something) file on winnt and them de odbc driver started to work. I'll check the file name and e-mail you again. -- Haven't got any mail from you yet.. --Jani --- [2000-09-04 20:49:05] [EMAIL PROTECTED] Is this still happening with php4.0.2 ? --Jani --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5594edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: PHP 4.0 Bug #5594 Updated: Can't connect ORACLE using ORACLE ODBC ver 8.01.55.00
I finished this job using OCI8 Connection and I can't test ODBC connections anymore Sorrry Helio Silva At 15:14 30/03/01 +, you wrote: ID: 5594 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: ODBC related Assigned To: Comments: has this been addressed in any of the recent releases since you've last submitted information on this bug? Previous Comments: --- [2001-03-30 10:14:35] [EMAIL PROTECTED] has this been addressed in any of the recent releases since you've last submitted information on this bug? --- [2000-09-13 18:24:07] [EMAIL PROTECTED] User feedback: - The filename is oraodbc.ini Probably oracle odbc installer changed something in win2k environment and this bug appears. --- --- [2000-09-13 06:58:40] [EMAIL PROTECTED] User feedback 5.9.2000 : -- To be honest this bug is real, but the solution changes sometimes. The first time I saw it I changed blob option and it started to work, last time it happened I renamed one Ora* (something) file on winnt and them de odbc driver started to work. I'll check the file name and e-mail you again. -- Haven't got any mail from you yet.. --Jani --- [2000-09-04 20:49:05] [EMAIL PROTECTED] Is this still happening with php4.0.2 ? --Jani --- [2000-07-14 18:13:29] [EMAIL PROTECTED] You have to disable LOB on ODBC administrator do avoid this crash This bug affects all php4x versions --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5594edit=2 Abrao, Hlio S. Silva Iggy Tecnologia e Informao S/C Ltda. Uso Linux : http://www2.uol.com.br/info/aberto/linux Sao Paulo,SP - BRASIL [EMAIL PROTECTED] Tel +55 11 -2889 / 3936-4521/3032 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10076: NULL entry calling
From: [EMAIL PROTECTED]
Operating system: Windows 2000
PHP version: 4.0 Latest CVS (30/03/2001)
PHP Bug Type: Reproduceable crash
Bug description: NULL entry calling
File output.c
No checks whether it is possible to call this php_body_write or not. During shutdown
of server calling from oci_debug( ... ) causes crash on the Win32 system by coalling
NULL entry.
PHPAPI int php_body_write(const char *str, uint str_length)
{
OLS_FETCH();
return OG(php_body_write)(str, str_length);
}
sugest to change it to:
if( OG(php_body_write) )
{
return OG(php_body_write)(str, str_length);
}
return 0;
--
Edit Bug report at: http://bugs.php.net/?id=10076edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10069 Updated: fread() / fputs() error with apache modules
ID: 10069 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Filesystem function related Assigned To: Comments: add the letter 'b' to your fopen argument string to enforce binary mode on DOS-based systems (it doesn't harm on unix systems) Previous Comments: --- [2001-03-29 21:13:09] [EMAIL PROTECTED] When I run PHP 4.0.4pl1 as apache module on my Windows 2000 ADV Server, I got the problem. When I fread() from a binary file, or fputs() a binary string to a file, the file not same as my data. The "0x0a" expanded to "0x0d0a", I don't know why. I try it by CGI PHP and PHP command line on same system, them ok. My PHP 4.0.4pl1 Win32 Binary was download from www.php.net. php.ini just changed some from php.ini-dist: short_open_tag = off max_execution_time = 120 session.cache_limiter =private --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10069edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #5594 Updated: Can't connect ORACLE using ORACLE ODBC ver 8.01.55.00
ID: 5594 Updated by: kalowsky Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: ODBC related Assigned To: Comments: User feedback: I finished this job using OCI8 Connection and I can't test ODBC connections anymore Sorrry Helio Silva Previous Comments: --- [2001-03-30 10:19:36] [EMAIL PROTECTED] user feedback: No --- [2001-03-30 10:14:48] [EMAIL PROTECTED] has this been addressed in any of the recent releases since you've last submitted information on this bug? --- [2001-03-30 10:14:35] [EMAIL PROTECTED] has this been addressed in any of the recent releases since you've last submitted information on this bug? --- [2000-09-13 18:24:07] [EMAIL PROTECTED] User feedback: - The filename is oraodbc.ini Probably oracle odbc installer changed something in win2k environment and this bug appears. --- --- [2000-09-13 06:58:40] [EMAIL PROTECTED] User feedback 5.9.2000 : -- To be honest this bug is real, but the solution changes sometimes. The first time I saw it I changed blob option and it started to work, last time it happened I renamed one Ora* (something) file on winnt and them de odbc driver started to work. I'll check the file name and e-mail you again. -- Haven't got any mail from you yet.. --Jani --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5594edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10077: after installing php-4.0.0, get error message undefined symbol: mysql_init
From: [EMAIL PROTECTED] Operating system: Linux Mandrake 7.0 PHP version: 4.0.0 PHP Bug Type: Apache related Bug description: after installing php-4.0.0, get error message "undefined symbol: mysql_init" Syntax error on line 207 of /usr/local/apache_1.3.12/conf/httpd.conf Cannot load /usr/local/apache_1.3.12/libexec/libphp4.so into server: /usr/local/apache_1.3.12/libexec/libphp4.so: undefined symbol: mysql_init ./bin/apachectl start: httpd cound not be started both apache and mysql functioned properly prior to compile of php-4.0.0 and both will function fine if I comment out line 207. However, php files won't run in my browser from localhost but will run from file located on isp, (same file copied from local to server will run). This makes off line development difficult. Any assistance would be greatly appreciated. -- Edit Bug report at: http://bugs.php.net/?id=10077edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10077 Updated: after installing php-4.0.0, get error message undefined symbol: mysql_init
ID: 10077 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Apache related Assigned To: Comments: first: why are you using the rather outdated 4.0.0 release? second: what does your configure line look like? Previous Comments: --- [2001-03-30 10:58:31] [EMAIL PROTECTED] Syntax error on line 207 of /usr/local/apache_1.3.12/conf/httpd.conf Cannot load /usr/local/apache_1.3.12/libexec/libphp4.so into server: /usr/local/apache_1.3.12/libexec/libphp4.so: undefined symbol: mysql_init ./bin/apachectl start: httpd cound not be started both apache and mysql functioned properly prior to compile of php-4.0.0 and both will function fine if I comment out line 207. However, php files won't run in my browser from localhost but will run from file located on isp, (same file copied from local to server will run). This makes off line development difficult. Any assistance would be greatly appreciated. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10077edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10078: Problems with ImageCreate function
From: [EMAIL PROTECTED] Operating system: Windows 98\' PHP version: 4.0.4pl1 PHP Bug Type: GD related Bug description: Problems with ImageCreate function When I tried to use ImageCreate and other GD functions in PHP, it happend to be not functioning correct: ImageCreate failed to return image descriptor, instead it returned undefined value. How can I fix this problem? Please reply my letter as soon as you can. My e-mail address is [EMAIL PROTECTED] Thanks! -- Edit Bug report at: http://bugs.php.net/?id=10078edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #7339 Updated: ODBC with Oracle and Apache, Server rejected the connection
ID: 7339
Updated by: kalowsky
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: ODBC related
Assigned To:
Comments:
this sounds more like a misconfiguration in the Oracle server rather than in PHP.
Please check that your Oracle installation is properly setup.
And then the that the user and password are correct.
Previous Comments:
---
[2000-10-19 08:37:44] [EMAIL PROTECTED]
Hello,
Using PHP3 and connecting to Oracle via ODBC everything works fine but using exactly
the same script with PHP4.0.3pl1 I receive this "SQL error: [Oracle][ODBC][Ora]Server
rejected the connection., SQL state 08004 in SQLConnect".
The scrip is really easy, here it is:
?php
if (!($conn=odbc_connect ("ORACLEQP", "scott", "tiger")))
echo "Error";
else
echo "OK";
?
Obviously "ORACLEQP" is my Sysytem DSN. The server machine is different from the Web
Server running apache and PHP.
Any hint would be very appreciated cause right now to workaround to the problem I am
using both PHP3 and PHP4.
(I need PHP4 because I am trying to use GD library)
Thanks
Andrea
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7339edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10079: Header Function Within IF construct
From: [EMAIL PROTECTED]
Operating system: SCO OpenServer 5.0.5
PHP version: 4.0.4pl1
PHP Bug Type: Scripting Engine problem
Bug description: Header Function Within IF construct
?php
// Header("WWW-Authenticate: Basic realm=\"Realm\"");
if (!$PHP_AUTH_USER) {
exec("");
Header("WWW-Authenticate: Basic realm=\"Realm\"");
Header("HTTP/1.0 401 Unauthorized");
} else
echo "else";
?
Compiler: gcc 2.95.2
Make: GNU 3.79
FSU Pthreads: 3.8
Apache: 1.3.19
MySQL: 3.23.36
PHP: 4.0.4pl1
Freetype: 2.0
LibPNG: 1.0.9
LibJPEG: 6b
Libgd: 1.8.4
PHP is compiled as an Apache module with the following options:
--with-mysql --with-apache --with-pdflib --with-gd --with-trans-sid
--enable-track-vars --enable-sysvsem --enable-sysvshm
Description of problem:
Both sides of the IF construct are being executed when testing the $PHP_AUTH_USER
variable AND issuing the header function. I posted this question in the general mail
list but have received any reponse from anyoneso
Using the script list above, follow the steps shown below to produce this problem:
1. Close all instances of your browser (I am using IE-5.01 and I have not tried any
other browsers). However I don't believe it is a browser issue.
2. Run the script shown above.
3. Enter some user ID and password... Everything so far works fine.
4. Look in the directory where the script is stored. There should be a file called
. This indicates that $PHP_AUTH_USER was NOT set.
5. Remove the file .
6. Refresh the browser. Look for the file . Notice that is present; which
should only happen if $PHP_AUTH_USER is NOT setYET "else" was printed on screen
which indicates that $PHP_AUTH_USER IS set.
7. Uncomment the commented "header" line and notice that a user ID and password prompt
is always issued in this case.
My questions are:
1. Why are both sides of the conditional "If (!isset($PHP_AUTH_USER))" being executed?
2. Why, when $PHP_AUTH_USER is not set, the 'exec("")' runs on subsequent
refreshes, but no prompt for a new user ID and password is issued?
3. Why, if a authenticate header is sent before testing, a user ID and password prompt
is issued?
Thanks for taking a look at this.
Dean
--
Edit Bug report at: http://bugs.php.net/?id=10079edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0.5 Release Midgard Problems
Sorry to bring this up yet again but before we release 4.0.5 this needs to be sorted otherwise nothing will ever happen. We have just reached 4.0.5RC4 (which was the final planned RC) and we find that the midgard folks need to fix some bugs with the build process. This will undoubtedly happen again and again ad midgard and PHP work on different release cycles and is by no means the fault of the midgard people but it just isn't practical if we are trying to release stable versions of PHP and midgard is still undergoing heavy development. Sascha complains about the stability of PHP and all of our patch levels yet Rasmus wants to include these extensions that are applications in their own right, it just isn't practical for the QA team to test something the size of midgard and thus it doesn't get tested (unless the midgard folks test it which we have to presume doesn't happen as we get no feedback from them), we then risk getting to a point like this where we are about to release PHP 4.0.5 and it either 1) has to be delayed with another release cycle 2) has to continue with a broken midgarad, neither are great but for the QA team its very annoying when midgard, somewhat of an outside extension means we have to do a whole new cycle. I propose that we remove midgard from the PHP CVS into a separate PEARC module before the release of 4.0.5 so that midgard is never been included in a PHP release. It will give some incentive to get the PEARC system running sooner too. If nobody objects to this strongly I propose we do this in 24-48 hours and then release 4.0.5 which has been dragging on for a while now. James -- James Moore [EMAIL PROTECTED] PHP Web Scripting: http://www.php.net/ PHP QA Team: http://qa.php.net/ PHP-GTK: http://gtk.php.net/ VL-SRM: http://www.vl-srm.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10070 Updated: incorrect ob_gzhandler implementation
ID: 10070 Updated by: avsm Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Analyzed Bug Type: Zlib Related Assigned To: Comments: Applied a patch to add Vary: headers if we add a Content-Encoding: header. Regarding the browser compatibility with Deflate, I think we should just leave it like it is. _They_ break the RFC; encourage people to upgrade to modern, non-broken browsers instead ? Previous Comments: --- [2001-03-29 21:21:53] [EMAIL PROTECTED] ob_gzhandler doesn't appear to set a Vary: header on responses, which means that proxy caches could store a compressed version of the resource and serve it to clients which can't handle the encoding. This is very difficult to debug for Web sites, and should be fixed ASAP. For an example of the proper headers to send, see the PHP at: http://www.mnot.net/cgi_buffer/ Also, in my experience, some versions of MSIE don't handle deflate compession correctly, even though their Accept-Encoding claims they do. It might be better to avoid deflate altogether, as gzip support is pretty much the unwritten standard. Cheers, --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10070edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
James Moore wrote: This will undoubtedly happen again and again ad midgard and PHP work on different release cycles and is by no means the fault of the midgard people but it just isn't practical if we are trying to release stable versions of PHP and midgard is still undergoing heavy development. True, but in this case the main issue is a problem in the autoconf system. I propose that we remove midgard from the PHP CVS into a separate PEARC module before the release of 4.0.5 so that midgard is never been included in a PHP release. It will give some incentive to get the PEARC system running sooner too. If nobody objects to this strongly I propose we do this in 24-48 hours and then release 4.0.5 which has been dragging on for a while now. Doesn't have my preference, of course, but if that's the general feel on php-dev then that's what needs to happen. Emile -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
James Moore wrote: Sascha complains about the stability of PHP and all of our patch And I think he is right about this. I propose that we remove midgard from the PHP CVS into a separate PEARC module Stig created such a module, called PEAR (who would've thought of that? *g*), some days ago. Currently it contains the C implementation of PEAR's base class. before the release of 4.0.5 so that midgard is never been included in a PHP release. +1 -- sebastian bergmann[EMAIL PROTECTED] http://www.sebastian-bergmann.de bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Question about socket ext. file descriptors
On Thu, 29 Mar 2001, Lars Torben Wilson wrote: Zeev Suraski writes: Note that the situation isn't as bad as you thought - it's not that it's not using the resource mechanism. It is, if it wasn't, we'd be getting loads of complaints from people running out of descriptors very quickly. It just uses old, PHP 3 style resources, of type IS_LONG. They're still destroyed when the request ends, so it's all safe and all. It simply doesn't use the PHP 4 style, of type IS_RESOURCE, which are actually destroyed when they're no longer needed. It's a good idea to update this code, but it's not very dangerous the way it is now. This doesn't look like what I remember from PHP...for instance, send() definitely isn't using any form of resources. Lars - apparently you got it wrong; The integers you are getting are *not* file descriptors. They're resource handles, of type IS_LONG. They might accidentally correspond to the file descriptors, but it'd be complete coincidence. In short, regardless of whether we upgrade the file functions to use IS_RESOURCE resources or not, what they return cannot be relied upon as file descriptor numbers, simply because they're not. I hope that clears it up... Zeev I hate to argue with you :) but this sure looks like it's passing back the descriptor (I could be missing something so if I am just shoot me): snip Nope, you aren't missing anything. The extension, I admit, is breaking some rules -- negative values instead of false for return values for example. OTOH, it *is* perfectly possible, for example, that socket() might return 0, which evaluates to false and is yet a valid file descriptor. The reason for returning file descriptors instead of resources was primarily select(). One thing I was considering doing was writing a file descriptor table (an fd_set perhaps) that keeps track of the open file descriptors, and at the end of the request (PHP_RSHUTDOWN...) closes all of the open sockets. I'm currently updating my CVS tree so I can update the current source with something to make sure that stuff opened here is closed at the end of it. For this, I'm not too fond of going the resource route for it, simply because I know people are more familiar with the C interfaces to socket() and friends (I know I'm not alone in this, but if I seem to be, feel free to speak up now).. so it makes the interfaces more familiar to people who would want to use it (and since I tried to keep the interfaces as similar as possible, it also means that people don't have to go running to the manual for everything except for the few oddities .. 'man socket' will tell you all you need to know about socket() on any decent *nix system.) I'm attempting to compile my fix for it now, will commit soon if compile goes well. Chris -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
IMHO, this sounds like its best for everyone, *especially* the end users of midgard and php. -Jason - Original Message - From: "James Moore" [EMAIL PROTECTED] To: "[EMAIL PROTECTED]" [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, March 30, 2001 12:02 PM Subject: [PHP-DEV] PHP 4.0.5 Release Midgard Problems Sorry to bring this up yet again but before we release 4.0.5 this needs to be sorted otherwise nothing will ever happen. We have just reached 4.0.5RC4 (which was the final planned RC) and we find that the midgard folks need to fix some bugs with the build process. This will undoubtedly happen again and again ad midgard and PHP work on different release cycles and is by no means the fault of the midgard people but it just isn't practical if we are trying to release stable versions of PHP and midgard is still undergoing heavy development. Sascha complains about the stability of PHP and all of our patch levels yet Rasmus wants to include these extensions that are applications in their own right, it just isn't practical for the QA team to test something the size of midgard and thus it doesn't get tested (unless the midgard folks test it which we have to presume doesn't happen as we get no feedback from them), we then risk getting to a point like this where we are about to release PHP 4.0.5 and it either 1) has to be delayed with another release cycle 2) has to continue with a broken midgarad, neither are great but for the QA team its very annoying when midgard, somewhat of an outside extension means we have to do a whole new cycle. I propose that we remove midgard from the PHP CVS into a separate PEARC module before the release of 4.0.5 so that midgard is never been included in a PHP release. It will give some incentive to get the PEARC system running sooner too. If nobody objects to this strongly I propose we do this in 24-48 hours and then release 4.0.5 which has been dragging on for a while now. James -- James Moore [EMAIL PROTECTED] PHP Web Scripting: http://www.php.net/ PHP QA Team: http://qa.php.net/ PHP-GTK: http://gtk.php.net/ VL-SRM: http://www.vl-srm.net/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
On Fri, 30 Mar 2001, James Moore wrote: Sorry to bring this up yet again but before we release 4.0.5 this needs to be sorted otherwise nothing will ever happen. We have just reached 4.0.5RC4 (which was the final planned RC) and we find that the midgard folks need to fix some bugs with the build process. This will undoubtedly happen again and again ad midgard and PHP work on different release cycles and is by no means the fault of the midgard people but it just isn't practical if we are trying to release stable versions of PHP and midgard is still undergoing heavy development. Sascha complains about the stability of PHP and all of our patch levels yet Rasmus wants to include these extensions that are applications in their own right, it just isn't practical for the QA team to test something the size of midgard and thus it doesn't get tested (unless the midgard folks test it which we have to presume doesn't happen as we get no feedback from them), we then risk getting to a point like this where we are about to release PHP 4.0.5 and it either 1) has to be delayed with another release cycle 2) has to continue with a broken midgarad, neither are great but for the QA team its very annoying when midgard, somewhat of an outside extension means we have to do a whole new cycle. I propose that we remove midgard from the PHP CVS into a separate PEARC module before the release of 4.0.5 so that midgard is never been included in a PHP release. It will give some incentive to get the PEARC system running sooner too. If nobody objects to this strongly I propose we do this in 24-48 hours and then release 4.0.5 which has been dragging on for a while now. Um... If I'm not mistaken, the midgaurd extension itself, only provides functionality to the "midguard" application? Ie, end-users of midguard will not use the functions and classes exported by the extension, only midguard will use that functionality? If so, I'm not too sure it would be a good idea to include the midguard extension in PEAR either... -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
Um... If I'm not mistaken, the midgaurd extension itself, only provides functionality to the "midguard" application? Ie, end-users of midguard will not use the functions and classes exported by the extension, only midguard will use that functionality? If so, I'm not too sure it would be a good idea to include the midguard extension in PEAR either... There is nothing stopping someone else making a php app that uses midguard extension if they want to. I can see your point but if there is a feeling that it should be distributed with PHP in someway PEAR seems the most logical place. By your arugment why should midguard be in ext/ either as noone but people running midgard use it. PEAR is somewhere where it would be easy to retive from (eventually) and is hopefully where we will eventually have other non standard extensions. James -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10080: can't call the function sybase_affected_rows() for insert, update and delete
From: [EMAIL PROTECTED]
Operating system: windows NT
PHP version: 4.0.4pl1
PHP Bug Type: Sybase (dblib) related
Bug description: can't call the function sybase_affected_rows() for insert, update
and delete
Hello Sirs.
When I use sybase_affected_rows() fucntion for our project, the function call failed.
Following is the code snippet:
$query = "insert into form_form values('company', 'lingqin', 'file',
'[EMAIL PROTECTED]', 'subject')";
$conn = sybase_connect($server, $user, $pass);
sybase_select_db($dbname, $conn);
$result = sybase_query($query, $conn);
$rows = sybase_affected_rows($result);
When I run the above script, I got the following error:
Fatal error: Call to undefined function: sybase_affected_rows() in
/webdev/skmtest/rw/docroot/sybtest.phtml on
line 9
But, the PHP manul tells me the above function can be used by PHP 3= 3.0.6, PHP 4
We are using PHP Version 4.0.4pl1.
Please let me know what's the problem.
Thanks a lot.
Ling Zhang
--
Edit Bug report at: http://bugs.php.net/?id=10080edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
RE: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
On Fri, 30 Mar 2001, James Moore wrote: Um... If I'm not mistaken, the midgaurd extension itself, only provides functionality to the "midguard" application? Ie, end-users of midguard will not use the functions and classes exported by the extension, only midguard will use that functionality? If so, I'm not too sure it would be a good idea to include the midguard extension in PEAR either... There is nothing stopping someone else making a php app that uses midguard extension if they want to. Right, but from what I understand the functions only make sense for the midguard application. I can see your point but if there is a feeling that it should be distributed with PHP in someway PEAR seems the most logical place. By your arugment why should midguard be in ext/ either as noone but people running midgard use it. PEAR is somewhere where it would be easy to retive from (eventually) and is hopefully where we will eventually have other non standard extensions. Yes, and no offense intended, I don't see why the midguard people don't just distribute the extension *with* midguard. I could see some sense in distributing it with PHP, because then users of midguard really didn't have to worry about compiling twice, etc, its already built-in to php. While I'm not for that idea (it adds 70k of bloat), I don't see the point in distributing it with PEAR. When you distribute it with pear there is no advantage for the midguard people (or anyone) that I can see (or advantage greater than just distributing the midguard extension with midguard itself). -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10081: Session does not save and restore values when register_globals set to On
From: [EMAIL PROTECTED] Operating system: Windows 98 SE PHP version: 4.0.4pl1 PHP Bug Type: *Session related Bug description: Session does not save and restore values when register_globals set to On I have few pages that work with session functions. If I have register_globals set to Off, everithing works fine. When I set register globals to On, saving and restoring of session values does not work. I am using always $HTTP_SESSION_VARS variable. -- Edit Bug report at: http://bugs.php.net/?id=10081edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10067 Updated: zlib not included when compiled with apache
ID: 10067
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Compile Problem
Assigned To:
Comments:
Could you please try the latest CVS snapshot from http://snaps.php.net/ as this should
be fixed.
--Jani
Previous Comments:
---
[2001-03-29 19:48:35] [EMAIL PROTECTED]
Just a note on what's in the libmysqlclient.la file; the dependency_libs= line has
-lz -lcrypt -lgen -lsocket -lnsl -lm
I'm puzzled as to why php apparently isn't using this .la file.
---
[2001-03-29 18:25:50] [EMAIL PROTECTED]
When I initially compile apache I'm configuring it with:
CFLAGS="-O2 -pipe" ; export CFLAGS
PATH=/usr/local/bin:${PATH} ; export PATH
configure
--prefix=/wmf/apache
--enable-module=so
--enable-module=most
--disable-shared=all
--disable-module=autoindex
--disable-module=cern_meta
--disable-module=proxy
--disable-module=speling
--disable-module=unique_id
--disable-module=usertrack
--disable-module=userdir
When I configure php I'm using:
PATH=/usr/local/bin:${PATH} ; export PATH
CFLAGS="-O2 -pipe" ; export CFLAGS
EXTRA_LIBS=-L/usr/local/lib ; export EXTRA_LIBS
configure
--prefix=/wmf/apache
--with-apache=/wmf/src/apache_1.3.19
--with-config-file-path=/wmf/apache/conf
--with-xml
--enable-wddx
--enable-track-vars
--enable-trans-sid
--enable-inline-optimization
--disable-pear
--disable-posix-threads
--disable-shared
--enable-static
--with-oci8=/wmf/oracle/oracle8i_r3v5
--with-mysql=/wmf/mysql
--with-ldap=/usr/local
--enable-libgcc
And the final configure of apache is
CFLAGS="-O2 -pipe" ; export CFLAGS
PATH=/usr/local/bin:${PATH} ; export PATH
sh configure
--prefix=/wmf/apache
--enable-module=so
--enable-module=most
--disable-shared=all
--disable-module=autoindex
--disable-module=cern_meta
--disable-module=proxy
--disable-module=speling
--disable-module=unique_id
--disable-module=usertrack
--disable-module=userdir
--activate-module=src/modules/php4/libphp4.a
---
[2001-03-29 18:21:08] [EMAIL PROTECTED]
Apache-1.3.19, mysql-3.23.36, php-4.0.4pl1
Everything compiles ok until I get to the final apache compile and then it bombs on
missing symbols compress and uncompress. They are used in libmysqlclient.a and the
code for them is in /lib/libz.a but the final compile of apache doesn't have -lz.
When I add that then it compiles. I'm linking static, not dso.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10067edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9886 Updated: Installation on w2k
ID: 9886 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: *General Issues Assigned To: Comments: User reported problem solved in CVS build. --Jani Previous Comments: --- [2001-03-29 12:01:23] [EMAIL PROTECTED] Could you please try the latest CVS build from http://www.php4win.de/ to check if this is fixed now? --Jani --- [2001-03-20 21:52:18] [EMAIL PROTECTED] I have just installed PHP 4.0.4pl1 on w2k SP1 using CGI. I have setup the extension_dir to the directory where the extension dll are. It alway give the error " unable to load dynamic library 'd:phpextensionsphp_curl.dll' - specified module could not be found". I have also set full path in the "extension=" directive, it did not too. What have I missed To me it seems that this is a bug. I have checked, the files are there, the path are correct, permissions are set but it just continue to give the error. I have visited the newsgroup and it seems to be a common problem but no one has a solution to this, Please help. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9886edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10072 Updated: SIGSEGV on startup (apxs)
ID: 10072
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Reproduceable crash
Assigned To:
Comments:
1. Delete config.cache
2. Add --enable-debug into your configure line
3. Configure and compile and try regenerating that gdb backtrace.
And do not use the source dirs in any other configure
option of PHP than --with-apache. You should be using the
INSTALL base dirs.
--Jani
Previous Comments:
---
[2001-03-29 23:40:15] [EMAIL PROTECTED]
OS version:
SunOS ptl2 5.7 Generic sun4u sparc SUNW,Ultra-5_10
Apache 1.3.19+mod_ssl-2.8.1 configure line:
EAPI_MM=../mm-1.1.3 SSL_BASE=../openssl-0.9.6 ./configure --prefix=/usr/local/apache
--enable-module=ssl --enable-module=so --enable-module=rewrite
PHP 4.0.4pl1 configure line:
./configure --with-apxs --with-mcrypt --with-mhash --with-mysql=../../mysql --with-gd
--enable-versioning --with-ttf --with-jpeg-dir=../jpeg-6b --enable-debug
If the LoadModule libphp4.so is removed from httpd.conf, Apache operates correctly.
Otherwise, there is a SIGSEGV as httpd starts up. Following is a GDB backtrace and
partial truss output. Full truss output can be found at
http://wolf.project-w.com/notes/20010330.phpsegv.txt
---
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.7"...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
warning: Lowest section in /usr/lib/libintl.so.1 is .hash at 0074
Program received signal SIGSEGV, Segmentation fault.
0xff3b8894 in ?? ()
(gdb) bt
#0 0xff3b8894 in ?? ()
#1 0xff3b35a0 in ?? ()
#2 0xff3b37e8 in ?? ()
#3 0xff3bd154 in ?? ()
#4 0xb7764 in ap_os_dso_load ()
#5 0x83a70 in load_module ()
#6 0x8d550 in invoke_cmd ()
#7 0x8e3c0 in ap_handle_command ()
#8 0x8e49c in ap_srm_command_loop ()
#9 0x8ee84 in ap_process_resource_config ()
#10 0x8facc in ap_read_config ()
#11 0x9e7bc in main ()
(gdb)
---
...
stat("/usr/local/apache", 0xFFBED7C8) = 0
open("/usr/local/apache/libexec/libphp4.so", O_RDONLY) = 5
fstat(5, 0xFFBED614)= 0
mmap(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xFF34
mmap(0x, 2187264, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xFED8
munmap(0xFEF46000, 57344) = 0
mmap(0xFEF54000, 182128, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5,
1851392) = 0xFEF54000
...
mprotect(0xFED8, 1854910, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0xFED8, 1854910, PROT_READ|PROT_EXEC) = 0
munmap(0xFEF54000, 265928) = 0
munmap(0xFED8, 1854910) = 0
Incurred fault #6, FLTBOUNDS %pc = 0xFF3B8894
siginfo: SIGSEGV SEGV_ACCERR addr=0xFF3CABD4
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_ACCERR addr=0xFF3CABD4
*** process killed ***
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10072edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: PHP 4.0 Bug #10079 Updated: Header Function Within IF construct
Apache is running standalone as a daemon. But even so, why would both sides
of the IF statement run?
Did you try this and get the same results?
Dean
-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: Friday, March 30, 2001 11:35 AM
To: [EMAIL PROTECTED]
Subject: PHP 4.0 Bug #10079 Updated: Header Function Within IF construct
ID: 10079
Updated by: cnewbill
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Assigned To:
Comments:
Are you running Apache as standalone or inetd?
If I remember right, PHP/Apache/inetd likes to lose env variables.
-Chris
Previous Comments:
---
[2001-03-30 11:38:36] [EMAIL PROTECTED]
?php
// Header("WWW-Authenticate: Basic realm="Realm"");
if (!$PHP_AUTH_USER) {
exec("");
Header("WWW-Authenticate: Basic realm="Realm"");
Header("HTTP/1.0 401 Unauthorized");
} else
echo "else";
?
Compiler: gcc 2.95.2
Make: GNU 3.79
FSU Pthreads: 3.8
Apache: 1.3.19
MySQL: 3.23.36
PHP: 4.0.4pl1
Freetype: 2.0
LibPNG: 1.0.9
LibJPEG: 6b
Libgd: 1.8.4
PHP is compiled as an Apache module with the following options:
--with-mysql --with-apache --with-pdflib --with-gd --with-trans-sid
--enable-track-vars --enable-sysvsem --enable-sysvshm
Description of problem:
Both sides of the IF construct are being executed when testing the
$PHP_AUTH_USER variable AND issuing the header function. I posted this
question in the general mail list but have received any reponse from
anyoneso
Using the script list above, follow the steps shown below to produce this
problem:
1. Close all instances of your browser (I am using IE-5.01 and I have not
tried any other browsers). However I don't believe it is a browser issue.
2. Run the script shown above.
3. Enter some user ID and password... Everything so far works fine.
4. Look in the directory where the script is stored. There should be a file
called . This indicates that $PHP_AUTH_USER was NOT set.
5. Remove the file .
6. Refresh the browser. Look for the file . Notice that is present;
which should only happen if $PHP_AUTH_USER is NOT setYET "else" was
printed on screen which indicates that $PHP_AUTH_USER IS set.
7. Uncomment the commented "header" line and notice that a user ID and
password prompt is always issued in this case.
My questions are:
1. Why are both sides of the conditional "If (!isset($PHP_AUTH_USER))" being
executed?
2. Why, when $PHP_AUTH_USER is not set, the 'exec("")' runs on
subsequent refreshes, but no prompt for a new user ID and password is
issued?
3. Why, if a authenticate header is sent before testing, a user ID and
password prompt is issued?
Thanks for taking a look at this.
Dean
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=10079edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10074 Updated: checkdnsrr always returns false
ID: 10074 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Analyzed Bug Type: Network related Assigned To: Comments: This is because of this line in ext/standard/dns.c: #if HAVE_RES_SEARCH !(defined(__BEOS__)||defined(PHP_WIN32)) I don't know whether windows has the necessary functions to get this work. Possibly. --Jani Previous Comments: --- [2001-03-29 23:58:41] [EMAIL PROTECTED] Every call I make to checkdnsrr returns false on Win2k/IIS. Same code behaves properly in linux. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10074edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10082: curl_setopt with CURLOPT_HTTPHEADER option is broken
From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.3
PHP version: 4.0 Latest CVS (30/03/2001)
PHP Bug Type:
Bug description: curl_setopt with CURLOPT_HTTPHEADER option is broken
The CURLOPT_HTTPHEADER option for curl_setopt does not
currently work correctly. in the 4.0.4pl1 release, it
didn't work at all because the constant CURLOPT_HTTPHEADER
was mistakenly defined to CURLOPT_HEADER instead of the
correct value. That appears to have been corrected in cvs.
The fix is not complete however. In lines 486 and 487 of
curl.c you are mallocing memory for a curl_slist and zeroing
it out, then using curl_slist_append later to add things to
the list. This is incorrect. curl_slist_append should
initially be called with a null pointer as its list, and it
will correctly allocate the memory itself. If you allocate
and zero the memory, that adds an item at the beginning of
the list which is empty. Later, when you try to execute
with curl_exec, it will crash because it trys to do a
strncmp against a null pointer inside your list object.
simply removing lines 486 and 487 will make everything work
properly.
a patch versus the latest cvs is attached below.
appologies for any trouble applying this, as i had to cut
and paste it into the web form.
Index: curl.c
===
RCS file: /repository/php4/ext/curl/curl.c,v
retrieving revision 1.41
diff -u -r1.41 curl.c
--- curl.c 2001/03/20 21:30:42 1.41
+++ curl.c 2001/03/30 19:37:40
@@ -483,9 +483,6 @@
RETURN_FALSE;
}
- header =
emalloc(sizeof(struct curl_slist));
- memset(header, 0,
sizeof(struct curl_slist));
-
for
(zend_hash_internal_pointer_reset(headers);
zend_hash_get_current_data(headers, (void *
*)current) == SUCCESS;
zend_hash_move_forward(headers)) {
--
Edit Bug report at: http://bugs.php.net/?id=10082edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10078 Updated: Problems with ImageCreate function
ID: 10078 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: GD related Assigned To: Comments: Please include the shortest possible self containing PHP script into this bug report which can be used to reproduce this. --Jani Previous Comments: --- [2001-03-30 11:27:57] [EMAIL PROTECTED] When I tried to use ImageCreate and other GD functions in PHP, it happend to be not functioning correct: ImageCreate failed to return image descriptor, instead it returned undefined value. How can I fix this problem? Please reply my letter as soon as you can. My e-mail address is [EMAIL PROTECTED] Thanks! --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10078edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #7339 Updated: ODBC with Oracle and Apache, Server rejected the connection
ID: 7339
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: ODBC related
Assigned To:
Comments:
Previous Comments:
---
[2000-10-19 08:37:44] [EMAIL PROTECTED]
Hello,
Using PHP3 and connecting to Oracle via ODBC everything works fine but using exactly
the same script with PHP4.0.3pl1 I receive this "SQL error: [Oracle][ODBC][Ora]Server
rejected the connection., SQL state 08004 in SQLConnect".
The scrip is really easy, here it is:
?php
if (!($conn=odbc_connect ("ORACLEQP", "scott", "tiger")))
echo "Error";
else
echo "OK";
?
Obviously "ORACLEQP" is my Sysytem DSN. The server machine is different from the Web
Server running apache and PHP.
Any hint would be very appreciated cause right now to workaround to the problem I am
using both PHP3 and PHP4.
(I need PHP4 because I am trying to use GD library)
Thanks
Andrea
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7339edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10082 Updated: curl_setopt with CURLOPT_HTTPHEADER option is broken
ID: 10082
User Update by: [EMAIL PROTECTED]
Status: Open
Old-Bug Type:
Bug Type: *General Issues
Description: curl_setopt with CURLOPT_HTTPHEADER option is broken
Another thing that occured to me:
The later crash could be missed if you haven't set a
User-Agent header yourself. When i set CURLOPT_USERAGENT
and then use CURLOPT_HTTPHEADER i get the crash. It looks
like you won't get that unless you set USERAGENT, but I
haven't tested that case. In any event, the way it's
currently done is still wrong.
Previous Comments:
---
[2001-03-30 14:43:49] [EMAIL PROTECTED]
The CURLOPT_HTTPHEADER option for curl_setopt does not
currently work correctly. in the 4.0.4pl1 release, it
didn't work at all because the constant CURLOPT_HTTPHEADER
was mistakenly defined to CURLOPT_HEADER instead of the
correct value. That appears to have been corrected in cvs.
The fix is not complete however. In lines 486 and 487 of
curl.c you are mallocing memory for a curl_slist and zeroing
it out, then using curl_slist_append later to add things to
the list. This is incorrect. curl_slist_append should
initially be called with a null pointer as its list, and it
will correctly allocate the memory itself. If you allocate
and zero the memory, that adds an item at the beginning of
the list which is empty. Later, when you try to execute
with curl_exec, it will crash because it trys to do a
strncmp against a null pointer inside your list object.
simply removing lines 486 and 487 will make everything work
properly.
a patch versus the latest cvs is attached below.
appologies for any trouble applying this, as i had to cut
and paste it into the web form.
Index: curl.c
===
RCS file: /repository/php4/ext/curl/curl.c,v
retrieving revision 1.41
diff -u -r1.41 curl.c
--- curl.c 2001/03/20 21:30:42 1.41
+++ curl.c 2001/03/30 19:37:40
@@ -483,9 +483,6 @@
RETURN_FALSE;
}
- header =
emalloc(sizeof(struct curl_slist));
- memset(header, 0,
sizeof(struct curl_slist));
-
for
(zend_hash_internal_pointer_reset(headers);
zend_hash_get_current_data(headers, (void *
*)current) == SUCCESS;
zend_hash_move_forward(headers)) {
---
Full Bug description available at: http://bugs.php.net/?id=10082
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10070 Updated: incorrect ob_gzhandler implementation
ID: 10070 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Analyzed Status: Closed Bug Type: Zlib Related Assigned To: Comments: If a browser breaks RFCs - not our problem. Closed. --Jani Previous Comments: --- [2001-03-30 13:07:42] [EMAIL PROTECTED] Applied a patch to add Vary: headers if we add a Content-Encoding: header. Regarding the browser compatibility with Deflate, I think we should just leave it like it is. _They_ break the RFC; encourage people to upgrade to modern, non-broken browsers instead ? --- [2001-03-29 21:21:53] [EMAIL PROTECTED] ob_gzhandler doesn't appear to set a Vary: header on responses, which means that proxy caches could store a compressed version of the resource and serve it to clients which can't handle the encoding. This is very difficult to debug for Web sites, and should be fixed ASAP. For an example of the proper headers to send, see the PHP at: http://www.mnot.net/cgi_buffer/ Also, in my experience, some versions of MSIE don't handle deflate compession correctly, even though their Accept-Encoding claims they do. It might be better to avoid deflate altogether, as gzip support is pretty much the unwritten standard. Cheers, --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10070edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10079 Updated: Header Function Within IF construct
ID: 10079
Updated by: cnewbill
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Scripting Engine problem
Assigned To:
Comments:
Use the web interface, do not reply to these emails.
I did not try it because i did not have the time. I just tried it and did not get
those same results.
After the first login it did create the file, I deleted, refreshed, no file...did what
it is supposed to.
I am however using a CVS version of 4.0.5, have you tried it with the CVS version?
-Chris
Previous Comments:
---
[2001-03-30 12:34:38] [EMAIL PROTECTED]
Are you running Apache as standalone or inetd?
If I remember right, PHP/Apache/inetd likes to lose env variables.
-Chris
---
[2001-03-30 11:38:36] [EMAIL PROTECTED]
?php
// Header("WWW-Authenticate: Basic realm="Realm"");
if (!$PHP_AUTH_USER) {
exec("");
Header("WWW-Authenticate: Basic realm="Realm"");
Header("HTTP/1.0 401 Unauthorized");
} else
echo "else";
?
Compiler: gcc 2.95.2
Make: GNU 3.79
FSU Pthreads: 3.8
Apache: 1.3.19
MySQL: 3.23.36
PHP: 4.0.4pl1
Freetype: 2.0
LibPNG: 1.0.9
LibJPEG: 6b
Libgd: 1.8.4
PHP is compiled as an Apache module with the following options:
--with-mysql --with-apache --with-pdflib --with-gd --with-trans-sid
--enable-track-vars --enable-sysvsem --enable-sysvshm
Description of problem:
Both sides of the IF construct are being executed when testing the $PHP_AUTH_USER
variable AND issuing the header function. I posted this question in the general mail
list but have received any reponse from anyoneso
Using the script list above, follow the steps shown below to produce this problem:
1. Close all instances of your browser (I am using IE-5.01 and I have not tried any
other browsers). However I don't believe it is a browser issue.
2. Run the script shown above.
3. Enter some user ID and password... Everything so far works fine.
4. Look in the directory where the script is stored. There should be a file called
. This indicates that $PHP_AUTH_USER was NOT set.
5. Remove the file .
6. Refresh the browser. Look for the file . Notice that is present; which
should only happen if $PHP_AUTH_USER is NOT setYET "else" was printed on screen
which indicates that $PHP_AUTH_USER IS set.
7. Uncomment the commented "header" line and notice that a user ID and password prompt
is always issued in this case.
My questions are:
1. Why are both sides of the conditional "If (!isset($PHP_AUTH_USER))" being executed?
2. Why, when $PHP_AUTH_USER is not set, the 'exec("")' runs on subsequent
refreshes, but no prompt for a new user ID and password is issued?
3. Why, if a authenticate header is sent before testing, a user ID and password prompt
is issued?
Thanks for taking a look at this.
Dean
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10079edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10079 Updated: Header Function Within IF construct
ID: 10079
Updated by: cnewbill
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Scripting Engine problem
Assigned To:
Comments:
Open - Feedback
That's rather annoying that the state is not saved, is anyone working on this? I know
there is a new system coming, but not for a while. Or where is it located in CVS and
I'll fix it.
-Chris
Previous Comments:
---
[2001-03-30 15:10:11] [EMAIL PROTECTED]
Use the web interface, do not reply to these emails.
I did not try it because i did not have the time. I just tried it and did not get
those same results.
After the first login it did create the file, I deleted, refreshed, no file...did what
it is supposed to.
I am however using a CVS version of 4.0.5, have you tried it with the CVS version?
-Chris
---
[2001-03-30 12:34:38] [EMAIL PROTECTED]
Are you running Apache as standalone or inetd?
If I remember right, PHP/Apache/inetd likes to lose env variables.
-Chris
---
[2001-03-30 11:38:36] [EMAIL PROTECTED]
?php
// Header("WWW-Authenticate: Basic realm="Realm"");
if (!$PHP_AUTH_USER) {
exec("");
Header("WWW-Authenticate: Basic realm="Realm"");
Header("HTTP/1.0 401 Unauthorized");
} else
echo "else";
?
Compiler: gcc 2.95.2
Make: GNU 3.79
FSU Pthreads: 3.8
Apache: 1.3.19
MySQL: 3.23.36
PHP: 4.0.4pl1
Freetype: 2.0
LibPNG: 1.0.9
LibJPEG: 6b
Libgd: 1.8.4
PHP is compiled as an Apache module with the following options:
--with-mysql --with-apache --with-pdflib --with-gd --with-trans-sid
--enable-track-vars --enable-sysvsem --enable-sysvshm
Description of problem:
Both sides of the IF construct are being executed when testing the $PHP_AUTH_USER
variable AND issuing the header function. I posted this question in the general mail
list but have received any reponse from anyoneso
Using the script list above, follow the steps shown below to produce this problem:
1. Close all instances of your browser (I am using IE-5.01 and I have not tried any
other browsers). However I don't believe it is a browser issue.
2. Run the script shown above.
3. Enter some user ID and password... Everything so far works fine.
4. Look in the directory where the script is stored. There should be a file called
. This indicates that $PHP_AUTH_USER was NOT set.
5. Remove the file .
6. Refresh the browser. Look for the file . Notice that is present; which
should only happen if $PHP_AUTH_USER is NOT setYET "else" was printed on screen
which indicates that $PHP_AUTH_USER IS set.
7. Uncomment the commented "header" line and notice that a user ID and password prompt
is always issued in this case.
My questions are:
1. Why are both sides of the conditional "If (!isset($PHP_AUTH_USER))" being executed?
2. Why, when $PHP_AUTH_USER is not set, the 'exec("")' runs on subsequent
refreshes, but no prompt for a new user ID and password is issued?
3. Why, if a authenticate header is sent before testing, a user ID and password prompt
is issued?
Thanks for taking a look at this.
Dean
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10079edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10079 Updated: Header Function Within IF construct
ID: 10079
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Scripting Engine problem
Description: Header Function Within IF construct
Apache is running standalone as a daemon.
.
No, I havn't tried 4.0.5. I'll give it try ... Just tell where to download it.
Dean
Previous Comments:
---
[2001-03-30 15:12:11] [EMAIL PROTECTED]
Open - Feedback
That's rather annoying that the state is not saved, is anyone working on this? I know
there is a new system coming, but not for a while. Or where is it located in CVS and
I'll fix it.
-Chris
---
[2001-03-30 15:10:11] [EMAIL PROTECTED]
Use the web interface, do not reply to these emails.
I did not try it because i did not have the time. I just tried it and did not get
those same results.
After the first login it did create the file, I deleted, refreshed, no file...did what
it is supposed to.
I am however using a CVS version of 4.0.5, have you tried it with the CVS version?
-Chris
---
[2001-03-30 12:34:38] [EMAIL PROTECTED]
Are you running Apache as standalone or inetd?
If I remember right, PHP/Apache/inetd likes to lose env variables.
-Chris
---
[2001-03-30 11:38:36] [EMAIL PROTECTED]
?php
// Header("WWW-Authenticate: Basic realm="Realm"");
if (!$PHP_AUTH_USER) {
exec("");
Header("WWW-Authenticate: Basic realm="Realm"");
Header("HTTP/1.0 401 Unauthorized");
} else
echo "else";
?
Compiler: gcc 2.95.2
Make: GNU 3.79
FSU Pthreads: 3.8
Apache: 1.3.19
MySQL: 3.23.36
PHP: 4.0.4pl1
Freetype: 2.0
LibPNG: 1.0.9
LibJPEG: 6b
Libgd: 1.8.4
PHP is compiled as an Apache module with the following options:
--with-mysql --with-apache --with-pdflib --with-gd --with-trans-sid
--enable-track-vars --enable-sysvsem --enable-sysvshm
Description of problem:
Both sides of the IF construct are being executed when testing the $PHP_AUTH_USER
variable AND issuing the header function. I posted this question in the general mail
list but have received any reponse from anyoneso
Using the script list above, follow the steps shown below to produce this problem:
1. Close all instances of your browser (I am using IE-5.01 and I have not tried any
other browsers). However I don't believe it is a browser issue.
2. Run the script shown above.
3. Enter some user ID and password... Everything so far works fine.
4. Look in the directory where the script is stored. There should be a file called
. This indicates that $PHP_AUTH_USER was NOT set.
5. Remove the file .
6. Refresh the browser. Look for the file . Notice that is present; which
should only happen if $PHP_AUTH_USER is NOT setYET "else" was printed on screen
which indicates that $PHP_AUTH_USER IS set.
7. Uncomment the commented "header" line and notice that a user ID and password prompt
is always issued in this case.
My questions are:
1. Why are both sides of the conditional "If (!isset($PHP_AUTH_USER))" being executed?
2. Why, when $PHP_AUTH_USER is not set, the 'exec("")' runs on subsequent
refreshes, but no prompt for a new user ID and password is issued?
3. Why, if a authenticate header is sent before testing, a user ID and password prompt
is issued?
Thanks for taking a look at this.
Dean
---
Full Bug description available at: http://bugs.php.net/?id=10079
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10079 Updated: Header Function Within IF construct
ID: 10079
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Scripting Engine problem
Assigned To:
Comments:
http://snaps.php.net/
Previous Comments:
---
[2001-03-30 15:21:34] [EMAIL PROTECTED]
Apache is running standalone as a daemon.
.
No, I havn't tried 4.0.5. I'll give it try ... Just tell where to download it.
Dean
---
[2001-03-30 15:12:11] [EMAIL PROTECTED]
Open - Feedback
That's rather annoying that the state is not saved, is anyone working on this? I know
there is a new system coming, but not for a while. Or where is it located in CVS and
I'll fix it.
-Chris
---
[2001-03-30 15:10:11] [EMAIL PROTECTED]
Use the web interface, do not reply to these emails.
I did not try it because i did not have the time. I just tried it and did not get
those same results.
After the first login it did create the file, I deleted, refreshed, no file...did what
it is supposed to.
I am however using a CVS version of 4.0.5, have you tried it with the CVS version?
-Chris
---
[2001-03-30 12:34:38] [EMAIL PROTECTED]
Are you running Apache as standalone or inetd?
If I remember right, PHP/Apache/inetd likes to lose env variables.
-Chris
---
[2001-03-30 11:38:36] [EMAIL PROTECTED]
?php
// Header("WWW-Authenticate: Basic realm="Realm"");
if (!$PHP_AUTH_USER) {
exec("");
Header("WWW-Authenticate: Basic realm="Realm"");
Header("HTTP/1.0 401 Unauthorized");
} else
echo "else";
?
Compiler: gcc 2.95.2
Make: GNU 3.79
FSU Pthreads: 3.8
Apache: 1.3.19
MySQL: 3.23.36
PHP: 4.0.4pl1
Freetype: 2.0
LibPNG: 1.0.9
LibJPEG: 6b
Libgd: 1.8.4
PHP is compiled as an Apache module with the following options:
--with-mysql --with-apache --with-pdflib --with-gd --with-trans-sid
--enable-track-vars --enable-sysvsem --enable-sysvshm
Description of problem:
Both sides of the IF construct are being executed when testing the $PHP_AUTH_USER
variable AND issuing the header function. I posted this question in the general mail
list but have received any reponse from anyoneso
Using the script list above, follow the steps shown below to produce this problem:
1. Close all instances of your browser (I am using IE-5.01 and I have not tried any
other browsers). However I don't believe it is a browser issue.
2. Run the script shown above.
3. Enter some user ID and password... Everything so far works fine.
4. Look in the directory where the script is stored. There should be a file called
. This indicates that $PHP_AUTH_USER was NOT set.
5. Remove the file .
6. Refresh the browser. Look for the file . Notice that is present; which
should only happen if $PHP_AUTH_USER is NOT setYET "else" was printed on screen
which indicates that $PHP_AUTH_USER IS set.
7. Uncomment the commented "header" line and notice that a user ID and password prompt
is always issued in this case.
My questions are:
1. Why are both sides of the conditional "If (!isset($PHP_AUTH_USER))" being executed?
2. Why, when $PHP_AUTH_USER is not set, the 'exec("")' runs on subsequent
refreshes, but no prompt for a new user ID and password is issued?
3. Why, if a authenticate header is sent before testing, a user ID and password prompt
is issued?
Thanks for taking a look at this.
Dean
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10079edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9821 Updated: ClibPDF cpdf_set_viewer_preferences function not working
ID: 9821
Updated by: ohrn
Reported By: [EMAIL PROTECTED]
Old-Status: Assigned
Status: Closed
Old-Bug Type: Feature/Change Request
Bug Type: ClibPDF related
Assigned To:
Comments:
Fixed in CVS.
Previous Comments:
---
[2001-03-18 14:57:01] [EMAIL PROTECTED]
I'll look into it.
---
[2001-03-18 14:45:32] [EMAIL PROTECTED]
Just thought I'd leave my small patch for making the cpdf_set_viewer_preferences work
a bit. I can't seem
to find anywhere else to leave it.
BEGIN PATCH
--- php-4.0.4pl1/ext/cpdf/cpdf.cWed Oct 25 19:43:49 2000
+++ php-4.0.4pl1/ext/cpdf/cpdf.cTue Mar 6 19:51:41 2001
@@ -338,6 +339,7 @@
/* {{{ proto void cpdf_set_viewer_preferences(int pdfdoc, int pagemode)
How to show the document by the viewer */
PHP_FUNCTION(cpdf_set_viewer_preferences) {
+ CPDFviewerPrefs vP = { 0, 0, 0, 0, 0, 0, 0, 0 };
pval *argv[6];
int id, type, pagemode;
int argc;
@@ -361,6 +363,9 @@
}
/* cpdf_setViewerPreferences(pdf, pagemode, 0, 0, 0, 0, 0, 0, pagemode); */
+ vP.pageMode=pagemode;
+ vP.nonFSPageMode=pagemode;
+ cpdf_setViewerPreferences(pdf, vP);
RETURN_TRUE;
}
---END PATCH
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9821edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9774 Updated: OCIColumnType() returns similar, but non-specific datatypes
ID: 9774 Updated by: ohrn Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: OCI8 related Assigned To: Comments: From a look at the OCI library headerfiles it doesn't seem to be possible to tell the difference. Previous Comments: --- [2001-03-15 17:26:07] [EMAIL PROTECTED] Section 2 of the Oracle 8i SQL Reference document specifies 4 character datatypes: CHAR, NCHAR, NVARCHAR2, and VARCHAR2. However, OCIColumnType() will only return CHAR, CHAR, VARCHAR and VARCHAR, respectively. Ryan Finnie --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9774edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10079 Updated: Header Function Within IF construct
ID: 10079 User Update by: [EMAIL PROTECTED] Status: Feedback Bug Type: Scripting Engine problem Description: Header Function Within IF construct I guess I'm doing this right... I downloaded php4-200103301245.tar.gz. Unzipped, untarred and configured using --with-mysql --with-apache --with-trans-sid --enable-track-vars --enable-sysvsem --enable-sysvshm All configured fine. But make is not making I'm getting symbol referencing errors. It is quite possible that this version is not quite ready for SCO OpenServer. If you want, I'll send you the debug.log file from the make operation. I'm not sure if you even mess with installation problems of PHP in this forum. I have a question: Is the annomally I reported a bug in 4.0.4pl1 or is it just my system? Dean Previous Comments: --- [2001-03-30 15:45:58] [EMAIL PROTECTED] http://snaps.php.net/ --- [2001-03-30 15:21:34] [EMAIL PROTECTED] Apache is running standalone as a daemon. . No, I havn't tried 4.0.5. I'll give it try ... Just tell where to download it. Dean --- [2001-03-30 15:12:11] [EMAIL PROTECTED] Open - Feedback That's rather annoying that the state is not saved, is anyone working on this? I know there is a new system coming, but not for a while. Or where is it located in CVS and I'll fix it. -Chris --- [2001-03-30 15:10:11] [EMAIL PROTECTED] Use the web interface, do not reply to these emails. I did not try it because i did not have the time. I just tried it and did not get those same results. After the first login it did create the file, I deleted, refreshed, no file...did what it is supposed to. I am however using a CVS version of 4.0.5, have you tried it with the CVS version? -Chris --- [2001-03-30 12:34:38] [EMAIL PROTECTED] Are you running Apache as standalone or inetd? If I remember right, PHP/Apache/inetd likes to lose env variables. -Chris --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=10079 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10072 Updated: SIGSEGV on startup (apxs)
ID: 10072
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Reproduceable crash
Description: SIGSEGV on startup (apxs)
I'm not sure what you mean. My PHP configure line already has --enable-debug, and
contains no source dirs except jpeg-6b (I can take that out and recompile I guess).
../../mysql = /usr/local/mysql, which is where it installed
Or are you referring to my Apache configure line (the example installation specified
to use those source dirs).
Previous Comments:
---
[2001-03-30 14:37:24] [EMAIL PROTECTED]
1. Delete config.cache
2. Add --enable-debug into your configure line
3. Configure and compile and try regenerating that gdb backtrace.
And do not use the source dirs in any other configure
option of PHP than --with-apache. You should be using the
INSTALL base dirs.
--Jani
---
[2001-03-29 23:40:15] [EMAIL PROTECTED]
OS version:
SunOS ptl2 5.7 Generic sun4u sparc SUNW,Ultra-5_10
Apache 1.3.19+mod_ssl-2.8.1 configure line:
EAPI_MM=../mm-1.1.3 SSL_BASE=../openssl-0.9.6 ./configure --prefix=/usr/local/apache
--enable-module=ssl --enable-module=so --enable-module=rewrite
PHP 4.0.4pl1 configure line:
./configure --with-apxs --with-mcrypt --with-mhash --with-mysql=../../mysql --with-gd
--enable-versioning --with-ttf --with-jpeg-dir=../jpeg-6b --enable-debug
If the LoadModule libphp4.so is removed from httpd.conf, Apache operates correctly.
Otherwise, there is a SIGSEGV as httpd starts up. Following is a GDB backtrace and
partial truss output. Full truss output can be found at
http://wolf.project-w.com/notes/20010330.phpsegv.txt
---
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "sparc-sun-solaris2.7"...
(gdb) run -X
Starting program: /usr/local/apache/bin/httpd -X
warning: Lowest section in /usr/lib/libintl.so.1 is .hash at 0074
Program received signal SIGSEGV, Segmentation fault.
0xff3b8894 in ?? ()
(gdb) bt
#0 0xff3b8894 in ?? ()
#1 0xff3b35a0 in ?? ()
#2 0xff3b37e8 in ?? ()
#3 0xff3bd154 in ?? ()
#4 0xb7764 in ap_os_dso_load ()
#5 0x83a70 in load_module ()
#6 0x8d550 in invoke_cmd ()
#7 0x8e3c0 in ap_handle_command ()
#8 0x8e49c in ap_srm_command_loop ()
#9 0x8ee84 in ap_process_resource_config ()
#10 0x8facc in ap_read_config ()
#11 0x9e7bc in main ()
(gdb)
---
...
stat("/usr/local/apache", 0xFFBED7C8) = 0
open("/usr/local/apache/libexec/libphp4.so", O_RDONLY) = 5
fstat(5, 0xFFBED614)= 0
mmap(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xFF34
mmap(0x, 2187264, PROT_READ|PROT_EXEC, MAP_PRIVATE, 5, 0) = 0xFED8
munmap(0xFEF46000, 57344) = 0
mmap(0xFEF54000, 182128, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 5,
1851392) = 0xFEF54000
...
mprotect(0xFED8, 1854910, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mprotect(0xFED8, 1854910, PROT_READ|PROT_EXEC) = 0
munmap(0xFEF54000, 265928) = 0
munmap(0xFED8, 1854910) = 0
Incurred fault #6, FLTBOUNDS %pc = 0xFF3B8894
siginfo: SIGSEGV SEGV_ACCERR addr=0xFF3CABD4
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_ACCERR addr=0xFF3CABD4
*** process killed ***
---
Full Bug description available at: http://bugs.php.net/?id=10072
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Question about socket ext. file descriptors
At 20:11 30/3/2001, [EMAIL PROTECTED] wrote: I'm currently updating my CVS tree so I can update the current source with something to make sure that stuff opened here is closed at the end of it. For this, I'm not too fond of going the resource route for it, simply because I know people are more familiar with the C interfaces to socket() and friends (I know I'm not alone in this, but if I seem to be, feel free to speak up now).. so it makes the interfaces more familiar to people who would want to use it (and since I tried to keep the interfaces as similar as possible, it also means that people don't have to go running to the manual for everything except for the few oddities .. 'man socket' will tell you all you need to know about socket() on any decent *nix system.) It's a pretty clear cut here - keeping the rules of PHP comes before similarity to the C interface. This covers the fact that failure should be denoted by a false return value, and that that things such as file or socket descriptors should be returned as resource handles. Having people use the UNIX 2/3 man pages to understand what the PHP functions do isn't considered a significant benefit - people are likely to check the PHP manual and not the UNIX manual anyway (man pages are just another type of a manual, hence their name :) Moving this code to use the standard PHP interface is something that should be done for 4.0.6. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10080 Updated: can't call the function sybase_affected_rows() for insert, update and delete
ID: 10080
Updated by: joey
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Sybase (dblib) related
Assigned To:
Comments:
Please try the manual before reporting bugs.
http://php.net/manual/en/function.sybase-affected-rows.php
Note: This function is only available using the CT library interface to Sybase, and
not the DB library.
Previous Comments:
---
[2001-03-30 13:25:03] [EMAIL PROTECTED]
Hello Sirs.
When I use sybase_affected_rows() fucntion for our project, the function call failed.
Following is the code snippet:
$query = "insert into form_form values('company', 'lingqin', 'file',
'[EMAIL PROTECTED]', 'subject')";
$conn = sybase_connect($server, $user, $pass);
sybase_select_db($dbname, $conn);
$result = sybase_query($query, $conn);
$rows = sybase_affected_rows($result);
When I run the above script, I got the following error:
Fatal error: Call to undefined function: sybase_affected_rows() in
/webdev/skmtest/rw/docroot/sybtest.phtml on
line 9
But, the PHP manul tells me the above function can be used by PHP 3= 3.0.6, PHP 4
We are using PHP Version 4.0.4pl1.
Please let me know what's the problem.
Thanks a lot.
Ling Zhang
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10080edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10052 Updated: setcookie() don't work
ID: 10052 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: *General Issues Assigned To: Comments: And as IE 6 is still BETA.. - bogus. --Jani Previous Comments: --- [2001-03-29 15:33:37] [EMAIL PROTECTED] I usually use IE 5.0, too. setcookie() works. But I tested also with IE 6.00.2462. and it doesn't work. Perhaps, this IE has bugs, and accepts no cookies, i don't know exactly. --- [2001-03-29 09:23:43] [EMAIL PROTECTED] Does it work with other browsers? (works for me just fine with both IE5 and NS4.76 and Mozilla) --Jani --- [2001-03-29 09:22:08] [EMAIL PROTECTED] Does it work with other browsers? (works for me just fine with both IE5 and NS4.76 and Mozilla) --Jani --- [2001-03-29 09:10:04] [EMAIL PROTECTED] In the Internet Explorer 6.00.2462. the setcookie() function don't work. No cookie will be set. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10052edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10070 Updated: incorrect ob_gzhandler implementation
ID: 10070 Updated by: avsm Reported By: [EMAIL PROTECTED] Old-Status: Closed Status: Feedback Bug Type: Zlib Related Assigned To: Comments: Just to clarify a bit more, and see if a workaround is worthwhile: Currently, if both gzip and deflate are present in the Accept-Encoding, we will prefer the gzip. The only good reason for a workaround in the code is if a widespread browser presents deflate only, and then proceeds to break. Do these broken versions of IE present Accept-Encoding: deflate _only_ ? And which versions are they? Anil Previous Comments: --- [2001-03-30 14:59:49] [EMAIL PROTECTED] If a browser breaks RFCs - not our problem. Closed. --Jani --- [2001-03-30 13:07:42] [EMAIL PROTECTED] Applied a patch to add Vary: headers if we add a Content-Encoding: header. Regarding the browser compatibility with Deflate, I think we should just leave it like it is. _They_ break the RFC; encourage people to upgrade to modern, non-broken browsers instead ? --- [2001-03-29 21:21:53] [EMAIL PROTECTED] ob_gzhandler doesn't appear to set a Vary: header on responses, which means that proxy caches could store a compressed version of the resource and serve it to clients which can't handle the encoding. This is very difficult to debug for Web sites, and should be fixed ASAP. For an example of the proper headers to send, see the PHP at: http://www.mnot.net/cgi_buffer/ Also, in my experience, some versions of MSIE don't handle deflate compession correctly, even though their Accept-Encoding claims they do. It might be better to avoid deflate altogether, as gzip support is pretty much the unwritten standard. Cheers, --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10070edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Funkiness in Zend Source ?
so im looking at the source to zend_list.c, trying to understand persistent lists. i check out zend_plist_delete which passes EG(persistent_list) as the hash table parameter to zend_list_do_delete. in zend_do_delete, however, the hashtable is completely ignored and EG(regular_list) is used instead. is this a WAD ? also, is there no zend_plist_addref ?? BTW - php4.04pl1 -- _ "Fried Ice-Cream is a reality !" - George Clinton -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10083: libphp4.so
From: [EMAIL PROTECTED] Operating system: linux mdk7.2 kernel 2.2-17 PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: libphp4.so ./apachectl start Syntax error on line 236 of /home/httpd/conf/httpd.conf: Cannot load /home/httpd/libexec/libphp4.so into server: /home/httpd/libexec/libphp4.so: undefined symbol: uncompress ./apachectl start: httpd could not be started after make install and make of php 4 and ./configure -with-apxs=/home/httpd/bin/apxs \ -with-mysql=/usr/local/mysql-3.23.36-pc-linux-gnu-i686 -- Edit Bug report at: http://bugs.php.net/?id=10083edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] CVS Account Request
Full name: djalma carneiro Email: [EMAIL PROTECTED] ID: djalma Purpose: I want to help to translate the manual for Portuguese -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10084: Release Quality
From: [EMAIL PROTECTED] Operating system: NA PHP version: 4.0 Latest CVS (30/03/2001) PHP Bug Type: Feature/Change Request Bug description: Release Quality As a happy user of PHP I'd love it if a) Releases (4.0.5) could be installed across server farms, compiled to commandline versions to support shell/console scripting, packaged in various ways for different workloads (ie adding IMAP) without the sinking fear that in a few days to a week or two I'll see pl1, pl2, pl3 and have to go through the who rigamarole again. So fewer patches, more RC's :) b) Extensions that are broken do not ship with the distribution. The quality of the extensions reflects on php itself. A few always seem to be borked but live on through releases. The folks that want to fix borked extensions can probably do so even if they are not included in the distro. Hand in hand with that is at least keeping a rough idea (or requiring the submitter to) on keeping up to date with extensions, which often are based on evolving external libraries and projects. c) Bluesky: Bloat numbers on the manual for the different extensions. This contibutes x bytes to cgi/apache module or whatever... -- Edit Bug report at: http://bugs.php.net/?id=10084edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10085: socket support seems not loaded
From: [EMAIL PROTECTED] Operating system: Mandrake Linux 7.2 PHP version: 4.0.4pl1 PHP Bug Type: Dynamic loading Bug description: socket support seems not loaded When I use default installed php package (php-4.0.3pl1) on Mandrake 7.2 (default kernel 2.2.17), it lacks socket support, then I downloaded php4.0.4pl1 and compiled a self-contained sockets.so module, it works fine! but since php 4.0.3pl1 has some bugs,therefore, I update to 4.0.0pl1 as suggested. Then each time I tried to call socket() function, it always says "call to undefined function socket()" I recompile the self-contained module, it still doesn't work ps.I have enabled extension=sockets.so in php.ini strangely enough, mysql.so still works fine! -- Edit Bug report at: http://bugs.php.net/?id=10085edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0.5 Release Midgard Problems
On Fri, Mar 30, 2001 at 01:27:11PM -0500, Sterling Hughes wrote: On Fri, 30 Mar 2001, James Moore wrote: Um... If I'm not mistaken, the midgaurd extension itself, only provides functionality to the "midguard" application? Ie, end-users of midguard will not use the functions and classes exported by the extension, only midguard will use that functionality? If so, I'm not too sure it would be a good idea to include the midguard extension in PEAR either... There is nothing stopping someone else making a php app that uses midguard extension if they want to. Right, but from what I understand the functions only make sense for the midguard application. Please clarify what you are understanding under term "midgard application"? Going this way anybody could say that MySQL extension only make sense for MySQL applications, IRCG -- for IRCG applications (no offense for Sascha :) and so on. Yes, Midgard provides different approach to store and process information than, f.g. MySQL extension, but it simply difference at high level. People are using Midgard together with other extensions as well, f.g. PostgreSQL, IRCG, ming, etc. and nobody said that Midgard functions only make sense for Midgard application. It is matter of proper design of application. I can see your point but if there is a feeling that it should be distributed with PHP in someway PEAR seems the most logical place. By your arugment why should midguard be in ext/ either as noone but people running midgard use it. PEAR is somewhere where it would be easy to retive from (eventually) and is hopefully where we will eventually have other non standard extensions. Yes, and no offense intended, I don't see why the midguard people don't just distribute the extension *with* midguard. I could see some sense in We did it for years with prepatched PHP 3.x. It always caused problems with both PHP team and end users (former was not in favor in having another PHP3 version which was extended in the core, latter were unable to use Midgard without recompiling PHP3). We spent thousand of hours to make possible co-existance of Midgard and original PHP core engine (PHP3 in first, Zend Engine in second), did it, got big experience in template generation, found zillion bugs in both PHP versions (most of them were fixed during this process). One thing that we would not to do is to close this experience inside our product. Instead, we are trying to give away it for anybody in other projects too. PHP has no templating system at core and implementations in PHP itself are rather ineffective for high-loaded applications. I don't want to initiate additional flame here, please see the problem in open eyes. Ask Zend folks, they have our proposals, even C code to Zend engine to implement native templating with no connection to Midgard at all -- this system was designed to be generic for any template providers. Midgard could be one of these template providers, not exclusive one. It is some kind of extension like session but better because it also works with template providers instantiated from dynamically loaded modules. distributing it with PHP, because then users of midguard really didn't have to worry about compiling twice, etc, its already built-in to php. While I'm not for that idea (it adds 70k of bloat), I don't see the point in distributing it with PEAR. When you distribute it with pear there is no advantage for the midguard people (or anyone) that I can see (or advantage greater than just distributing the midguard extension with midguard itself). We are really want to help PHP team to improve build environment and I'm personally did it in past month, look into archives. What is strange is that PHP team itself does not want to see problem with build environment as serious and continue talk about 'bloat' in code instead of productive work. It is sad. Please see this discussion as a call for collaborative discussion how to find solutions and improvements, not as an 'angry' answer. Latter is not productive in any movement, especially in Open Source. -- Sincerely yours, Alexander Bokovoy The Midgard Project| ALT Linux Team | Minsk Linux Users Group www.midgard-project.org | www.altlinux.ru |www.minsk-lug.net -- Since we're all here, we must not be all there. -- Bob "Mountain" Beck -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #10084 Updated: Release Quality
ID: 10084 Updated by: rasmus Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Feature/Change Request Assigned To: Comments: And I assume you will be pitching in and helping out on each front? We don't set out to have a buggy release. There is a QA team and a QA process for this purpose. Feel free to join it. See http://qa.php.net Compiling for command-line is trivial. Just don't add --with-apxs ot --with-apache and you have the standalone parser. And your bluesky stuff about adding bloat numbers to the manual. Go for it. That just takes someone sitting down and writing down the numbers. You are more than qualified and more than welcome to do this. Note however that this will be different on most platforms, so be sure to do each one. Might even have significant differences across versions of the same operating system, linkers, compilers, libc's, different versions of the 3rd party libs, etc. Previous Comments: --- [2001-03-31 00:02:29] [EMAIL PROTECTED] As a happy user of PHP I'd love it if a) Releases (4.0.5) could be installed across server farms, compiled to commandline versions to support shell/console scripting, packaged in various ways for different workloads (ie adding IMAP) without the sinking fear that in a few days to a week or two I'll see pl1, pl2, pl3 and have to go through the who rigamarole again. So fewer patches, more RC's :) b) Extensions that are broken do not ship with the distribution. The quality of the extensions reflects on php itself. A few always seem to be borked but live on through releases. The folks that want to fix borked extensions can probably do so even if they are not included in the distro. Hand in hand with that is at least keeping a rough idea (or requiring the submitter to) on keeping up to date with extensions, which often are based on evolving external libraries and projects. c) Bluesky: Bloat numbers on the manual for the different extensions. This contibutes x bytes to cgi/apache module or whatever... --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10084edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
