Re: [PHP-DEV] Logic in sapi/cgi/cgi_main.c
http://www.faqts.com/knowledge_base/view.phtml/aid/734/fid/37
It sounds to me that you are right. That should probably just be request_uri.
I thought many people have used this $PHP_SELF so it's kind of strange that
there haven't been a zillion complaints.
Does anyone object to changing this behavior?
Andi
At 01:56 PM 4/29/2001 -0400, Sterling Hughes wrote:
Can you give an example of how it looks with request_uri and how it looks
with both? Then it'll be easier for someone like me who doesn't know the
standard too well to check the PHP manual and the HTTP standard to see
what
the correct behavior should be.
Well, I can't really test this, as I don't have windows, but here's my
logic ;)
To quote the bug report ::
in your website such that it is contained somewhere within the subtree of
a directory
whose name ends with .php. For example, on my box I had the file
located at
http://site/php/secure.php/version.php
If you then look at the value of $PHP_SELF it is
/php/secure.php/php/secure.php/version.php
and NOT
/php/secure.php/version.php
as it should be.
::
This appears in what I assume is the CGI version (only place possible). I
then took a look at the code shown below. While most other sapi's
register only the request_uri (or something else, given by the server's
api itself), the code below provides an opportunity for the above
condition to occur, if SCRIPT_NAME is invalid, ie, it gets cut off too
soon, because of a odd directory name, then strcmp will not return the
correct results and request_uri will un-necessarily be appended
If you look at the first one, its with SCRIPT_NAME and
REQUEST_URI (invalid), the second one is just the value of REQUEST_URI
(valid)...
-Sterling
Andi
At 07:55 AM 4/29/2001 -0400, Sterling Hughes wrote:
I've taken a look at the code that registers $PHP_SELF in the CGI
version,
in accordance with bug 6491. I see the problem, its that on some server
OS combinations, the SCRIPT_NAME environment variable is incorrectly set
and therefore the below code exhibits the bug (the strcmp() should
avoid the request_uri being tagged on, but because the SCRIPT_NAME is
invalid, it doesn't happen the two don't match, and the REQUEST_URI is
incorrectly tagged on).
It seems like the logical fix to this would to be just registering the
REQUEST_URI as the PHP_SELF, however, I don't know this code to well,
could one of the authors explain the reasoning behind prepending the
SCRIPT_NAME when FORCE_CGI_REDIRECT is not enabled?
-Sterling
Related Code:
#if FORCE_CGI_REDIRECT
php_register_variable(PHP_SELF, (SG(request_info).request_uri ?
SG(request_info).request_uri:), track_vars_array ELS_CC PLS_CC);
#else
{
char *sn;
char *val;
int l=0;
sn = getenv(SCRIPT_NAME);
pi = SG(request_info).request_uri;
if (sn)
l += strlen(sn);
if (pi)
l += strlen(pi);
if (pi sn !strcmp(pi, sn)) {
l -= strlen(pi);
pi = NULL;
}
val = emalloc(l + 1);
sprintf(val, %s%s, (sn ? sn : ), (pi ? pi : )); /* SAFE */
php_register_variable(PHP_SELF, val, track_vars_array ELS_CC
PLS_CC);
efree(val);
}
#endif
--
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]
--
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]
[PHP-DEV] Bug #10521 Updated: Referencing a variable without setting its contents
ID: 10521
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: IIS related
PHP Version: 4.0.4pl1
Assigned To:
Comments:
I bet the Apache box has error_reporting E_ALL ~ E_NOTICE while the IIS box has
error_reporting E_ALL.
RTFM, please.
(if this ain't the case, reopen the report)
Previous Comments:
---
[2001-04-27 02:03:00] [EMAIL PROTECTED]
The following script works in Apache but not in IIS
?
if ($test==testval) { print(Success); }
?
Apache treats the variable $test as a null variable but IIS throws a error:
Warning: undefined variable test in [script] in line 2
Depending on what follows, it will usually output something like what you were testing
for/wanted except that it has the error in front of it.
This is with the standard PHP windows installer. CGI version.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10521edit=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 #10453 Updated: mod_auth_mysql and php4.0.5pl1
ID: 10453 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Apache related Description: mod_auth_mysql and php4.0.5pl1 I am using mysql and the mod_auth_mysql for a long time with older versions of php without problem. All mysql-Operations still work as before. It seems to me that the autorization information (name/passwd) don't get passsed over ... I tried to recompile with different paths in all modules but it did not work upto now. So I still use an older php module... Previous Comments: --- [2001-04-23 07:16:51] [EMAIL PROTECTED] What was your configure line? You need to give the dir to your mysql libraries of you use other modules for apache that use MySQL. Like (Example): ./configure --with-mysql=/usr/local --- [2001-04-23 07:16:35] [EMAIL PROTECTED] What was your configure line? You need to give the dir to your mysql libraries of you use other modules for apache that use MySQL. Like (Example): ./configure --with-mysql=/usr/local --- [2001-04-23 06:47:48] [EMAIL PROTECTED] I recompiled my Apache as follows: apache_1.3.19 php-4.0.4pl1 mysql-3.22.26a mod_auth_mysql-2.20 Is there any known bug in the interoperability of these modules? php works fine, but the mod_auth_mysql module gives an internal error AFTER login: Could not load complete page - and nothing shows up. Regards, Rupert Mohr --- Full Bug description available at: http://bugs.php.net/?id=10453 -- 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: Bug #10511 Updated: Cannot set COM object properties
Thanks for the quick response. When I logon as my webuser, and execute from the command line, the scripts still fail. I have changed the permissions to give this webuser admin rights, but the scripts are still failing. Accessing the same scripts with no authentication works fine. Any other ideas I can try? Cheers Peter -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: 29 April 2001 16:00 To: [EMAIL PROTECTED] Subject: Bug #10511 Updated: Cannot set COM object properties ID: 10511 Updated by: phanto Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: COM related PHP Version: 4.0.4pl1 Assigned To: Comments: make sure, that the logged in user (after basic authentication) has enough rights to change these properties. try to run the script from the commandline logged in as one of the webusers. harald Previous Comments: --- [2001-04-26 10:10:57] [EMAIL PROTECTED] I am accessing ADO COM objects through PHP. I am using PHP 4.05 RC6 on Win2K in CGI mode. If I change the authentication from anonymous access, to requiring a login through basic authentication, then the scripts fail and cannot set properties on the COM object. The same scripts work fine when run as the anonymous user. Very weird... Thanks in advance for any help Cheers Peter --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10511edit=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] Bug #10551 Updated: array_switch ( permute the keys w/ values)
ID: 10551 Updated by: cynic Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: Feature/Change Request PHP Version: 4.0 Latest CVS (29/04/2001) Assigned To: Comments: RTFM: array_flip() Previous Comments: --- [2001-04-29 08:38:06] [EMAIL PROTECTED] I found myself with an array like $a = array (0 = Foo, 1 = Bar ); and thought it would be cool to be able to say $a = array_permute/switch ($a); a being now: array (Foo = 0 , Bar=1); the value colision can use the style of extract() 3rd parameter. what do you think? -- teodor --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10551edit=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] Bug #7016 Updated: Error when starting iPlanet
ID: 7016 Updated by: avsm Reported By: [EMAIL PROTECTED] Status: Open Bug Type: iPlanet related PHP Version: 4.0.2 Assigned To: Comments: Try the following obj.conf entry, and see if it fixes your problem. Apart from this change, you should follow the manual entry for the rest of the obj.conf Init fn=load-modules shlib=/path/to/server4/bin/libphp4.so funcs=php4_init,php4_close,php4_execute,php4_auth_trans Init fn=php4_init LateInit=yes Previous Comments: --- [2000-11-03 21:01:15] [EMAIL PROTECTED] reclassified --- [2000-10-04 12:41:54] [EMAIL PROTECTED] This is the error I got when restarting iPlanet via command line after installing PHP4 w/o any errors showing up: conf_init: Error running init function load-modules: dlopen of /usr/netscape/server/bin/libphp4.so failed (ld.so.1: ns-httpd: fatal: relocation error: file /usr/netscape/server/bin/libphp4.so: symbol __pure_virtual: referenced symbol not found) Can you give me an ideas on what's going on here? Thanks. We're using the GCC2.95.2 also. After configure, make and make install, these are the steps I did: 1. add the ff line in mime.types type=magnus-internal/x-httpd-phpexts=php 2. edit obj.conf # note place following two lines after mime types init! Init fn=load-modules funcs=php4_init,php4_close,php4_execute,php4_auth_trans shlib=/usr/netscape/server/bin/libphp4.so Init fn=php4_init errorString=Failed to initialize PHP! Object name=default . . . # NOTE this next line should happen after all 'ObjectType' and before all 'AddLog' lines Service fn=php4_execute type=magnus-internal/x-httpd-php . . /Object Object name=x-httpd-php ObjectType fn=force-type type=magnus-internal/x-httpd-php Service fn=php4_execute /Object Are these correct? Thanks, Lester --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7016edit=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 #10521 Updated: Referencing a variable without setting its contents
ID: 10521
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: IIS related
Description: Referencing a variable without setting its contents
I bet the Apache box has error_reporting E_ALL ~ E_NOTICE while the IIS box has
error_reporting E_ALL.
How can I check this or set it the same as Apache? Both versions of Apache and IIS
are the default installations, so nothing to my knowledge has been modified in this
area.
Previous Comments:
---
[2001-04-30 03:17:41] [EMAIL PROTECTED]
I bet the Apache box has error_reporting E_ALL ~ E_NOTICE while the IIS box has
error_reporting E_ALL.
RTFM, please.
(if this ain't the case, reopen the report)
---
[2001-04-27 02:03:00] [EMAIL PROTECTED]
The following script works in Apache but not in IIS
?
if ($test==testval) { print(Success); }
?
Apache treats the variable $test as a null variable but IIS throws a error:
Warning: undefined variable test in [script] in line 2
Depending on what follows, it will usually output something like what you were testing
for/wanted except that it has the error in front of it.
This is with the standard PHP windows installer. CGI version.
---
Full Bug description available at: http://bugs.php.net/?id=10521
--
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] Bug #10029 Updated: zend_list_do_delete() ignores HashTable* param. Potential mem leak.
ID: 10029
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Unknown/Other Function
PHP Version: 4.0.4pl1
Assigned To:
Comments:
zend_plist_delete() was redundant and removed from the CVS a few weeks ago (it didn't
make it for 4.0.5, but will be in 4.0.6)
Previous Comments:
---
[2001-03-27 13:54:23] [EMAIL PROTECTED]
from Zend/zend_list.c
Note that list is passed in, but EG(regular_list) is used wherever list should be
used.
static inline int zend_list_do_delete(HashTable *list,int id)
{
zend_rsrc_list_entry *le;
ELS_FETCH();
if (zend_hash_index_find(EG(regular_list), id, (void **) le)==SUCCESS) {
/* printf(del(%d): %d-%dn, id, le-refcount, le-refcount-1); */
if (--le-refcount=0) {
return zend_hash_index_del(EG(regular_list), id);
} else {
return SUCCESS;
}
} else {
return FAILURE;
}
}
.
.
.
Scroll down, and we see that both zend_list_delete and zend_plist_delete are calling
this with different hashtable args. It looks as though we must be leaking memory
whenever zend_plist_delete is called.
ZEND_API int zend_list_delete(int id)
{
ELS_FETCH();
return zend_list_do_delete(EG(regular_list), id);
}
ZEND_API int zend_plist_delete(int id)
{
ELS_FETCH();
return zend_list_do_delete(EG(persistent_list), id);
}
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10029edit=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] Bug #8414 Updated: set_time_out() is acting inconsistantly
ID: 8414
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Performance problem
PHP Version: 4.0.4
Assigned To:
Comments:
Note that under UNIX, execution time relates to the actual CPU time consumed by PHP,
which may be very different (less) than the actual time that passed. sleep(), for
instance, does not consume any CPU time, so it will never trigger the execution
timeout.
Previous Comments:
---
[2001-04-29 22:03:53] [EMAIL PROTECTED]
I can't reproduce this with latest CVS. If problem
still persist with PHP 4.0.5 or with latest CVS snapshot
from http://snaps.php.net/ reopen this bug report.
--Jani
---
[2001-04-07 02:10:02] [EMAIL PROTECTED]
I'm re-filing this as a bug report.
It appears that set_time_out() is acting inconsistant.
The following code stops after 5 seconds as you would expect:
set_time_limit(5);
while(1) {
$i++;
}
While this code continues executing indefinitely:
set_time_limit(5);
while(1) {
$i++;
echo $in;
}
---
[2000-12-25 05:55:38] [EMAIL PROTECTED]
documentation is not clear enough on what excecution time
the max_execution_parameter does limit.
try the following:
?php
set_time_limit(1);
while(1) sleep(1);
?
on my machine that runs much more then one second, while:
?php
set_time_limit(1);
while(1);
?
stops after 1 second as expected.
That difference is never mentioned in documentaion.
While the usage of PROF timer make sence sometimes the parameter name
max_execution_time suggests the real time limit so that
?php
set_time_limit(30);
sleep(3600);
?
should be terminated on timeout after 30 seconds.
oleg
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8414edit=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] Bug #10558:
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.4pl1 PHP Bug Type: Documentation problem Bug description: when you enter the documentation in the Program execution section. The links between the cmd´s are messed, e.g.: on http://php.net/manual/en/function.system.php there is no link to http://php.net/manual/en/function.passthru.php or EscapeShellCmd ... Regards Jan -- Edit Bug report at: http://bugs.php.net/?id=10558edit=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] Bug #10559: commenting php closing tag
From: [EMAIL PROTECTED] Operating system: LINUX PHP version: 4.0.4pl1 PHP Bug Type: Scripting Engine problem Bug description: commenting php closing tag Is it a bug or a feature this one will ignore the closing php tag ---cut here- ?php foofoofoo(); ... /* ? */ ...whereas this won't: ---cut here- ?php echo yaho!; # ? -- Edit Bug report at: http://bugs.php.net/?id=10559edit=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] Bug #10559 Updated: commenting php closing tag
ID: 10559 Updated by: cynic Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Bogus Bug Type: Scripting Engine problem PHP Version: 4.0.4pl1 Assigned To: Comments: a feature; RTFM: http://www.php.net/manual/en/html/language.basic-syntax.comments.html Previous Comments: --- [2001-04-30 05:25:49] [EMAIL PROTECTED] Is it a bug or a feature this one will ignore the closing php tag ---cut here- ?php foofoofoo(); ... /* ? */ ...whereas this won't: ---cut here- ?php echo yaho!; # ? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10559edit=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] Bug #10521 Updated: Referencing a variable without setting its contents
ID: 10521
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: IIS related
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Well, you probably used php.ini-dist for Apache, and php.ini-optimized for IIS. Either
way, send further questions to [EMAIL PROTECTED] or [EMAIL PROTECTED]
Previous Comments:
---
[2001-04-30 05:04:54] [EMAIL PROTECTED]
I bet the Apache box has error_reporting E_ALL ~ E_NOTICE while the IIS box has
error_reporting E_ALL.
How can I check this or set it the same as Apache? Both versions of Apache and IIS
are the default installations, so nothing to my knowledge has been modified in this
area.
---
[2001-04-30 03:17:41] [EMAIL PROTECTED]
I bet the Apache box has error_reporting E_ALL ~ E_NOTICE while the IIS box has
error_reporting E_ALL.
RTFM, please.
(if this ain't the case, reopen the report)
---
[2001-04-27 02:03:00] [EMAIL PROTECTED]
The following script works in Apache but not in IIS
?
if ($test==testval) { print(Success); }
?
Apache treats the variable $test as a null variable but IIS throws a error:
Warning: undefined variable test in [script] in line 2
Depending on what follows, it will usually output something like what you were testing
for/wanted except that it has the error in front of it.
This is with the standard PHP windows installer. CGI version.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10521edit=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] Interbase problem
As discussed with Jouni a few months ago, I'm still available for testing the IB stuff on NT 4/5. At 18:31 29.4. 2001, Andi Gutmans wrote the following: -- Hi, Can you please check the following bug report? http://www.php.net/bugs.php?id=10458edit=1 Thanks, Andi -- 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] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List 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 #10538 Updated: mcrypt_generic_init truncates key/iv upon first '\0'
ID: 10538
User Update by: [EMAIL PROTECTED]
Old-Status: Assigned
Status: Closed
Bug Type: mcrypt related
Description: mcrypt_generic_init truncates key/iv upon first '\0'
Seems to be a duplicate of Bug #8839 and it is already fixed in CVS.
Previous Comments:
---
[2001-04-28 12:50:42] [EMAIL PROTECTED]
Same happens in mcrypt_ecb, mcrypt_cbc, mcrypt_cfb and mcrypt_ofb too.
Script showing the bug:
?php
$key1 = pack(H*, FF00FF0
0);
$key2 = pack(H*, FF0
0);
$iv= pack(H*, );
$plain = pack(H*, );
$handle = mcrypt_module_open(MCRYPT_TWOFISH, , MCRYPT_MODE_CFB, );
mcrypt_generic_init($handle, $key1, $iv);
$crypted1 = mcrypt_generic($handle, $plain);
mcrypt_generic_end($handle);
$handle = mcrypt_module_open(MCRYPT_TWOFISH, , MCRYPT_MODE_CFB, );
mcrypt_generic_init($handle, $key2, $iv);
$crypted2 = mcrypt_generic($handle, $plain);
mcrypt_generic_end($handle);
print bin2hex($plain).nn;
print bin2hex($crypted1).nn;
print bin2hex($crypted2).nn;
?
The two ciphertexts should NOT be the same as the key is different.
Proposed patch (also fixes a possible memory access problem, but only for the
mcrypt_generic_init function, the I didn't fully understand php_mcrypt_do_crypt yet,
when I do I will update the patch, see also Bug #10518):
--- php-4.0.4pl1/ext/mcrypt/mcrypt.cWed Nov 22 22:40:15 2000
+++ php-4.0.4pl1-sk/ext/mcrypt/mcrypt.c Sat Apr 28 18:53:07 2001
@@ -463,14 +463,22 @@
Z_STRLEN_PP(key), key_size);
php_error (E_NOTICE, dummy);
}
- strncpy (key_s, Z_STRVAL_PP(key), key_size);
+ if (Z_STRLEN_PP(key) key_size) {
+ memcpy (key_s, Z_STRVAL_PP(key), key_size);
+ } else {
+ memcpy (key_s, Z_STRVAL_PP(key), Z_STRLEN_PP(key));
+ }
if (Z_STRLEN_PP(iv) != iv_size) {
sprintf (dummy, iv size incorrect; supplied length: %d, needed: %d,
Z_STRLEN_PP(iv), iv_size);
php_error (E_WARNING, dummy);
}
- strncpy (iv_s, Z_STRVAL_PP(iv), iv_size);
+ if (Z_STRLEN_PP(iv) iv_size) {
+ memcpy (iv_s, Z_STRVAL_PP(iv), iv_size);
+ } else {
+ memcpy (iv_s, Z_STRVAL_PP(iv), Z_STRLEN_PP(iv));
+ }
RETVAL_LONG (mcrypt_generic_init (td, key_s, key_size, iv_s));
efree (iv_s);
---
Full Bug description available at: http://bugs.php.net/?id=10538
--
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] Interbase problem
What does that mean? :) Should his patch be applied or not? Andi At 11:45 AM 4/30/2001 +0200, Cynic wrote: As discussed with Jouni a few months ago, I'm still available for testing the IB stuff on NT 4/5. At 18:31 29.4. 2001, Andi Gutmans wrote the following: -- Hi, Can you please check the following bug report? http://www.php.net/bugs.php?id=10458edit=1 Thanks, Andi -- 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] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List 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] Interbase problem
I don't know. :) That msg wasn't meant for php-dev@, I didn't notice it among the recipients. Some time ago I talked to Jouni about the IB extension, we agreed I'd help him test it on NT, but I haven't heard from him since. That msg was just a reminder I'm still here; it had nothing to do with any proposed patches. It was just that your mail reminded me of the mentioned conversation... Sorry for the confusion. At 11:51 30.4. 2001, Andi Gutmans wrote the following: -- What does that mean? :) Should his patch be applied or not? Andi At 11:45 AM 4/30/2001 +0200, Cynic wrote: As discussed with Jouni a few months ago, I'm still available for testing the IB stuff on NT 4/5. At 18:31 29.4. 2001, Andi Gutmans wrote the following: -- Hi, Can you please check the following bug report? http://www.php.net/bugs.php?id=10458edit=1 Thanks, Andi -- 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] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List 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] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List 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] key_exists from php
Why? It's only interesting if you're trying to understand the table schema from one of the arrays. The right way to do it (IMHO) would be by querying the result using the field fetching functions... Zeev At 13:12 30/4/2001, David Croft wrote: mysql_fetch_array (and probably others) return a key with 'null' as the value if the field is null. This is distinct from that field not having been returned at all/not existing. -- | /+\ \| | | David Croft Infotrek On Mon, 30 Apr 2001, Zeev Suraski wrote: Why would you care if a key exists and is null? In general the behavior is so close to isset() that it's annoying to have to introduce a whole new function just for this difference. Zeev At 04:50 30/4/2001, David Croft wrote: There doesn't seem to be any way for a php script to determine whether a given key exists in an array. isset($arr['x']) fails when it exists but has a null value. I know there are ways around it like using foreach or array_keys but these don't seem very efficient. I would like to add a function key_exists, with the following proto: bool key_exists(array search, string key) Please let me know if this is inappropriate or I have missed something obvious, otherwise I shall add this tomorrow. Thanks, David. -- | /+\ \| | | David Croft Infotrek -- 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] -- 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] Bug #10067 Updated: zlib not included when compiled with apache
ID: 10067
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: MySQL related
PHP Version: 4.0.4pl1
Assigned To:
Comments:
No feedback
closing
Previous Comments:
---
[2001-03-30 14:32:47] [EMAIL PROTECTED]
Could you please try the latest CVS snapshot from http://snaps.php.net/ as this should
be fixed.
--Jani
---
[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 #10548 Updated: function ImageTTFText always get wrong chinese words from TTF ...
ID: 10548 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: GD related Description: function ImageTTFText always get wrong chinese words from TTF ... About Image function - ImageTTFText: always get wrong chinese words from TTF. To correct the problem: 690c690 ch = (ch * 256) + **next; --- ch = (ch * 256) + ((**next) 255); 705c705,709 *advance = glyph-metrics.advance; --- if ( !font-have_char_map_Unicode (ch 161) ) *advance = glyph-metrics.advance / 2; else *advance = glyph-metrics.advance; Script to test: ?php // Create the image $png = ImageCreate(200,200); $bg = ImageColorAllocate($png,0,0,0); $tx = ImageColorAllocate($png,255,128,128); // Set Chinese words (Chinese language in Chinese Big5) $string=¤¤¤å; // Chinese test (need mingli.ttf from MS-Win Chinese ver) ImageTTFText($png,30,0,0,100,$tx,/home/staff/cchsieh/public_html/gd/mingli.ttf // Send the image header(content-type: image/png\n\n); ImagePng($png); // Destroy image ImageDestroy($png); ? Previous Comments: --- [2001-04-29 06:00:49] [EMAIL PROTECTED] About Image function - ImageTTFText: always get wrong chinese words from TTF. To correct the problem: $ diff gdttf.c.orig gdttf.c 690c690 ch = (ch * 256) + **next; --- ch = (ch * 256) + ((**next) 255); Script to test: ?php // Create the image $png = ImageCreate(200,200); $bg = ImageColorAllocate($png,0,0,0); $tx = ImageColorAllocate($png,255,128,128); // Set Chinese words (Chinese language in Chinese Big5) $string=¤¤¤å; // Chinese test (need mingli.ttf from MS-Win Chinese ver) ImageTTFText($png,30,0,0,100,$tx,/home/staff/cchsieh/public_html/gd/mingli.ttf // Send the image header(content-type: image/pngnn); ImagePng($png); // Destroy image ImageDestroy($png); ? --- Full Bug description available at: http://bugs.php.net/?id=10548 -- 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 #10548 Updated: function ImageTTFText always get wrong chinese words from TTF ...
ID: 10548 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: GD related Description: function ImageTTFText always get wrong chinese words from TTF ... About Image function - ImageTTFText: always get wrong chinese words from TTF. To correct the problem: 690c690 ch = (ch * 256) + **next; --- ch = (ch * 256) + ((**next) 255); 705c705,709 *advance = glyph-metrics.advance; --- if ( !font-have_char_map_Unicode (ch 161) ) *advance = glyph-metrics.advance / 2; else *advance = glyph-metrics.advance; Script to test: ?php // Create the image $png = ImageCreate(200,200); $bg = ImageColorAllocate($png,0,0,0); $tx = ImageColorAllocate($png,255,128,128); // Set Chinese words (Chinese language in Chinese Big5) $string=¤¤¤å; // Chinese test (need mingli.ttf from MS-Win Chinese ver) ImageTTFText($png,30,0,0,100,$tx,/home/staff/cchsieh/public_html/gd/mingli.ttf // Send the image header(content-type: image/png\n\n); ImagePng($png); // Destroy image ImageDestroy($png); ? Previous Comments: --- [2001-04-30 08:26:58] [EMAIL PROTECTED] About Image function - ImageTTFText: always get wrong chinese words from TTF. To correct the problem: 690c690 ch = (ch * 256) + **next; --- ch = (ch * 256) + ((**next) 255); 705c705,709 *advance = glyph-metrics.advance; --- if ( !font-have_char_map_Unicode (ch 161) ) *advance = glyph-metrics.advance / 2; else *advance = glyph-metrics.advance; Script to test: ?php // Create the image $png = ImageCreate(200,200); $bg = ImageColorAllocate($png,0,0,0); $tx = ImageColorAllocate($png,255,128,128); // Set Chinese words (Chinese language in Chinese Big5) $string=¤¤¤å; // Chinese test (need mingli.ttf from MS-Win Chinese ver) ImageTTFText($png,30,0,0,100,$tx,/home/staff/cchsieh/public_html/gd/mingli.ttf // Send the image header(content-type: image/pngnn); ImagePng($png); // Destroy image ImageDestroy($png); ? --- [2001-04-29 06:00:49] [EMAIL PROTECTED] About Image function - ImageTTFText: always get wrong chinese words from TTF. To correct the problem: $ diff gdttf.c.orig gdttf.c 690c690 ch = (ch * 256) + **next; --- ch = (ch * 256) + ((**next) 255); Script to test: ?php // Create the image $png = ImageCreate(200,200); $bg = ImageColorAllocate($png,0,0,0); $tx = ImageColorAllocate($png,255,128,128); // Set Chinese words (Chinese language in Chinese Big5) $string=¤¤¤å; // Chinese test (need mingli.ttf from MS-Win Chinese ver) ImageTTFText($png,30,0,0,100,$tx,/home/staff/cchsieh/public_html/gd/mingli.ttf // Send the image header(content-type: image/pngnn); ImagePng($png); // Destroy image ImageDestroy($png); ? --- Full Bug description available at: http://bugs.php.net/?id=10548 -- 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] 4.0.6
Andi, We have plan to add ext/jstring which is a japanese string extension module to php-4.0.6. Is there any problem to add this module on CVS tree now ? On Sun, 29 Apr 2001 22:35:43 +0200 Andi Gutmans [EMAIL PROTECTED] wrote: Guys, I think that despite the release of 4.0.5 tomorrow we are pretty close to having an RC1 for 4.0.6. Lots of things have been fixed/added since 4.0.5 (check the NEWS file). Can we make a list of things which still need to make it into 4.0.6 before we branch? Andi -- -- Rui Hirokawa [EMAIL PROTECTED] maintainer of japanese PHP manual [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]
[PHP-DEV] Bug #9708 Updated: double #defined V_RENAME, the second
ID: 9708 Updated by: andi Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Compile Failure PHP Version: 4.0.4pl1 Assigned To: Comments: This should be fixed in the latest CVS. Previous Comments: --- [2001-03-13 18:21:09] [EMAIL PROTECTED] Sorry! The last comment was put in the wrong context. Andreas --- [2001-03-13 18:16:21] [EMAIL PROTECTED] The alloca.h file, I have written, is this: #ifndef _H_ALLOCA #define _H_ALLOCA #pragma alloca /*needed, as no alloca in any library of AIX*/ #ifdef _NO_PROTO extern void *alloca(); #else /* _NO_PROTO */ #include stdlib.h /*size_t is defined in here*/ extern void *alloca(size_t); #endif /* _NO_PROTO */ #endif /* _H_ALLOCA */ Regards Andreas Pistoor --- [2001-03-12 10:07:29] [EMAIL PROTECTED] Hi, I got this symptom by compiling PHP: xlc -I. -I/home/pistoor/php-4.0.4pl1/ext/shmop -I/home/pistoor/php-4.0.4pl1/main -I/home/pistoor/php-4.0.4pl1 -I/home/pistoor/php-4.0.4pl1/Zend -I/home/pistoor/php-4.0.4pl1/ext/mysql/libmysql -I/home/pistoor/php-4.0.4pl1/ext/xml/expat/xmltok -I/home/pistoor/php-4.0.4pl1/ext/xml/expat/xmlparse -I/home/pistoor/php-4.0.4pl1/TSRM -DXML_BYTE_ORDER=21 -qsource -qshowinc -I/home/pistoor -DHAVE_INT_8_16_32=1 -c shmop.c touch shmop.lo /usr/include/sys/vnode.h, line 102.9: 1506-213 (S) Macro name V_RENAME cannot be redefined. /usr/include/sys/vnode.h, line 102.9: 1506-358 (I) V_RENAME is defined on line 190 of /home/pistoor/php-4.0.4pl1/TSRM/tsrm_virtual_cwd.h. I use the xlc-version of the C Set ++ for AIX compiler, as it is more ANSI-C than the cc-version. It also shows more errors. My configuration of PHP (as a CGI-program to be used by Lynx): CC=xlc ./configure --prefix=/home/pistoor/php --with-config-file-path=/home/pistoor/php --enable-debug --enable-sigchild --enable-calendar --enable-ftp --enable-trans-sid --enable-shmop --with-regex=php --enable-sysvsem --enable-sysvshm --enable-wddx --enable-yp The file ext/shmop/shmop.c includes sys/shm.h without taking care of V_RENAME. I have inluded some code to save V_RENAME: #ifdef V_RENAME #define PHP_V_RENAME V_RENAME #undef V_RENAME #endif #include sys/ipc.h #include sys/shm.h #ifdef PHP_V_RENAME #ifdef V_RENAME #undef V_RENAME #endif #define V_RENAME PHP_V_RENAME #undef PHP_V_RENAME #endif Regard Andreas Pistoor PS. I got also the error depending on HAVE_INT_8_16_32! --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9708edit=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 #10419 Updated: apache ./configure fails
ID: 10419
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Compile Problem
Description: apache ./configure fails
problem solved.
using the official patch for oracle from technet.oracle.com
will do the job
Previous Comments:
---
[2001-04-20 05:56:04] [EMAIL PROTECTED]
this is the same as bug #9950
when i add -lpthread to LIBS in the apache makefile,
some errors are solved but not all when running ./configure in the apache dir.
/usr/lib/libresolv.so: undefined reference to `[EMAIL PROTECTED]'
/usr/lib/libnsl.so: undefined reference to `[EMAIL PROTECTED]'
/usr/lib/libnsl.so: undefined reference to `[EMAIL PROTECTED]'
/usr/lib/libnsl.so: undefined reference to `[EMAIL PROTECTED]'
/usr/lib/libresolv.so: undefined reference to `[EMAIL PROTECTED]'
/usr/lib/libresolv.so: undefined reference to `[EMAIL PROTECTED]'
/usr/lib/libresolv.so: undefined reference to `[EMAIL PROTECTED]'
/usr/lib/libnsl.so: undefined reference to `[EMAIL PROTECTED]'
collect2: ld returned 1 exit status
latest cvs from php (checked out on 20-apr-01 11:40) can't run ./configure correctly:
loading cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking whether to enable maintainer-specific portions of Makefiles... no
checking host system type... i686-pc-linux-gnu
checking for mawk... no
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.28 (ok)
checking for gcc... gcc
checking whether the C compiler (gcc ) works... no
configure: error: installation or configuration problem: C compiler cannot create
executables.
so i can't try apache configure together with latest cvs
gcc is:
gcc version 2.95.3 20010315 (release)
and gcc works correctly with all other configure scripts.
any ideas ?
thx
gerald
---
Full Bug description available at: http://bugs.php.net/?id=10419
--
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] Bug #9297 Updated: sprintf (%f, $foo) crashes with very large $foo.
ID: 9297 Updated by: andi Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Strings related PHP Version: 4.0.4pl1 Assigned To: Comments: Can you please try the latest CVS or a snapshot from snaps.php.net and let us know if this still happens. I can't reproduce it on redhat 6.2. Thanks. Previous Comments: --- [2001-02-16 10:34:20] [EMAIL PROTECTED] [ben@home ben]$ echo '? $foo = 2.2864849511949E+190; settype($foo,double); printf(%fn, $foo) ?' | php X-Powered-By: PHP/4.0.4pl1 Content-type: text/html 2286484951194899000 Segmentation fault (core dumped) --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9297edit=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] Bug #10439 Updated: relative chdir from root doesn´t work
ID: 10439
Updated by: andi
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: *Directory/Filesystem functions
PHP Version: 4.0.4
Assigned To:
Comments:
Works fine in latest CVS under NT.
Please try 4.0.5 which should be released today and report back if your problem has
been solved.
Previous Comments:
---
[2001-04-22 06:54:22] [EMAIL PROTECTED]
On w98 and w98se it is not possible to change from root directory (eg. c:) to a
relative subdirectory (e.g. windows). There is a delay of about 1 second. The same
when accessing file functions (eg. is_dir, filesize) on filenames in the root
directory without path (e.g. filesize (msdos.sys), no result is returned.
Try this script:
?PHP
function mychdir ($text, $dir, $works) {
echo $text '$dir': ; flush();
chdir ($dir);
echo
font color=. ($works ? green : red)..
str_replace (\, /, getcwd ())./FONTBR;
flush ();
}
mychdir (change to root, /, true);
mychdir (change to existing full path, c:/windows/temp, true);
mychdir (change to parent, .., true);
mychdir (change to relative subdir, temp, true);
mychdir (change to parent-parent, ../.., true);
mychdir (change to root, /, true);
mychdir (change to relative subdir from root - does not work (notice the delay),
windows, false);
?
Gustav Graf
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10439edit=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] Bug #10560: IISConfig Error
From: [EMAIL PROTECTED] Operating system: NT 4.0 PHP version: 4.0.4pl1 PHP Bug Type: *Install and Config Bug description: IISConfig Error During the install of PHP I recieved an error stating that the MSCOMCTL.OCX did not correctly register a file is missing or invalid. -- Edit Bug report at: http://bugs.php.net/?id=10560edit=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] 4.0.6
On Mon, 30 Apr 2001 15:37:14 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: At 09:35 PM 4/30/2001 +0900, Rui Hirokawa wrote: Andi, We have plan to add ext/jstring which is a japanese string extension module to php-4.0.6. Is there any problem to add this module on CVS tree now ? No I don't see a problem with this but please do it quickly. 4.0.6 has already gone a long way since we started RC'ing 4.0.5 and I would like to start RC'ing it pretty soon. You should probably also copy dotnet/EXPERIMENTAL to your directory until it becomes completely stable. I did. By the way, do you think jstring is the right name? Is it only for Japanese? It includes some functions for japanese,but some functions are not only for japanese. For example, this module supports encoding conversion functionality between Unicode and some other encodings like ISO-8859-X. Currently, it includes encoding conversion filter for japanese and ISO-8859-X, but it is relatively easy task to add another conversion filter for some other language. I believe this module is small step for PHP internationalization. I think the name 'jstring' is right name now because it is existing for japanese string function now. But 'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name. -- -- Rui Hirokawa [EMAIL PROTECTED] maintainer of japanese PHP manual [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] 4.0.6
RH For example, this module supports encoding conversion RH functionality between Unicode and some other encodings like RH ISO-8859-X. Currently, it includes encoding conversion filter Doesn't this duplicate the GNU recode functionality? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] Bug #10560 Updated: IISConfig Error
ID: 10560 Updated by: cynic Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Install and Config PHP Version: 4.0.4pl1 Assigned To: Comments: this is being solved right now and will be probably fixed in 4.0.6 Previous Comments: --- [2001-04-30 09:41:19] [EMAIL PROTECTED] During the install of PHP I recieved an error stating that the MSCOMCTL.OCX did not correctly register a file is missing or invalid. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10560edit=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] Bug #9297 Updated: sprintf (%f, $foo) crashes with very large $foo.
ID: 9297 Updated by: cmv Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Strings related PHP Version: 4.0.4pl1 Assigned To: Comments: Works fine for me (RH7 and latest CVS): [cmv@sunniva cmv]$ echo '? $foo = 2.2864849511949E+190; settype($foo,double); printf(%fn, $foo) ?' | php X-Powered-By: PHP/4.0.6-dev Content-type: text/html 2286484951194899000n[cmv@sunniva cmv] Previous Comments: --- [2001-04-30 09:17:45] [EMAIL PROTECTED] Can you please try the latest CVS or a snapshot from snaps.php.net and let us know if this still happens. I can't reproduce it on redhat 6.2. Thanks. --- [2001-02-16 10:34:20] [EMAIL PROTECTED] [ben@home ben]$ echo '? $foo = 2.2864849511949E+190; settype($foo,double); printf(%fn, $foo) ?' | php X-Powered-By: PHP/4.0.4pl1 Content-type: text/html 2286484951194899000 Segmentation fault (core dumped) --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9297edit=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] 4.0.6
At 10:47 PM 4/30/2001 +0900, Rui Hirokawa wrote: No I don't see a problem with this but please do it quickly. 4.0.6 has already gone a long way since we started RC'ing 4.0.5 and I would like to start RC'ing it pretty soon. You should probably also copy dotnet/EXPERIMENTAL to your directory until it becomes completely stable. I did. By the way, do you think jstring is the right name? Is it only for Japanese? It includes some functions for japanese,but some functions are not only for japanese. For example, this module supports encoding conversion functionality between Unicode and some other encodings like ISO-8859-X. Currently, it includes encoding conversion filter for japanese and ISO-8859-X, but it is relatively easy task to add another conversion filter for some other language. I believe this module is small step for PHP internationalization. I think the name 'jstring' is right name now because it is existing for japanese string function now. But 'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name. jstring sounds very Java'ish :) I think a more descriptive name would be better especially if it is not Japanese specific. Let's wait and see what other people think. I'm very happy to see this code being merged into PHP 4. Many Japanese users have missed out on PHP 4 because these patches were mostly available for PHP 3. Andi -- 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] 4.0.6
recode is GPL'd IIRC and thus (your mileage may vary) not very usable, doesn't build on win32 systems, and the author has no interest in changing that. At 15:51 30.4. 2001, Stanislav Malyshev wrote the following: -- RH For example, this module supports encoding conversion RH functionality between Unicode and some other encodings like RH ISO-8859-X. Currently, it includes encoding conversion filter Doesn't this duplicate the GNU recode functionality? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] --end of quote-- [EMAIL PROTECTED] - And the eyes of them both were opened and they saw that their files were world readable and writable, so they chmoded 600 their files. - Book of Installation chapt 3 sec 7 -- PHP Development Mailing List 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] 4.0.6
On Mon, 30 Apr 2001 16:51:15 +0300 (IDT) Stanislav Malyshev [EMAIL PROTECTED] wrote: RH For example, this module supports encoding conversion RH functionality between Unicode and some other encodings like RH ISO-8859-X. Currently, it includes encoding conversion filter Doesn't this duplicate the GNU recode functionality? ext/jstring adds some unique functionalities as follows, - automatic encoding recognition functionality for japanese and Unicode encodings. - the output encoding translation using output buffering functionality. - adding encoding translation for HTTP input (POST/GET/Cookie). - adding multibyte compatible string functions like mbstrlen (multibyte enabled strlen()) These functionalities are not fully supported by ext/recode or ext/iconv. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] -- -- Rui Hirokawa [EMAIL PROTECTED] maintainer of japanese PHP manual [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] 4.0.6
On Mon, 30 Apr 2001, Rui Hirokawa wrote: On Mon, 30 Apr 2001 16:51:15 +0300 (IDT) Stanislav Malyshev [EMAIL PROTECTED] wrote: RH For example, this module supports encoding conversion RH functionality between Unicode and some other encodings like RH ISO-8859-X. Currently, it includes encoding conversion filter Doesn't this duplicate the GNU recode functionality? ext/jstring adds some unique functionalities as follows, - automatic encoding recognition functionality for japanese and Unicode encodings. - the output encoding translation using output buffering functionality. - adding encoding translation for HTTP input (POST/GET/Cookie). - adding multibyte compatible string functions like mbstrlen (multibyte enabled strlen()) These functionalities are not fully supported by ext/recode or ext/iconv. This seems like a very cool thing, however, I agree with Andi and others, jstring sounds very Java like to me also. perhaps: ext/wchar (wide character support?) ext/mstring (multibyte string functions) ext/jpstring (japanese string functions) -Sterling -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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]
[PHP-DEV] Re: Bug #10526 Updated: Possible problem with query
Well, I 'm not sure where the error message is comming from. It is an error being generated by either PHP or MySQL. I have figured out a way around the error, so it can be closed - but I never figured out what was causing the error. It is definately something that should be looked into because someone else may have more problems in the future. Matthew Grigajtis -- 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] 4.0.6
C recode is GPL'd IIRC and thus (your mileage may vary) not very C usable, doesn't build on win32 systems, and the author has no recode libs are LGPL, IIRC. As for win32, I don't know (not being user of such systems) but I guess since its functionality do not include anything that is unix-specific, it should build with little modification. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- 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] Logic in sapi/cgi/cgi_main.c
On Mon, 30 Apr 2001, Andi Gutmans wrote:
http://www.faqts.com/knowledge_base/view.phtml/aid/734/fid/37
It sounds to me that you are right. That should probably just be request_uri.
I thought many people have used this $PHP_SELF so it's kind of strange that
there haven't been a zillion complaints.
Does anyone object to changing this behavior?
You'd think one of the authors of the faqt would have filed a bug also...
Anyway, If no one objects by tonight, I'll go ahead make the change and
wait to be flamed ;)
-Sterling
Andi
At 01:56 PM 4/29/2001 -0400, Sterling Hughes wrote:
Can you give an example of how it looks with request_uri and how it looks
with both? Then it'll be easier for someone like me who doesn't know the
standard too well to check the PHP manual and the HTTP standard to see
what
the correct behavior should be.
Well, I can't really test this, as I don't have windows, but here's my
logic ;)
To quote the bug report ::
in your website such that it is contained somewhere within the subtree of
a directory
whose name ends with .php. For example, on my box I had the file
located at
http://site/php/secure.php/version.php
If you then look at the value of $PHP_SELF it is
/php/secure.php/php/secure.php/version.php
and NOT
/php/secure.php/version.php
as it should be.
::
This appears in what I assume is the CGI version (only place possible). I
then took a look at the code shown below. While most other sapi's
register only the request_uri (or something else, given by the server's
api itself), the code below provides an opportunity for the above
condition to occur, if SCRIPT_NAME is invalid, ie, it gets cut off too
soon, because of a odd directory name, then strcmp will not return the
correct results and request_uri will un-necessarily be appended
If you look at the first one, its with SCRIPT_NAME and
REQUEST_URI (invalid), the second one is just the value of REQUEST_URI
(valid)...
-Sterling
Andi
At 07:55 AM 4/29/2001 -0400, Sterling Hughes wrote:
I've taken a look at the code that registers $PHP_SELF in the CGI
version,
in accordance with bug 6491. I see the problem, its that on some server
OS combinations, the SCRIPT_NAME environment variable is incorrectly set
and therefore the below code exhibits the bug (the strcmp() should
avoid the request_uri being tagged on, but because the SCRIPT_NAME is
invalid, it doesn't happen the two don't match, and the REQUEST_URI is
incorrectly tagged on).
It seems like the logical fix to this would to be just registering the
REQUEST_URI as the PHP_SELF, however, I don't know this code to well,
could one of the authors explain the reasoning behind prepending the
SCRIPT_NAME when FORCE_CGI_REDIRECT is not enabled?
-Sterling
Related Code:
#if FORCE_CGI_REDIRECT
php_register_variable(PHP_SELF, (SG(request_info).request_uri ?
SG(request_info).request_uri:), track_vars_array ELS_CC PLS_CC);
#else
{
char *sn;
char *val;
int l=0;
sn = getenv(SCRIPT_NAME);
pi = SG(request_info).request_uri;
if (sn)
l += strlen(sn);
if (pi)
l += strlen(pi);
if (pi sn !strcmp(pi, sn)) {
l -= strlen(pi);
pi = NULL;
}
val = emalloc(l + 1);
sprintf(val, %s%s, (sn ? sn : ), (pi ? pi : )); /* SAFE */
php_register_variable(PHP_SELF, val, track_vars_array ELS_CC
PLS_CC);
efree(val);
}
#endif
--
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]
--
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] 4.0.6
At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote: ext/wchar (wide character support?) ext/mstring (multibyte string functions) ext/jpstring (japanese string functions) I'd make mstring - mbstring. The question is if it's worth splitting this up into more than one extension. Probably not. So we should probably be picking out of wchar, mbstring, jpstring. Rui, what do you think? Andi -- 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] 4.0.6
[Cynic [EMAIL PROTECTED]] recode is GPL'd IIRC and thus (your mileage may vary) not very usable, doesn't build on win32 systems, and the author has no interest in changing that. libiconv is pretty good too. I don't know if it builds on Win32 though. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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: Bug #10560 Updated: IISConfig Error
Does this error only have to do with the setup of MMC or does it effect more than that. I'm new to PHP so I can't tell yet if there is a problem. -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 8:48 AM To: [EMAIL PROTECTED] Subject: Bug #10560 Updated: IISConfig Error ID: 10560 Updated by: cynic Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Install and Config PHP Version: 4.0.4pl1 Assigned To: Comments: this is being solved right now and will be probably fixed in 4.0.6 Previous Comments: --- [2001-04-30 09:41:19] [EMAIL PROTECTED] During the install of PHP I recieved an error stating that the MSCOMCTL.OCX did not correctly register a file is missing or invalid. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10560edit=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] 4.0.6
On 30 Apr 2001, Stig Sæther Bakken wrote: [Cynic [EMAIL PROTECTED]] recode is GPL'd IIRC and thus (your mileage may vary) not very usable, doesn't build on win32 systems, and the author has no interest in changing that. libiconv is pretty good too. I don't know if it builds on Win32 though. It does. -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] 4.0.6
I'd make mstring - mbstring. The question is if it's worth splitting this up into more than one extension. Probably not. So we should probably be picking out of wchar, mbstring, jpstring. Rui, what do you think? I'm not Rui, but my vote would be for mbstring (or mb_string). If this handles any multi-byte character strings and Unicode, then it's going to be used for a lot more than Japanese strings. Hopefully, this will save me from porting String::Unicode into PHP. :) - Colin -- 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] Bug #10561: sockets.c uses `SUN_LEN' unconditionally - undefined on Solaris
From: [EMAIL PROTECTED] Operating system: Solaris 7 PHP version: 4.0.4pl1 PHP Bug Type: Compile Failure Bug description: sockets.c uses `SUN_LEN' unconditionally - undefined on Solaris Configured with nv 'CC=cc -mt' CFLAGS=-O CPPFLAGS='-D_XPG4_2 -D__EXTENSIONS__' ./configure --with-apxs=/usr/local/apache_1.3.19/bin/apxs --with-mysql=/usr/local/mysql --with-ldap=/usr/local/openldap --with-xml --enable-yp --enable-safe-mode --with-gd --with-jpeg-dir=/usr/local --with-pdflib --with-zlib --with-tiff-dir=/usr/local --with-openssl=/usr/local/openssl --enable-bcmath --with-bz2 --enable-calendar --enable-dbase --with-gdbm=/usr/local/gnu --with-ndbm --enable-ctype --with-db3=/usr/local/BerkeleyDB --with-dom --enable-exif --with-fdftk --enable-filepro --enable-ftp --enable-gd-imgstrttf --with-gd --with-gmp --with-hyperwave --with-imap-ssl --with-imap=/usr/local/src/pine4.30/imap --with-java=/usr/java --with-mcal --with-unixODBC=/usr/local/unixODBC --with-readline=/usr/local/gnu --with-mm --enable-trans-sid --enable-shmop --enable-sockets --with-regex=php --enable-sysvsem --enable-sysvshm --enable-wddx --with-zlib --enable-versioning --enable-track-vars --without-fdftk --without-mcal --with-xpm-dir=/usr/local/X11 Can be fixed with (I suspect this is going to get mangled in the post). diff -c -r1.1 sockets.c *** sockets.c 2001/04/19 10:04:11 1.1 --- sockets.c 2001/04/19 16:17:37 *** *** 66,71 --- 66,77 #endif #endif + /* ... or this */ + #ifndef SUN_LEN + #define SUN_LEN(sunp) ((size_t)((struct sockaddr_un *)0)-sun_path \ ++ strlen((sunp)-sun_path)) + #endif + /* Use the read() wrapper, stopping at '\n', '\r', or '\0'. */ #define PHP_NORMAL_READ 0x0001 /* Use the read() wrapper, but read until the entire buffer is filled. */ -- Edit Bug report at: http://bugs.php.net/?id=10561edit=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.ini location
Hi, The default location of php.ini in the current CVS seems to be /usr/local/etc. Didn't we say we're saving this one for 4.1.x? I just got bitten by this and I bet there will be a huge amount of people who will too. Andi -- 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] 4.0.6
On Mon, 30 Apr 2001 17:26:58 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote: ext/wchar (wide character support?) ext/mstring (multibyte string functions) ext/jpstring (japanese string functions) I'd make mstring - mbstring. The question is if it's worth splitting this up into more than one extension. Probably not. So we should probably be picking out of wchar, mbstring, jpstring. Rui, what do you think? I prefer unified approach is better for php-i18n than splitting some modules. I think mbstring is better, although this module also supports single-byte encoding like ISO-8859-X. Some people might say 'wchar' is better choise, because this module converts string to wide character internally. If someone want to add some other encoding support, he should add mbfilter_xx.c mbfilter_xx.h where xx means some specific language like ja (japanese). Anyway, because I am not original author of this module, I must discuss to Mr. Tsukada ,the original author of jstring about renaming the module. -- -- Rui Hirokawa [EMAIL PROTECTED] maintainer of japanese PHP manual [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] 4.0.6
At 12:23 AM 5/1/2001 +0900, Rui Hirokawa wrote: On Mon, 30 Apr 2001 17:26:58 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote: ext/wchar (wide character support?) ext/mstring (multibyte string functions) ext/jpstring (japanese string functions) I'd make mstring - mbstring. The question is if it's worth splitting this up into more than one extension. Probably not. So we should probably be picking out of wchar, mbstring, jpstring. Rui, what do you think? I prefer unified approach is better for php-i18n than splitting some modules. I think mbstring is better, although this module also supports single-byte encoding like ISO-8859-X. Some people might say 'wchar' is better choise, because this module converts string to wide character internally. If someone want to add some other encoding support, he should add mbfilter_xx.c mbfilter_xx.h where xx means some specific language like ja (japanese). Anyway, because I am not original author of this module, I must discuss to Mr. Tsukada ,the original author of jstring about renaming the module. OK. I think wchar or mbstring are both good. jstring will just confuse people. Andi -- 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] 4.0.6
Cynic wrote: recode is GPL'd IIRC and thus (your mileage may vary) not very usable, doesn't build on win32 systems, and the author has no interest in changing that. the recode command is under GPL while the library part is under LGPL so it's ok as it is license-wise (even RMS did not take the bait on it during the readline discussion) -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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] key_exists from php
On Sun, Apr 29, 2001 at 09:50:13PM -0400, David Croft wrote: There doesn't seem to be any way for a php script to determine whether a given key exists in an array. isset($arr['x']) fails when it exists but has a null value. I know there are ways around it like using foreach or array_keys but these don't seem very efficient. Wouldn't empty() handle that case? e.g.if (!empty($arr['x'])) echo $arr['x']; -- Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] 4.0.6
Andi Gutmans wrote: Can we make a list of things which still need to make it into 4.0.6 before we branch? i have started to create ext/saprfc that will interface with the ABAP/4 Remote Function Call mechanism in SAP R/3, but right now it only has a working configure script and no functionality within (making it even more useless than ext/rtfm for now) so i'll wait until 4.0.6 branches off before i add it ... -- Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 -- 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] Troubles with DL'ed module
Andi Gutmans wrote: Did you compile with debug on or off? Please try without debug in both PHP and your module and let us know if something changes. Also can you try and load it via php.ini (extension=module.so) and not with dl(). I rebuilt php 4.0.4p1 with debug off, rebuilt my module with debug off, and switched from using DL to the extension load in the php.ini. Unfortunately I still get the same coredump at the same line, just a different constant. As before I can step though it with the debugger and the address it cores in is viewable and has data. My gut is telling me its a build problem. Some address not aligned right or something. For example shouldn't the -KPIC have been used in the build argument list to libtool? But yet, in a seperate install without my new module the same version of php on the same machine is running in production very stable. Any ideas? Brian -- 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] Troubles with DL'ed module
One more strange behavior I just saw. Take this little script: ? phpinfo (); $tux = tux_tpalloc (TUX_FML32, , 5000); print $tux; tux_tpfree ($tux); print $tux; ? The tux_tpalloc and tux_free are new functions in my module. If I comment out everything but the phpinfo () and hit a fresh start of the web server, it will not core. My module is loaded because I see it in the phpinfo output. After that I can uncomment the rest of the script and it will NOT core. However if I just run this script right away from a fresh restart, it will coredump. Very strange... Brian -- 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] Troubles with DL'ed module
Your module is probably causing some memory corruption. The best way to debug it is building the module statically into PHP. You need to copy it to ext/your_module/ (assuming you have a standard config.m4). Then in php4/ run ./buildconf and you should see your module when you do ./configure --help. ./configure and compile PHP with your module statically (best is even as a CGI) and then you can really debug it and see if it's a problem with the build as a shared library or if you have some bugs. Andi At 11:01 AM 4/30/2001 -0500, Brian Foddy wrote: Andi Gutmans wrote: Did you compile with debug on or off? Please try without debug in both PHP and your module and let us know if something changes. Also can you try and load it via php.ini (extension=module.so) and not with dl(). I rebuilt php 4.0.4p1 with debug off, rebuilt my module with debug off, and switched from using DL to the extension load in the php.ini. Unfortunately I still get the same coredump at the same line, just a different constant. As before I can step though it with the debugger and the address it cores in is viewable and has data. My gut is telling me its a build problem. Some address not aligned right or something. For example shouldn't the -KPIC have been used in the build argument list to libtool? But yet, in a seperate install without my new module the same version of php on the same machine is running in production very stable. Any ideas? Brian -- 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] Troubles with DL'ed module
On Mon, 30 Apr 2001, Andi Gutmans wrote: Your module is probably causing some memory corruption. The best way to debug it is building the module statically into PHP. You need to copy it to ext/your_module/ (assuming you have a standard config.m4). Then in php4/ run ./buildconf and you should see your module when you do ./configure --help. ./configure and compile PHP with your module statically (best is even as a CGI) and then you can really debug it and see if it's a problem with the build as a shared library or if you have some bugs. also, configuring with --enable-debug often helps... -Sterling Andi At 11:01 AM 4/30/2001 -0500, Brian Foddy wrote: Andi Gutmans wrote: Did you compile with debug on or off? Please try without debug in both PHP and your module and let us know if something changes. Also can you try and load it via php.ini (extension=module.so) and not with dl(). I rebuilt php 4.0.4p1 with debug off, rebuilt my module with debug off, and switched from using DL to the extension load in the php.ini. Unfortunately I still get the same coredump at the same line, just a different constant. As before I can step though it with the debugger and the address it cores in is viewable and has data. My gut is telling me its a build problem. Some address not aligned right or something. For example shouldn't the -KPIC have been used in the build argument list to libtool? But yet, in a seperate install without my new module the same version of php on the same machine is running in production very stable. Any ideas? Brian -- 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]
[PHP-DEV] PHP 4.0 Bug #10513 Updated: configure fails when I include Oracle 8.1.7
ID: 10513 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Description: configure fails when I include Oracle 8.1.7 I've got round this problem by loading a new version from snaps.php.net called php4-200104270145. Thanks. Previous Comments: --- [2001-04-26 12:38:37] [EMAIL PROTECTED] configure fails when I include Oracle 8.1.7. I set both vars below and exported them fist. ORACLE_HOME=/o8/product/8.1.7 LD_LIBRARY_PATH=/o8/product/8.1.7/lib I've also tried this with PHP3 and fails during 'make' with a similar message about core4 and nlsrtl3. The contents of debug.log is below. CONFIGURE: './configure' '--without-mysql' '--with-oracle' '--with-apache=../apache_1.3.19' '--enable-track-vars' CC: cc CFLAGS: -g CPPFLAGS: CXX: CXXFLAGS: INCLUDES:-I/ora4/test/apache_1.3.19/src/include -I/ora4/test/apache_1.3.19/src/os/unix -I$(top_builddir)/Zend -I/o8/product/8.1.7/rdbms/public -I/o8/product/8.1.7/rdbms/demo LDFLAGS: -R/o8/product/8.1.7/lib -L/o8/product/8.1.7/lib LIBS: -lclntsh -lpsa -lcore4 -lnlsrtl3 -lld -lbsd_r -lm -lodm -ldl -lbind -lm -ldl -lcrypt DLIBS: SAPI: apache PHP_RPATHS: /o8/product/8.1.7/lib uname -a: AIX welwyn 3 4 00089E3DA100 cc -o conftest -g -R/o8/product/8.1.7/lib -L/o8/product/8.1.7/lib conftest.c -lclntsh -lpsa -lcore4 -lnlsrtl3 -lld -lbsd_r -lm -lodm -ldl -lbind -lm -ldl -lcrypt 15 ld: 0706-027 The -R /o8/product/8.1.7/lib flag is ignored. ld: 0706-006 Cannot find or open library file: -l core4 ld:open(): No such file or directory ld: 0706-006 Cannot find or open library file: -l nlsrtl3 ld:open(): No such file or directory --- Full Bug description available at: http://bugs.php.net/?id=10513 -- 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] Troubles with DL'ed module
Sounds like some kind of memory corruption. With these kind of problems even the order of statements can make a difference. Do you want to post those two functions and we can take a look at them? Also are your RINIT() MINIT() functions doing anything? Maybe they are causing problems? Andi At 11:17 AM 4/30/2001 -0500, Brian Foddy wrote: One more strange behavior I just saw. Take this little script: ? phpinfo (); $tux = tux_tpalloc (TUX_FML32, , 5000); print $tux; tux_tpfree ($tux); print $tux; ? The tux_tpalloc and tux_free are new functions in my module. If I comment out everything but the phpinfo () and hit a fresh start of the web server, it will not core. My module is loaded because I see it in the phpinfo output. After that I can uncomment the rest of the script and it will NOT core. However if I just run this script right away from a fresh restart, it will coredump. Very strange... Brian -- 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] 4.0.6
On Mon, Apr 30, 2001 at 10:47:21PM +0900, Rui Hirokawa wrote: On Mon, 30 Apr 2001 15:37:14 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: At 09:35 PM 4/30/2001 +0900, Rui Hirokawa wrote: Andi, We have plan to add ext/jstring which is a japanese string extension module to php-4.0.6. Is there any problem to add this module on CVS tree now ? No I don't see a problem with this but please do it quickly. 4.0.6 has already gone a long way since we started RC'ing 4.0.5 and I would like to start RC'ing it pretty soon. You should probably also copy dotnet/EXPERIMENTAL to your directory until it becomes completely stable. I did. By the way, do you think jstring is the right name? Is it only for Japanese? It includes some functions for japanese,but some functions are not only for japanese. For example, this module supports encoding conversion functionality between Unicode and some other encodings like ISO-8859-X. Currently, it includes encoding conversion filter for japanese and ISO-8859-X, but it is relatively easy task to add another conversion filter for some other language. I believe this module is small step for PHP internationalization. I think the name 'jstring' is right name now because it is existing for japanese string function now. But 'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name. It would be very good to join this features with existing iconv extension rather than generate new extensions. -- Sincerely yours, Alexander Bokovoy The Midgard Project| ALT Linux Team | Minsk Linux Users Group www.midgard-project.org | www.altlinux.ru |www.minsk-lug.net -- You won't skid if you stay in a rut. -- Frank Hubbard -- PHP Development Mailing List 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] Bug #10526 Updated: Possible problem with query
ID: 10526 Updated by: cardinal Reported By: [EMAIL PROTECTED] Old-Status: Feedback Status: Closed Bug Type: MySQL related PHP Version: 4.0.4pl1 Assigned To: Comments: User feedback: Well, I'm not sure where the error message is comming from. It is an error being generated by either PHP or MySQL. I have figured out a way around the error, so it can be closed - but I never figured out what was causing the error. It is definately something that should be looked into because someone else may have more problems in the future. Previous Comments: --- [2001-04-29 22:23:04] [EMAIL PROTECTED] I can't locate any error message in PHP that says Query was empty. Is it an error being displayed by your script, or one that your script calls upon? This can probably be closed. --- [2001-04-27 11:37:08] [EMAIL PROTECTED] Okay, I think I found a bug so please don't chew my head off if I'm wrong. I have written a short script to convert an excel spreadsheet into MySQL. Text format of course. I try to create a table using these lines: $query = CREATE TABLE test3 (Sales_Number varchar(255), Sales_Name varchar(255), Location varchar(255), Amount varchar(255)); $result = mysql_query ($query); It creates the table, but it stops the script with this error message: Query was empty I have never seen this error message before, and I don't think the query is empty because it does create the table... If you want me to email you the script for further analysis, please let me know. Matthew Grigajtis --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10526edit=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] Bug #10564: feof bug isn't fixed in windows versions.
From: [EMAIL PROTECTED]
Operating system: win NT 4.0
PHP version: 4.0.4pl1
PHP Bug Type: *Function Specific
Bug description: feof bug isn't fixed in windows versions.
while (!feof($sock)) {
echo fgets ($sock, 128);
}
fclose ($sock);
This hangs forever, even though remote end closes connection
within 120 miliseconds. this is a known bug (discussed on the list), but the fix
apperently didn't make it into the prepackaged windows release. Please do let me know
when this is fixed, for i need it more than i need cocaine (and i really really need
cocaine) thank you.
--
Edit Bug report at: http://bugs.php.net/?id=10564edit=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] Question
I have developed an extension, and am wondering to whom or where I submit it for review? -- 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
What is doing your extension? -- alex On Mon, 30 Apr 2001, Billy Rose wrote: I have developed an extension, and am wondering to whom or where I submit it for review? -- 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]
[PHP-DEV] RE: RE: Question
It is a front end to the Verity K2 Search Engine toolkit so that PHP script can run Verity searches. -- 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] I have libtool version 1.4 and buildconf script refuses to run
I have libtool version 1.4 and buildconf script refuses to run, it says: lexington# ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.4 found. You need libtool version 1.3.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 This has got to be a bug, any suggestions on a work-around? -Mark -- 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] XML/EXPAT patches for empty elements
Hi! The problem is: expat parser produces no reports on the score of situation when the document contains img .../ body .../ etc. tags where there is no data and end tag. So, the workaround was to add a new function to expat, which is called by the PHP parser every time for empty entries when the end tag handler function launches (BEFORE THE END TAG HANDLER!!). This avoids the situation of img/img in resulting HTML. I've uploaded patches for current PHP(CVS) and expat(CVS) versions to a href=http://www.legko.ru/Soft target=Softhttp://www.legko.ru/Soft/a Have a nice day! -- 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] If Interested..
Here's the URL's if anyone wants to have a look... http://www.billyrose.org/verity.c http://www.billyrose.org/php_verity.h http://www.billyrose.org/REFERENCE -- 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] Troubles with DL'ed module
I'm going to try and build it statically first. I don't have any problem posting the code (its already avail on sourceforge but you will need some proprietary libraries to build it). The MINIT and/or RINIT is the constants are initialized. You've given me some to go on, I'll work with it for a day or so first. Thanks, Brian Andi Gutmans wrote: Sounds like some kind of memory corruption. With these kind of problems even the order of statements can make a difference. Do you want to post those two functions and we can take a look at them? Also are your RINIT() MINIT() functions doing anything? Maybe they are causing problems? Andi At 11:17 AM 4/30/2001 -0500, Brian Foddy wrote: One more strange behavior I just saw. Take this little script: ? phpinfo (); $tux = tux_tpalloc (TUX_FML32, , 5000); print $tux; tux_tpfree ($tux); print $tux; ? The tux_tpalloc and tux_free are new functions in my module. If I comment out everything but the phpinfo () and hit a fresh start of the web server, it will not core. My module is loaded because I see it in the phpinfo output. After that I can uncomment the rest of the script and it will NOT core. However if I just run this script right away from a fresh restart, it will coredump. Very strange... Brian -- 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]
[PHP-DEV] Imap SSL support (Bug #10330)
The imap module fails with the following (perhaps only when building against imap-2000*): php_imap.c: In function `php_minit_imap': php_imap.c:450: `auth_ssl' undeclared (first use in this function) php_imap.c:450: (Each undeclared identifier is reported only once php_imap.c:450: for each function it appears in.) The solution is to rebuild the imap c-client library with something resembling make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=/path/to/openssl/includes/ This just failed for me on 4.0.5-RC8 and imap-2000c. I never built imap in this manner previously, and the php-imap module has never failed on releases prior to the 4.0.5-RC's, as they don't look for an auth_ssl function in the c-client library. Thanks! Jeremy -- 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] Imap SSL support (Bug #10330)
On Mon, Apr 30, 2001 at 01:22:32PM -0500, J. Jones wrote: make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=/path/to/openssl/includes/ Whoops! make that make slx SPECIALAUTHENTICATORS=ssl EXTRACFLAGS=-I/path/to/openssl/includes/ -- 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] ODBC Build
Can you please look at the patch in bug http://www.php.net/bugs.php?id=10563 and commit it if its needed/comment on the bug. thanks - James -- James Moore [EMAIL PROTECTED] http://www.perl.com/search/index.php - we must be doing somthing right -- 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 #10497 Updated: Not connect with MySql
ID: 10497 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Old-Bug Type: MySQL related Bug Type: Filesystem function related Description: Not connect with MySql this script don't work ? $file=fopen (ftp://user:password@localhost/administrador/servicios.inc,w;); fputs($file,Algo); fclose($file); ? Previous Comments: --- [2001-04-29 04:57:52] [EMAIL PROTECTED] The error message 'Maximum execution time of 30 seconds exceeded' doesn't need to be related to MySQL, as it just says that your script's running time is longer than allowed. Do you get, apart from that, any error message that indicates a relation to MySQL? On first look your code looks okay, could it be that your query just consumes much time? --- [2001-04-25 16:52:29] [EMAIL PROTECTED] this is the error: Fatal error: Maximum execution time of 30 seconds exceeded in D:Mis DocumentosWebtempok.php on line 2 and this is the script in php: ? $db = mysql_connect(localhost,root); mysql_select_db(portal,$db); $query = select hora from noticias order by fecha; $r_noticias = mysql_query($query); $rw_noticias = mysql_numrows($r_noticias); if ($rw_noticias) while($a_noticias = mysql_fetch_array($r_noticias)) $hora= $a_noticias[hora]; ... ? ok. thanks. --- [2001-04-25 16:27:44] [EMAIL PROTECTED] user feedback: this is the error: Fatal error: Maximum execution time of 30 seconds exceeded in D:Mis DocumentosWebtempok.php on line 2 and this is the script: ? $db = mysql_connect(localhost,root); mysql_select_db(portal,$db); $query = select hora from noticias order by fecha; $r_noticias = mysql_query($query); $rw_noticias = mysql_numrows($r_noticias); if ($rw_noticias) while($a_noticias = mysql_fetch_array($r_noticias)) $hora= $a_noticias[hora]; ... ? please, use the web interface for future updates --- [2001-04-25 15:56:20] [EMAIL PROTECTED] ah, right: this worked in 4.0.3 but doesn't work in 4.0.4 pl1, right? what error message do you get? --- [2001-04-25 15:54:35] [EMAIL PROTECTED] please report bugs in English. --- 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=10497 -- 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 #10497 Updated: Not connect with MySql
ID: 10497 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Filesystem function related Description: Not connect with MySql this script don't work ? $file=fopen(ftp://user:password@localhost/administrador/servicios.inc,w;); fputs($file,Algo); fclose($file); ? Previous Comments: --- [2001-04-30 14:49:20] [EMAIL PROTECTED] this script don't work ? $file=fopen (ftp://user:password@localhost/administrador/servicios.inc,w;); fputs($file,Algo); fclose($file); ? --- [2001-04-29 04:57:52] [EMAIL PROTECTED] The error message 'Maximum execution time of 30 seconds exceeded' doesn't need to be related to MySQL, as it just says that your script's running time is longer than allowed. Do you get, apart from that, any error message that indicates a relation to MySQL? On first look your code looks okay, could it be that your query just consumes much time? --- [2001-04-25 16:52:29] [EMAIL PROTECTED] this is the error: Fatal error: Maximum execution time of 30 seconds exceeded in D:Mis DocumentosWebtempok.php on line 2 and this is the script in php: ? $db = mysql_connect(localhost,root); mysql_select_db(portal,$db); $query = select hora from noticias order by fecha; $r_noticias = mysql_query($query); $rw_noticias = mysql_numrows($r_noticias); if ($rw_noticias) while($a_noticias = mysql_fetch_array($r_noticias)) $hora= $a_noticias[hora]; ... ? ok. thanks. --- [2001-04-25 16:27:44] [EMAIL PROTECTED] user feedback: this is the error: Fatal error: Maximum execution time of 30 seconds exceeded in D:Mis DocumentosWebtempok.php on line 2 and this is the script: ? $db = mysql_connect(localhost,root); mysql_select_db(portal,$db); $query = select hora from noticias order by fecha; $r_noticias = mysql_query($query); $rw_noticias = mysql_numrows($r_noticias); if ($rw_noticias) while($a_noticias = mysql_fetch_array($r_noticias)) $hora= $a_noticias[hora]; ... ? please, use the web interface for future updates --- [2001-04-25 15:56:20] [EMAIL PROTECTED] ah, right: this worked in 4.0.3 but doesn't work in 4.0.4 pl1, right? what error message do you get? --- 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=10497 -- 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.ini location
[Andi Gutmans [EMAIL PROTECTED]] Hi, The default location of php.ini in the current CVS seems to be /usr/local/etc. Didn't we say we're saving this one for 4.1.x? I just got bitten by this and I bet there will be a huge amount of people who will too. I'll change it back. - Stig -- Stig Sæther Bakken [EMAIL PROTECTED] Fast Search Transfer ASA, Trondheim, Norway -- 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 Bug #8889 Updated: Memory is not being freed.
The big problem is that the memory is never returned to the system. The
Apache process holds on to it until it dies.
Brian Moon
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
-
Look for my presentation at ApacheCon 2001.
Caching Dynamic Web Content to Increase Dependability and Performance
http://www.apachecon.com/
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, April 30, 2001 1:45 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
14MB of memory in use isn't necessarily that much. Some of that memory
might be in shared libraries (shared across the Apache processes). Are you
doing any big SQL queries in those scripts?
Do you have time to do some tests and let us know if things improve?
Andi
At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.
I am talking about nearly endless amounts. I saw Apache processes with
as
much as 14MB of memory in use.
Brian.
Previous Comments:
---
[2001-04-29 19:59:56] [EMAIL PROTECTED]
What kind of sizes are we talking about here? the Zend memory manager
holds a memory cache, but we're talking at around 1MB per process max.
---
[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-devm=97923602322593w=2 which
contains a hacked up solution. It looks like it should be able to turn
into a usable end solution.
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes memory
is
growing by the minute. If I start a separate server on another port and
serve only static pages and files through it, those process do not grow.
I have tried what I remembered of gdb but have not come up with
anything. I know I need to attach to a process and it seems I can `gdb
{pid}` but that gives me nothing. How can I get some info for you
guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
Full Bug description available at: http://bugs.php.net/?id=8889
--
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]
[PHP-DEV] Bug #10070 Updated: incorrect ob_gzhandler implementation
ID: 10070 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Zlib Related PHP Version: 4.0 Latest CVS (29/03/2001) Assigned To: Comments: This should have been resolved with various patches that have been added recently, please test with latest CVS and reopen if this is not the case. (Although once again can we really write workarounds for every browser that breaks the standards?) - James Previous Comments: --- [2001-04-02 00:53:35] [EMAIL PROTECTED] IIRC, it advertises both, so it shouldn't be an issue. I don't have a windows box around to make sure with... --- [2001-03-30 19:45:38] [EMAIL PROTECTED] 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 --- [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, --- 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=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 Bug #8889 Updated: Memory is not being freed.
Memory is never returned to the system with libc memory allocation.
When you need memory it enlarges the address space it is using. Freeing
memory won't make it shrink its address space.
All I can suggest is to write your scripts in a way that if it deals with
many SQL queries free a query before you do the next. This way the maximum
size of your scripts memory space will hopefully be smaller.
Andi
At 02:37 PM 4/30/2001 -0500, Brian Moon wrote:
The big problem is that the memory is never returned to the system. The
Apache process holds on to it until it dies.
Brian Moon
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
-
Look for my presentation at ApacheCon 2001.
Caching Dynamic Web Content to Increase Dependability and Performance
http://www.apachecon.com/
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, April 30, 2001 1:45 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
14MB of memory in use isn't necessarily that much. Some of that memory
might be in shared libraries (shared across the Apache processes). Are you
doing any big SQL queries in those scripts?
Do you have time to do some tests and let us know if things improve?
Andi
At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.
I am talking about nearly endless amounts. I saw Apache processes with
as
much as 14MB of memory in use.
Brian.
Previous Comments:
---
[2001-04-29 19:59:56] [EMAIL PROTECTED]
What kind of sizes are we talking about here? the Zend memory manager
holds a memory cache, but we're talking at around 1MB per process max.
---
[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-devm=97923602322593w=2 which
contains a hacked up solution. It looks like it should be able to turn
into a usable end solution.
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes memory
is
growing by the minute. If I start a separate server on another port and
serve only static pages and files through it, those process do not grow.
I have tried what I remembered of gdb but have not come up with
anything. I know I need to attach to a process and it seems I can `gdb
{pid}` but that gives me nothing. How can I get some info for you
guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
Full Bug description available at: http://bugs.php.net/?id=8889
--
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]
[PHP-DEV] Bug #10557 Updated: php does not work with php_mcrypt.dll
ID: 10557 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Duplicate Status: Bogus Bug Type: mcrypt related PHP Version: 4.0.4 Assigned To: Comments: submitted twice (#10556) Previous Comments: --- [2001-04-30 02:02:51] [EMAIL PROTECTED] I am using a windows 98 machine. I have installed php 4.0.4 using the easy installer for windows. I downloaded the php_mcrypt.dll file fromhttp://www.multimedia.uni-greifswald.de/~php4. When i tried to run the test program I got the following error. unable to load php_mcrypt.dll.The other dll's like php_gd.dll are working.Please help me out. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10557edit=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] Bug #10453 Updated: mod_auth_mysql and php4.0.5pl1
ID: 10453 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Apache related PHP Version: 4.0.4pl1 Assigned To: Comments: You have to use the external mysql client libraries when you have some other modules in Apache that use mysql. ie. configure --with-mysql=/path/to/mysql (remember to delete config.cache first!) And do 'make clean' after configure. There is no bugs in PHP regarding this issue. I myself use mod_auth_mysql with latest PHP (4.0.5) without any problems. Ask further questions on [EMAIL PROTECTED] --Jani Previous Comments: --- [2001-04-30 04:09:04] [EMAIL PROTECTED] I am using mysql and the mod_auth_mysql for a long time with older versions of php without problem. All mysql-Operations still work as before. It seems to me that the autorization information (name/passwd) don't get passsed over ... I tried to recompile with different paths in all modules but it did not work upto now. So I still use an older php module... --- [2001-04-23 07:16:51] [EMAIL PROTECTED] What was your configure line? You need to give the dir to your mysql libraries of you use other modules for apache that use MySQL. Like (Example): ./configure --with-mysql=/usr/local --- [2001-04-23 07:16:35] [EMAIL PROTECTED] What was your configure line? You need to give the dir to your mysql libraries of you use other modules for apache that use MySQL. Like (Example): ./configure --with-mysql=/usr/local --- [2001-04-23 06:47:48] [EMAIL PROTECTED] I recompiled my Apache as follows: apache_1.3.19 php-4.0.4pl1 mysql-3.22.26a mod_auth_mysql-2.20 Is there any known bug in the interoperability of these modules? php works fine, but the mod_auth_mysql module gives an internal error AFTER login: Could not load complete page - and nothing shows up. Regards, Rupert Mohr --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10453edit=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] Bug #7016 Updated: Error when starting iPlanet
ID: 7016 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: iPlanet related PHP Version: 4.0.2 Assigned To: Comments: status - feedback Previous Comments: --- [2001-04-30 04:43:38] [EMAIL PROTECTED] Try the following obj.conf entry, and see if it fixes your problem. Apart from this change, you should follow the manual entry for the rest of the obj.conf Init fn=load-modules shlib=/path/to/server4/bin/libphp4.so funcs=php4_init,php4_close,php4_execute,php4_auth_trans Init fn=php4_init LateInit=yes --- [2000-11-03 21:01:15] [EMAIL PROTECTED] reclassified --- [2000-10-04 12:41:54] [EMAIL PROTECTED] This is the error I got when restarting iPlanet via command line after installing PHP4 w/o any errors showing up: conf_init: Error running init function load-modules: dlopen of /usr/netscape/server/bin/libphp4.so failed (ld.so.1: ns-httpd: fatal: relocation error: file /usr/netscape/server/bin/libphp4.so: symbol __pure_virtual: referenced symbol not found) Can you give me an ideas on what's going on here? Thanks. We're using the GCC2.95.2 also. After configure, make and make install, these are the steps I did: 1. add the ff line in mime.types type=magnus-internal/x-httpd-phpexts=php 2. edit obj.conf # note place following two lines after mime types init! Init fn=load-modules funcs=php4_init,php4_close,php4_execute,php4_auth_trans shlib=/usr/netscape/server/bin/libphp4.so Init fn=php4_init errorString=Failed to initialize PHP! Object name=default . . . # NOTE this next line should happen after all 'ObjectType' and before all 'AddLog' lines Service fn=php4_execute type=magnus-internal/x-httpd-php . . /Object Object name=x-httpd-php ObjectType fn=force-type type=magnus-internal/x-httpd-php Service fn=php4_execute /Object Are these correct? Thanks, Lester --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7016edit=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] 4.0.6
On Mon, 30 Apr 2001 18:27:26 +0300 Andi Gutmans wrote: At 12:23 AM 5/1/2001 +0900, Rui Hirokawa wrote: On Mon, 30 Apr 2001 17:26:58 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote: ext/wchar (wide character support?) ext/mstring (multibyte string functions) ext/jpstring (japanese string functions) I'd make mstring - mbstring. The question is if it's worth splitting this up into more than one extension. Probably not. So we should probably be picking out of wchar, mbstring, jpstring. Rui, what do you think? I prefer unified approach is better for php-i18n than splitting some modules. I think mbstring is better, although this module also supports single-byte encoding like ISO-8859-X. Some people might say 'wchar' is better choise, because this module converts string to wide character internally. If someone want to add some other encoding support, he should add mbfilter_xx.c mbfilter_xx.h where xx means some specific language like ja (japanese). Anyway, because I am not original author of this module, I must discuss to Mr. Tsukada ,the original author of jstring about renaming the module. OK. I think wchar or mbstring are both good. jstring will just confuse people. I think mbstring is nice. Takuya Tsukada -- 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] Bug #10565: mysql_real_connect dumps core, fix included
From: [EMAIL PROTECTED] Operating system: SCO OpenServer 5.0.6 PHP version: 4.0.4pl1 PHP Bug Type: MySQL related Bug description: mysql_real_connect dumps core, fix included ** This is a problem in MySql. This report provides a code modification to compensate for the MySql problem. ** Under SCO OpenServer 5.0.6, Apache 1.3.19, PHP 4.0.4 PL 1, and MySql 3.23.36 (precompiled MySQL for OpenServer 5.0.x), calls to mysql_real_connect will silently dump core if mysql_init was not allowed to *allocate* the memory for the MySQL structure. To function properly, mysql_init must be passed NULL, thus allowing it to allocate and manage the memory. If you use a previously malloc()'ed or static structure, MySQL will dump core on connect. We find this problem to be present in MySQL, and can duplicate it using a C code stub. The problem, of course, also exists in PHP, causing a core dump there as well, since PHP pre-malloc()'s its own structure. Here is a DIFF for ext/mysql/php_mysql.c which fixes the problem for us. It's ugly, and hack-y, but it works. FYI. 198c198 efree(link); --- /* efree(link); */ 456c456 mysql = (MYSQL *) malloc(sizeof(MYSQL)); --- /* mysql = (MYSQL *) malloc(sizeof(MYSQL)); */ 458c458 mysql_init(mysql); --- mysql = mysql_init(NULL); 542c542 mysql = (MYSQL *) emalloc(sizeof(MYSQL)); --- /* mysql = (MYSQL *) emalloc(sizeof(MYSQL)); */ 544c544 mysql_init(mysql); --- mysql = mysql_init(NULL); -- Edit Bug report at: http://bugs.php.net/?id=10565edit=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] Bug #10566: don't work properly fopen
From: [EMAIL PROTECTED] Operating system: Windows NT/ Unix FreeBSD PHP version: 4.0.4pl1 PHP Bug Type: Filesystem function related Bug description: don't work properly fopen this scrip don't work properly: (only the first time, that's ok) ? $file=fopen(ftp://usr:pass@localhost/administrador/servicios5.inc,w;); fputs($file,Algo); fclose($file); ? this the warning: Warning: File already exists in generaservicios.inc on line 1 Warning: fopen(ftp://...@localhost/administrador/servicios5.inc,w;) - File exists in generaservicios.inc on line 1 Warning: Supplied argument is not a valid File-Handle resource in generaservicios.inc on line 2 Warning: Supplied argument is not a valid File-Handle resource in generaservicios.inc on line 97 -- Edit Bug report at: http://bugs.php.net/?id=10566edit=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] Bug #10538 Updated: mcrypt_generic_init truncates key/iv upon first '\0'
ID: 10538
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: mcrypt related
PHP Version: 4.0.4pl1
Assigned To: derick
Comments:
It's fixed in CVS as you say (and it is fixed in 4.0.5 too BTW_
Previous Comments:
---
[2001-04-30 05:43:16] [EMAIL PROTECTED]
Seems to be a duplicate of Bug #8839 and it is already fixed in CVS.
---
[2001-04-28 12:50:42] [EMAIL PROTECTED]
Same happens in mcrypt_ecb, mcrypt_cbc, mcrypt_cfb and mcrypt_ofb too.
Script showing the bug:
?php
$key1 = pack(H*, FF00FF0
0);
$key2 = pack(H*, FF0
0);
$iv= pack(H*, );
$plain = pack(H*, );
$handle = mcrypt_module_open(MCRYPT_TWOFISH, , MCRYPT_MODE_CFB, );
mcrypt_generic_init($handle, $key1, $iv);
$crypted1 = mcrypt_generic($handle, $plain);
mcrypt_generic_end($handle);
$handle = mcrypt_module_open(MCRYPT_TWOFISH, , MCRYPT_MODE_CFB, );
mcrypt_generic_init($handle, $key2, $iv);
$crypted2 = mcrypt_generic($handle, $plain);
mcrypt_generic_end($handle);
print bin2hex($plain).nn;
print bin2hex($crypted1).nn;
print bin2hex($crypted2).nn;
?
The two ciphertexts should NOT be the same as the key is different.
Proposed patch (also fixes a possible memory access problem, but only for the
mcrypt_generic_init function, the I didn't fully understand php_mcrypt_do_crypt yet,
when I do I will update the patch, see also Bug #10518):
--- php-4.0.4pl1/ext/mcrypt/mcrypt.cWed Nov 22 22:40:15 2000
+++ php-4.0.4pl1-sk/ext/mcrypt/mcrypt.c Sat Apr 28 18:53:07 2001
@@ -463,14 +463,22 @@
Z_STRLEN_PP(key), key_size);
php_error (E_NOTICE, dummy);
}
- strncpy (key_s, Z_STRVAL_PP(key), key_size);
+ if (Z_STRLEN_PP(key) key_size) {
+ memcpy (key_s, Z_STRVAL_PP(key), key_size);
+ } else {
+ memcpy (key_s, Z_STRVAL_PP(key), Z_STRLEN_PP(key));
+ }
if (Z_STRLEN_PP(iv) != iv_size) {
sprintf (dummy, iv size incorrect; supplied length: %d, needed: %d,
Z_STRLEN_PP(iv), iv_size);
php_error (E_WARNING, dummy);
}
- strncpy (iv_s, Z_STRVAL_PP(iv), iv_size);
+ if (Z_STRLEN_PP(iv) iv_size) {
+ memcpy (iv_s, Z_STRVAL_PP(iv), iv_size);
+ } else {
+ memcpy (iv_s, Z_STRVAL_PP(iv), Z_STRLEN_PP(iv));
+ }
RETVAL_LONG (mcrypt_generic_init (td, key_s, key_size, iv_s));
efree (iv_s);
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10538edit=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] 4.0.6
At 05:56 AM 5/1/2001 +0900, [EMAIL PROTECTED] wrote: On Mon, 30 Apr 2001 18:27:26 +0300 Andi Gutmans wrote: At 12:23 AM 5/1/2001 +0900, Rui Hirokawa wrote: On Mon, 30 Apr 2001 17:26:58 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: At 10:01 PM 4/29/2001 -0400, Sterling Hughes wrote: ext/wchar (wide character support?) ext/mstring (multibyte string functions) ext/jpstring (japanese string functions) I'd make mstring - mbstring. The question is if it's worth splitting this up into more than one extension. Probably not. So we should probably be picking out of wchar, mbstring, jpstring. Rui, what do you think? I prefer unified approach is better for php-i18n than splitting some modules. I think mbstring is better, although this module also supports single-byte encoding like ISO-8859-X. Some people might say 'wchar' is better choise, because this module converts string to wide character internally. If someone want to add some other encoding support, he should add mbfilter_xx.c mbfilter_xx.h where xx means some specific language like ja (japanese). Anyway, because I am not original author of this module, I must discuss to Mr. Tsukada ,the original author of jstring about renaming the module. OK. I think wchar or mbstring are both good. jstring will just confuse people. I think mbstring is nice. Sounds good. Andi -- 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 Bug #8889 Updated: Memory is not being freed.
This is the answer I had previously received. IMHO, this sucks. We don't
do SQL queries on our production site. It is all cached. So, SQL is not
the problem. It is most likely because of the storage of large arrays or
something of that nature.
I guess we will continue to use MaxRequestsPerChild until one day the people
that wrote that memory allocation system get a clue.
Brian Moon
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
-
Look for my presentation at ApacheCon 2001.
Caching Dynamic Web Content to Increase Dependability and Performance
http://www.apachecon.com/
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, April 30, 2001 2:54 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
Memory is never returned to the system with libc memory allocation.
When you need memory it enlarges the address space it is using. Freeing
memory won't make it shrink its address space.
All I can suggest is to write your scripts in a way that if it deals with
many SQL queries free a query before you do the next. This way the maximum
size of your scripts memory space will hopefully be smaller.
Andi
At 02:37 PM 4/30/2001 -0500, Brian Moon wrote:
The big problem is that the memory is never returned to the system. The
Apache process holds on to it until it dies.
Brian Moon
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
-
Look for my presentation at ApacheCon 2001.
Caching Dynamic Web Content to Increase Dependability and Performance
http://www.apachecon.com/
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, April 30, 2001 1:45 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
freed.
14MB of memory in use isn't necessarily that much. Some of that memory
might be in shared libraries (shared across the Apache processes). Are
you
doing any big SQL queries in those scripts?
Do you have time to do some tests and let us know if things improve?
Andi
At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.
I am talking about nearly endless amounts. I saw Apache processes
with
as
much as 14MB of memory in use.
Brian.
Previous Comments:
---
[2001-04-29 19:59:56] [EMAIL PROTECTED]
What kind of sizes are we talking about here? the Zend memory
manager
holds a memory cache, but we're talking at around 1MB per process
max.
---
[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-devm=97923602322593w=2 which
contains a hacked up solution. It looks like it should be able to
turn
into a usable end solution.
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes
memory
is
growing by the minute. If I start a separate server on another port
and
serve only static pages and files through it, those process do not
grow.
I have tried what I remembered of gdb but have not come up with
anything. I know I need to attach to a process and it seems I can
`gdb
{pid}` but that gives me nothing. How can I get some info for you
guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
Full Bug description available at: http://bugs.php.net/?id=8889
--
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 Bug #8889 Updated: Memory is not being freed.
At 04:59 PM 4/30/2001 -0500, Brian Moon wrote: This is the answer I had previously received. IMHO, this sucks. We don't do SQL queries on our production site. It is all cached. So, SQL is not the problem. It is most likely because of the storage of large arrays or something of that nature. Well maybe you should try and see what in your script is taking up lots of memory. I guess we will continue to use MaxRequestsPerChild until one day the people that wrote that memory allocation system get a clue. They are very clue full. A program which uses X MB of memory is very likely to use X MB of memory again at a later time. For example, how does it help you if your 14 MB were shrunk back to 10 MB on each request. The next request would probably make it grow back to 14 MB. There might be some memory management libraries that shrink the memory back but I doubt you can gain much from it especially as memory fragmentation can severally limit the amount of memory you can reclaim and because of the point I made before, it's probably just not worth it. If you can find a case where you really think PHP is using much too much memory let me know and we can try and check together if there's a way to improve the situation. Andi -- 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 Bug #8889 Updated: Memory is not being freed.
But the reverse side of this is that I might have one script out of 1000 that needs that much memory. But since 20 of my httpd processes have run that script, they all have that much memory and are not going to let it go no matter what. I basically sounds like a flaw that memory can not be freed. Reuse in the same process is not free memory, it is reused memory. And it sounds like there is nothing that the PHP team can do about it. Brian Moon - Phorum Dev Team - http://phorum.org Making better forums with PHP - Look for my presentation at ApacheCon 2001. Caching Dynamic Web Content to Increase Dependability and Performance http://www.apachecon.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 30, 2001 5:02 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. At 04:59 PM 4/30/2001 -0500, Brian Moon wrote: This is the answer I had previously received. IMHO, this sucks. We don't do SQL queries on our production site. It is all cached. So, SQL is not the problem. It is most likely because of the storage of large arrays or something of that nature. Well maybe you should try and see what in your script is taking up lots of memory. I guess we will continue to use MaxRequestsPerChild until one day the people that wrote that memory allocation system get a clue. They are very clue full. A program which uses X MB of memory is very likely to use X MB of memory again at a later time. For example, how does it help you if your 14 MB were shrunk back to 10 MB on each request. The next request would probably make it grow back to 14 MB. There might be some memory management libraries that shrink the memory back but I doubt you can gain much from it especially as memory fragmentation can severally limit the amount of memory you can reclaim and because of the point I made before, it's probably just not worth it. If you can find a case where you really think PHP is using much too much memory let me know and we can try and check together if there's a way to improve the situation. Andi -- 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] Bug #10567: Your PHP 4.05 Zip file is missing 88 bytes!
From: [EMAIL PROTECTED] Operating system: Win 32 PHP version: 4.0.4pl1 PHP Bug Type: *General Issues Bug description: Your PHP 4.05 Zip file is missing 88 bytes! Your PHP 4.05 Windows 32 ZIP file, complete install, appears to be bad. After downloading, I am told it is missing 88 bytes of data and is unusable. -- Edit Bug report at: http://bugs.php.net/?id=10567edit=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 #10539 Updated: still - unresolved reference to compress
ID: 10539 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Compile Failure Description: still - unresolved reference to compress Thanks for your response. Info you requested is below. I'm afraid I don't know what to look for in this case, so let me know if you need anything else. -d Output of 'ldd /usr/local/mysql-3.23.37/lib/mysql/libmysqlclient.so': libcrypt_i.so.1 = /usr/lib/libcrypt_i.so.1 libgen.so.1 = /usr/lib/libgen.so.1 libsocket.so.1 =/usr/lib/libsocket.so.1 libnsl.so.1 = /usr/lib/libnsl.so.1 libm.so.1 = /usr/lib/libm.so.1 libc.so.1 = /usr/lib/libc.so.1 libdl.so.1 =/usr/lib/libdl.so.1 libmp.so.2 =/usr/lib/libmp.so.2 /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1 I verified that all these libraries are present. config.log info: Run 1: ./configure --with-mysql=/usr/local/mysql-3.23.37 --with -apache=../apache_1.3. 19 --enable-track-vars --with-imap=../imap-2001.BETA.SNAP-0104241750 --enable-sy svsem --enable-sysvshm Prodiced this in config.log configure:49857: checking whether to include zlib support No other messages related to zlib. Run 2: ./configure --with-mysql=/usr/local/mysql-3.23.37 --with -apache=../apache_1.3. 19 --enable-track-vars --with-imap=../imap-2001.BETA.SNAP-0104241750 --enable-sy svsem --enable-sysvshm --with-zlib=/usr/local/zlib-1.1.3 aborts with: configure: error: Zlib module requires zlib = 1.0.9. and this in config.log: configure:49857: checking whether to include zlib support configure:50058: checking for gzgets in -lz configure:50077: gcc -o conftest -g -O2 -D_POSIX_PTHREAD_SEMANTICS -DSUPPORT_UT F8 -DXML_BYTE_ORDER=21 -L/usr/local/zlib-1.1.3/lib -R/usr/ucblib -L/usr/ucblib -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -L/usr/local/lib/gcc-lib/sp arc-sun-solaris2.8/2.95.2 -R/usr/local/src/www/imap-2001.BETA.SNAP-0104241750/c- client -L/usr/local/src/www/imap-2001.BETA.SNAP-0104241750/c-client -R/usr/local /mysql-3.23.37/lib/mysql -L/usr/local/mysql-3.23.37/lib/mysql conftest.c -lz -l mysqlclient -lcrypt -lresolv -lresolv -lm -ldl -lnsl -lsocket -lsocket -lgcc 1 5 Undefined first referenced symbol in file uncompress /usr/local/mysql-3.23.37/lib/mysql/libmysql c lient.so compress/usr/local/mysql-3.23.37/lib/mysql/libmysql c lient.so ld: fatal: Symbol referencing errors. No output written to conftest collect2: ld returned 1 exit status configure: failed program was: #line 50066 configure Tried editing configure, change line # 14725 to: 14725 LIBS=$LIBS -lz Get same result as Run #2 above. Previous Comments: --- [2001-04-29 22:23:04] [EMAIL PROTECTED] What does 'ldd /usr/local/mysql-3.23.37/lib/mysql/libmysqlclient.so' output? What is in config.log about zlib?? --Jani --- [2001-04-28 13:33:01] [EMAIL PROTECTED] Solaris 8 / gcc. Unresolved symbol errors during php configure. I have seen lots of information about this, but none of the fixes I've encountered have worked. I have: - tried adding -lz to LTLIBRARY_LDFLAGS in Makefile - tried adding --with-zlib-dir=/usr/local/zlib-1.1.3 - tried adding --with-zlib, or --with-zlib=/usr/local/zlib-1.1.3 - changed LIBS=-$LIBS -lz in configure - tried installing zlib to system location (--prefix=/usr) - obtained latest CVS tree and built, with same results. Output of debug.log follows. Thank you -David -- CONFIGURE: './configure' '--with-mysql=/usr/local/mysql-3.23.37' '--with-apache=../apache_1.3.19' '--enable-tr ack-vars' '--with-imap=../imap-2001.BETA.SNAP-0104241750' '--enable-sysvsem' '--enable-sysvshm' '--with-config-f ile-path=/etc/apache' '--with-zlib' CC: gcc CFLAGS: -g -O2 CPPFLAGS:-D_POSIX_PTHREAD_SEMANTICS CXX: CXXFLAGS: INCLUDES:-I/usr/local/src/www/apache_1.3.19/src/include -I/usr/local/src/www/apache_1.3.19/src/os/unix -I$( top_builddir)/Zend -I/usr/local/src/www/imap-2001.BETA.SNAP-0104241750/c-client -I/usr/local/mysql-3.23.37/inclu de/mysql LDFLAGS: -R/usr/ucblib -L/usr/ucblib -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -L/usr/local/lib/g cc-lib/sparc-sun-solaris2.8/2.95.2 -R/usr/local/src/www/imap-2001.BETA.SNAP-0104241750/c-client -L/usr/local/src /www/imap-2001.BETA.SNAP-0104241750/c-client -R/usr/local/mysql-3.23.37/lib/mysql -L/usr/local/mysql-3.23.37/lib /mysql LIBS: -lmysqlclient -lresolv -lresolv -lm -ldl -lcrypt -lnsl -lsocket -lsocket -lgcc DLIBS: -lc-client SAPI: apache PHP_RPATHS: /usr/ucblib /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2
RE: [PHP-DEV] php.ini location
[Andi Gutmans [EMAIL PROTECTED]] Hi, The default location of php.ini in the current CVS seems to be /usr/local/etc. Didn't we say we're saving this one for 4.1.x? I just got bitten by this and I bet there will be a huge amount of people who will too. I'll change it back. - Stig Phew. : Mike Robinson -- 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] Bug #10568: error using ODBC
From: [EMAIL PROTECTED]
Operating system: Win 98
PHP version: 4.0.4pl1
PHP Bug Type: ODBC related
Bug description: error using ODBC
Hello:
I am using a database called RECITAL . I am trying to connect myself using ODBC.
When executing the command: odbc_exec($connect, $query) I can revise the connection
from the database and indeed her ago. But then treatment of consenting to the data
using any function ODBC, for example:
odbc_result_all($connect, BGCOLOR = ' #AAFFAA ' border=3 width=30% bordercolordark = '
#FF ');
---
and it throws me this error:
-
Warning: Not tuples available at this result index in programa/apache c:/archivos
group/apache/htdocs/b.html on line 7
-
I need to know if they can help me with this.
thank you.
(the table if it exists, some fields is: nlocal,ncontr)
This is the program php:
---
?php
function to () {
$connect = odbc_connect ( dig , root , cir0921, SQL_CUR_USE_ODBC );
$query = SELECT * local FROM;
$result = odbc_exec($connect, $query);
while(odbc_fetch_row($result)) {
$id=odbc_result($result,1);
$pass=odbc_result($result,2);
echo id:$id,pass:$pass
;
}
odbc_close_all($connect);
return true;
} / / a
?
?php
echoLines Before;
$bb = a();
echo Lines Later;
?
---
--
Edit Bug report at: http://bugs.php.net/?id=10568edit=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] Bug #10071 Updated: print and echo dont work for string of size 65k
ID: 10071 Updated by: andi Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Scripting Engine problem PHP Version: 4.0.4pl1 Assigned To: Comments: Fixed in latest CVS. By the way, size_t on Windows is 32bit so the 64KB limit must be some internal buffer size of the Standard C I/O library of Windows. Previous Comments: --- [2001-03-29 23:29:00] [EMAIL PROTECTED] If you try to print (or echo) a variable string with size larger than 65k, It does not work. The reason of this is that the engine uses fwrite function with str_length (in this case say it is 155000) so fwrite fails because it uses size_t which is defined as unsigned int (limited to 65k). --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10071edit=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] Bug #10567: Your PHP 4.05 Zip file is missing 88 bytes!
This seems definiatly to be the case.. (I would build one but on a 56k its going to take a few hours before its upthere) - James -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 30 April 2001 23:18 To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug #10567: Your PHP 4.05 Zip file is missing 88 bytes! From: [EMAIL PROTECTED] Operating system: Win 32 PHP version: 4.0.4pl1 PHP Bug Type: *General Issues Bug description: Your PHP 4.05 Zip file is missing 88 bytes! Your PHP 4.05 Windows 32 ZIP file, complete install, appears to be bad. After downloading, I am told it is missing 88 bytes of data and is unusable. -- Edit Bug report at: http://bugs.php.net/?id=10567edit=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 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.ini location
This wasn't the case with the 4.0.5 branch was it? -Original Message- From: Mike Robinson [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 6:29 PM To: [EMAIL PROTECTED] Subject: RE: [PHP-DEV] php.ini location [Andi Gutmans [EMAIL PROTECTED]] Hi, The default location of php.ini in the current CVS seems to be /usr/local/etc. Didn't we say we're saving this one for 4.1.x? I just got bitten by this and I bet there will be a huge amount of people who will too. I'll change it back. - Stig Phew. : Mike Robinson -- 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.ini location
Nope At 02:25 1/5/2001, Sean R. Bright wrote: This wasn't the case with the 4.0.5 branch was it? -Original Message- From: Mike Robinson [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 6:29 PM To: [EMAIL PROTECTED] Subject: RE: [PHP-DEV] php.ini location [Andi Gutmans [EMAIL PROTECTED]] Hi, The default location of php.ini in the current CVS seems to be /usr/local/etc. Didn't we say we're saving this one for 4.1.x? I just got bitten by this and I bet there will be a huge amount of people who will too. I'll change it back. - Stig Phew. : Mike Robinson -- 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] -- 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] 4.0.6
I am also one of the authors of ext/iconv module. iconv module is only for encoding translation but jstring (renaming to mbstring) is for general multibyte string handling fucntions. The encoding translation is one of functionalities of mbstring. I think rather iconv module should be merged into mbstring in the future. On Mon, 30 Apr 2001 19:53:11 +0300 Alexander Bokovoy [EMAIL PROTECTED] wrote: On Mon, Apr 30, 2001 at 10:47:21PM +0900, Rui Hirokawa wrote: On Mon, 30 Apr 2001 15:37:14 +0300 Andi Gutmans [EMAIL PROTECTED] wrote: At 09:35 PM 4/30/2001 +0900, Rui Hirokawa wrote: Andi, We have plan to add ext/jstring which is a japanese string extension module to php-4.0.6. Is there any problem to add this module on CVS tree now ? No I don't see a problem with this but please do it quickly. 4.0.6 has already gone a long way since we started RC'ing 4.0.5 and I would like to start RC'ing it pretty soon. You should probably also copy dotnet/EXPERIMENTAL to your directory until it becomes completely stable. I did. By the way, do you think jstring is the right name? Is it only for Japanese? It includes some functions for japanese,but some functions are not only for japanese. For example, this module supports encoding conversion functionality between Unicode and some other encodings like ISO-8859-X. Currently, it includes encoding conversion filter for japanese and ISO-8859-X, but it is relatively easy task to add another conversion filter for some other language. I believe this module is small step for PHP internationalization. I think the name 'jstring' is right name now because it is existing for japanese string function now. But 'i18n' or 'wchar' or 'i18n-ja' are also the candidate for the name. It would be very good to join this features with existing iconv extension rather than generate new extensions. -- -- Rui Hirokawa [EMAIL PROTECTED] maintainer of japanese PHP manual [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]
[PHP-DEV] PHP 4.0 Bug #9433 Updated: ErrorDocument 404 pointing to PHP file
ID: 9433 User Update by: [EMAIL PROTECTED] Status: Open Bug Type: Apache related Description: ErrorDocument 404 pointing to PHP file To make this more understandable (people emailed me with questions which weren't posted in the report). This scenario does work on lynx and it can not be a browser or apache server error because it works perfectly with 4.0.1pl2 and earlier. Are there any modifications I can make in the php sources before compiling to meet my need if you would prefer to not modify the current php source on this feature? Previous Comments: --- [2001-02-28 19:42:15] [EMAIL PROTECTED] No response? --- [2001-02-24 17:17:08] [EMAIL PROTECTED] If this were the case, then why does it react differently with PHP version 4.0.1pl2 and 4.0.2? --- [2001-02-24 16:51:21] [EMAIL PROTECTED] Adding to this, lynx reports a 404 then continues to load the correct page. I guess lynx reports a 404 if the file is not found then proceeds to the page specified for that error. --- [2001-02-24 16:43:48] [EMAIL PROTECTED] No, lynx reports a 404 error also. --- [2001-02-23 22:34:31] [EMAIL PROTECTED] Apache 1.3.12 I wrote a script that redirects a person to a different page based on the REQUEST_URI and HTTP_HOST apache variables. Ever since PHP 4.0.2, Internet Explorer started reporting 404 errors instead of going to the appropriate page. What is even more mysterious is that it is the IE 404 error page, not the server wide page nor the default 404 error page for the site. To top it all off, it works for Opera as well as Netscape. I think this must be caused by the way PHP handles headers and the way IE interprets them, because I can put PHP version 4.0.1pl2 on and it will work great even with IE, then any versions afterwards cause an error. An example page is at http://test.jwdx.com I have also added header(Status: 404 Not Found) as stated in other bug reports. I would not blame this on PHP except for the fact that different versions respond differently with all other circumstances remaining the same. --Justin Bachus --- 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=9433 -- 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.5 is out
Woohoo! Thanks guys for adding sybase_get_last_message() support! I only just discovered that I needed it yesterday, and then the new version comes out with the function implemented. Nice! Thanks guys for all the good werke. Tyson Lloyd Thwaites I.Te Limited -- 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 is out
After a very long QA process, PHP 4.0.5 has finally been officially
released. This is a maintenance version, with a lot of bug fixes from PHP
4.0.4pl1. Other than that, there aren't too many new features in this
release, so it's mostly recommended for people that were experiencing one
(or more) of the bugs that were fixed. Note that PHP 4.0.6 is also planned
for the near future, featuring mostly bug fixes; This may affect your
upgrade considerations.
Notable features:
- High performance output compression support and improved output buffering
- Experimental FastCGI module
- A lot of PEAR work
- Significantly improved thread safety (users of multithreaded servers
should definitely upgrade if they have earlier versions of PHP)
Full list of changes is available at http://www.php.net/ChangeLog-4.php,
and is also attached at the end of this letter. Thanks goes to the PHP QA
team, which worked a lot to make sure that this release works as well as
expected, and beyond. Special thanks to Mr. J, which managed to survive
the long and thrilling QA process without getting a heart attack :)
Zeev
30 Apr 2001, Version 4.0.5
- IMPORTANT: removed /F modifier handling from preg_replace(). Instead
one should use new preg_replace_callback() function. (Andrei)
- Added new php.ini directive: arg_separator.input which is used to tell
PHP which characters are considered as argument separators in URLs.
Renamed php.ini directive: arg_separator - arg_separator.output (Jani)
- Added FastCGI SAPI module. (Ben Mansell)
- Added array_reduce(), which allows iterative reduction of an array
to a single value via a callback function. (Andrei)
- The imageloadfont function of the gd extension should be not platform
dependent after this fix. ([EMAIL PROTECTED])
- Fixed a compatibility problem in some file functions (fgets, fputs, fread,
fwrite). The ANSI standard says that if a file is opened in read/write
mode, fseek() should be called before switching from reading to writing
and vice versa. ([EMAIL PROTECTED])
- Fixed argument checking for call_user_func* functions and allowed
specifying array($obj, 'method') syntax for call_user_func_array. (Andrei)
- Fixed parent::method() to also work with runtime bindings.
(Zeev, Zend Engine)
- Implemented high-performance zlib-based output compression - see
zlib.output_compression INI directive. (Zeev)
- Improved ob_gzhandler() to support chunked output buffering - it's
recommended to use it with 4KB chunks. (Zeev)
- Fixed chunked output buffering. (Zeev)
- Forced call_user_method() and call_user_method_array() to take the
object argument by reference. (Andrei)
- Fixed binding of ROWIDs in OCI8. (Thies)
- Added PEAR/Cache as a generic Caching System. (Sebastian, PEAR/Cache)
- Added IMAP quota support (imap_set_quota, imap_get_quota), enabled/added via
c-client2000. (kalowsky)
- Upgraded PCRE to version 3.4. (Andrei)
- Added array_search which works similar to in_array but returns
the key instead of a boolean. ([EMAIL PROTECTED])
- Fixed pgsql transaction support. (Stig, PEAR/DB)
- Added new object VARIANT() to encapsulate values for use with
the COM and DOTNET module. Therefore it is now possible to pass
values by reference, convert php values to extended variant types (currency,
date, idispatch, iunknown, ...) and define the codepage that should
be used for unicode - conversion.
- Improved overall speed of IRCG, added URL handling to message scanner.
(Sascha)
- Fixed some modules to allow using output-buffering. (Thies)
- Added the chroot() function. (Derick)
- PostgreSQL now does a rollback at the end of a request on every
persistent connection. This is done by doing an empty transaction
on the connection. This was advised by someone from the PostgreSQL
core-team. (Thies)
- Fixed PostgeSQL pg_connect() bug. We would sometimes close the default
link by accident. (Patch by: [EMAIL PROTECTED])
- Improved OCI8 dead-session detection. (Patch by: George Schlossnagle)
- Fixed get_meta_tags() multiline bug #4556. (Sean)
- Prefer random() over *rand48(). (JimJag)
- Sped up WDDX serialization 2x. (Andrei)
- Added a new parameter to mail() which appends aditional command line
parameters to the mail program. (Derick)
- Added Udm_Clear_Search_Limits mnoGoSearch extension function. (gluke)
- Fixed mnogosearch protos. Fixed mnogosearch functions return values.
A bug with capital letters break search has been fixed. (gluke)
- Static methods can now be called via call_user_method_* functions, e.g.
call_user_method('method', 'class'), and also array('class', 'method')
constructs (for array_walk(), for example). (Andrei, Zend Engine)
- microtime() under Windows now returns accurate values. (James)
- Added PREG_SPLIT_DELIM_CAPTURE flag to preg_split() that allows for Perl-like
functionality of capturing parenthesized delimiter expression. (Andrei)
- Fixed strip_tags() to not strip a lone character. (Rasmus)
-
Re: [PHP-DEV] Bug #10570: PHP 4.0.5 - Cannot connect to mySQL database
I had the same problem when I first compiled 4.0.5, using the built-in MySQL libraries. I changed my configure line to use --with-mysql=/usr/local/mysql and it worked fine after that. I had the same problem on two different boxes. Seems kind of odd that they didn't catch this one... [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... From: [EMAIL PROTECTED] Operating system: RedHat 6.2 PHP version: 4.0.4pl1 PHP Bug Type: MySQL related Bug description: PHP 4.0.5 - Cannot connect to mySQL database I compiled and installed php 4.0.5. Then I could not establish any connections to the mySQL database we have. If we switch back to php4.0.4pl1 we have no problem. PHP 4.0.5 was compiled both with and without mysql config flags. -- Edit Bug report at: http://bugs.php.net/?id=10570edit=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 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 Bug #8889 Updated: Memory is not being freed.
Perhaps another possible solution is this... For those 1 in 300 web hits that the developer knows is going to use gobs of memory and assuming they can't be re-engineered to use less (through temp files, etc), create a simple function that is callable in PHP that will cause the parent apache process to exit (if it doesn't exist already) It will be immediately replaced by another much smaller version ready to handle the remaining 299 web hits. This gives the performance benefit for most hits of the apache module, but the memory benefits of the cgi behavior. But before I'd do that, I'd make sure the big page can't be re-engineered first. Brian On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote: I too have experienced this problem and can reproduce, I just changed to the cgi version instead to eliminate the problem, which I would agree, it is. I have one page on a site of hundreds of pages that produces the large process, 30MB+ and this is on a heavily used server with more than 300 processes. So if I don't run the cgi-version the server will crash in a matter of time as the memory is not freed and eventually will swap itself to death. So while the cgi-version is slightly slower, I have reliability. John Hamlik -Original Message- From: Brian Moon [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 3:20 PM To: [EMAIL PROTECTED]; Andi Gutmans Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. But the reverse side of this is that I might have one script out of 1000 that needs that much memory. But since 20 of my httpd processes have run that script, they all have that much memory and are not going to let it go no matter what. I basically sounds like a flaw that memory can not be freed. Reuse in the same process is not free memory, it is reused memory. And it sounds like there is nothing that the PHP team can do about it. Brian Moon - Phorum Dev Team - http://phorum.org Making better forums with PHP - Look for my presentation at ApacheCon 2001. Caching Dynamic Web Content to Increase Dependability and Performance http://www.apachecon.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 30, 2001 5:02 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. At 04:59 PM 4/30/2001 -0500, Brian Moon wrote: This is the answer I had previously received. IMHO, this sucks. We don't do SQL queries on our production site. It is all cached. So, SQL is not the problem. It is most likely because of the storage of large arrays or something of that nature. Well maybe you should try and see what in your script is taking up lots of memory. I guess we will continue to use MaxRequestsPerChild until one day the people that wrote that memory allocation system get a clue. They are very clue full. A program which uses X MB of memory is very likely to use X MB of memory again at a later time. For example, how does it help you if your 14 MB were shrunk back to 10 MB on each request. The next request would probably make it grow back to 14 MB. There might be some memory management libraries that shrink the memory back but I doubt you can gain much from it especially as memory fragmentation can severally limit the amount of memory you can reclaim and because of the point I made before, it's probably just not worth it. If you can find a case where you really think PHP is using much too much memory let me know and we can try and check together if there's a way to improve the situation. Andi -- 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] -- 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]
