Re: [PHP-DEV] Re: #18824 [NEW]: PHP should produce an appropriate

[Troels Arvin]

On Fri, 09 Aug 2002 11:28:20 +0200, Rasmus Lerdorf wrote:

> Buffering should be transparent and should not have a different http
> status code from a non-buffered.

There are already differences with regard to output buffering or not. Like
the way cookie-setting should designed by the web developer.

But OK; it may be valid point, depending how "transparent" is interpreted.

Would it be difficult to add a configuration option which, when enabled,
makes PHP send an 500 HTTP response code _if possible_ in case of fatal
errors? "if possible" would probably mean "if output buffering is on or if
no HTTP request body has been sent yet". I know that we would use such a
feature.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: #18824 [NEW]: PHP should produce an appropriate status code when an error is encountered

[Troels Arvin]

On Fri, 09 Aug 2002 08:09:34 +0200, Bugs Php Net wrote:

> Please modify PHP to generate appropriate status codes.

I totally agree. PHP should generate a 500 error in case of a fatal error
which means that PHP can't parse or compile the page - i.e. at least in
cases where using your own error handling system is difficult.

I can't see how that would break anything. On the other hand, it would be
much easier to detect errors and fatal-error pages would normally not be
picked up by caches, spiders, etc.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Patch suggestions for PHP 4.2.3 (sablotron and pcre)

[Troels Arvin]

Hello,

I have two patch suggestions for PHP 4.2.3. Both patches patch well into
PHP 4.2.2.


http://rpms.arvin.dk/php/source/patches/php-4.2.2-xslt-config.m4.patch
--

First part of the patch removes the iconv detection which simply doesn't
seem to work well; at least it didn't detect iconv built into glibc on my
Red Hat 7.3 system. This may be a bit controversial.

The second part of the patch is less controversial: Without the changes,
detection of SablotSetEncoding fails on my system (I have sablotron with
javascript enabled).


http://rpms.arvin.dk/php/source/patches/php-4.2.2-pcre.config.m4.patch
--

Without this patch, configure can't find pcre.h on my system (Red Hat
7.3) when pcre is compiled to use the system pcre library in stead of the
bundled pcre library.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_2_0) /ext/mcal config.m4

[Troels Arvin]

On Mon, 24 Jun 2002 12:29:02 +0200, Jani Taskinen wrote:


> The real fix would be to
> fix PHP_ADD_LIBRARY_DEFER_WITH_PATH..

That's how it is in PHP 4.2.1, and it's buggy: The mcal library is linked
to the main PHP binary (e.g. libphp4.so) and not the the extension
(mcal.so).

Maybe there is a bug in PHP_ADD_LIBRARY_WITH_PATH?

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fixes/suggestions for PHP 4.2.2

[Troels Arvin]

Hello Derick,

On Mon, 24 Jun 2002 10:48:56 +0200, derick wrote:
> I merged all suggested patches to the branch, and applied most of your
> patches
Thanks! - That will make my RPM-building process a bit easier.

> except for the pcre thing, as I don't know how this is supposed to work.
I'll try creating a proper patch for pcre's config.m4; hopefully in the
PHP 4.2.2 time frame.

> Thank you for submitting this, and if you may find anything else, feel
> free to write this list.
Actually, I have one more suggestion. See this patch:
http://rpms.arvin.dk/php/source/patches/php-4.2-info.c.patch

It clears up some potential misunderstandings in phpinfo()'s output.

Example:
phpinfo()'s "Apache Version" output prints the apache version present at
build-time. If PHP is built on a system with Apache 1.3.26, and then
installed on a system with an Apach 1.3.20, then phpinfo() will currently
write:
Apache Version: 1.3.26.

This is confusing, at best. And it could make some not-so-experienced
system administrators think that their Apache doesn't have the nasty
chunked encoding bug while, in fact, it has.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Fixes/suggestions for PHP 4.2.2

[Troels Arvin]

Hello,

If PHP 4.2.2 is going to be released, then I have some suggestions:

I believe that the following changes to HEAD should be MFH'ed:

http://cvs.php.net/diff.php/php4/ext/gmp/config.m4?r1=1.6&r2=1.7
http://cvs.php.net/diff.php/php4/ext/standard/link.c?r1=1.37&r2=1.38
http://cvs.php.net/diff.php/php4/ext/standard/math.c?sbt=2&r1=1.83&r2=1.85
http://cvs.php.net/diff.php/php4/ext/mcrypt/mcrypt.c?r1=1.75&r2=1.76
http://cvs.php.net/diff.php/php4/ext/standard/basic_functions.c?r1=1.478&r2=1.479
http://cvs.php.net/diff.php/php4/ext/standard/string.c?r1=1.274&r2=1.275
http://cvs.php.net/diff.php/php4/ext/standard/versioning.c?sbt=2&r1=1.8&r2=1.9

I also _seems_ that the May 17 changes in HEAD's sysvsem extension should
be MFH'ed.


I need the following patch for the mcal extension to build properly as a
shared module on my Linuxes:

http://rpms.arvin.dk/php/source/patches/php-4.2.1-mcal-shared.patch

It reverts a change made by sniper on April 3. Without the patch, then the
main PHP binary links to libmcal.so.0, but the PHP extension (mcal.so)
doesn't.


If I don't use the following patch, then the pcre extension will not build
with the system pcre library:

http://rpms.arvin.dk/php/source/patches/php-4.2.1-pcre.h.patch

The correct fix would probably be to add checks in pcre's config.m4 (see
if pcre.h is in /usr/local/include/pcre, /usr/local/include,
/usr/include/pcre, or /usr/include).


If I don't use the following patch, then "make install" will fail to
respect a "prefix=" argument when doing "make install":
http://rpms.arvin.dk/php/source/patches/php-4.2.1-regression-tools.patch

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Bug #11998 Updated: Crash on multipart file form upload

[troels]

ID: 11998
Updated by: troels
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Reproducible crash
Operating System: FreeBSD 4.2-STABLE
PHP Version: 4.0CVS-2001-07-10
New Comment:

Some follow-up.

PHP 4.0.5 does _not_ have the bug.
Current CVS (August 30 2001) does have the bug.

The bug doesn't seem to show up unless around 30 files are uploaded.

Here's a back-trace from PHP current CVS.

#0  php_mime_split (
buf=0x80fbaf4 '-' , 
"172461271845611381008674657\r\nContent-Disposition: form-data; 
name=\"date_debut\"\r\n\r\n2001-08-25", cnt=28292, boundary=0x80c387a '-' , "172461271845611381008674657", array_ptr=0x80fb0e4) at rfc1867.c:177
#1  0x4042a55f in rfc1867_post_handler (
content_type_dup=0x80c385c "multipart/form-data; boundary=", '-' , "172461271845611381008674657", arg=0x80fb0e4)
at rfc1867.c:472
#2  0x40427c83 in sapi_handle_post (arg=0x80fb0e4) at SAPI.c:107
#3  0x4042b768 in php_treat_data (arg=0, str=0x0, destArray=0x0) at 
php_variables.c:250
#4  0x40425036 in php_hash_environment () at main.c:1097
#5  0x404244d0 in php_request_startup () at main.c:684
#6  0x404216c0 in apache_php_module_main (r=0x80e5218, display_source_mode=0) at 
sapi_apache.c:67
#7  0x40422324 in send_php (r=0x80e5218, display_source_mode=0, filename=0x0) at 
mod_php4.c:575
#8  0x40422383 in send_parsed_php (r=0x80e5218) at mod_php4.c:590
#9  0x080551cd in ap_invoke_handler () at eval.c:41
#10 0x0806732c in ap_some_auth_required () at eval.c:41
#11 0x080673a3 in ap_process_request () at eval.c:41
#12 0x0805fa47 in ap_child_terminate () at eval.c:41
#13 0x0805fbea in ap_child_terminate () at eval.c:41
#14 0x0805fd2d in ap_child_terminate () at eval.c:41
#15 0x08060350 in ap_child_terminate () at eval.c:41
#16 0x08060c13 in main () at eval.c:41
#17 0x4015c4b7 in __libc_start_main (main=0x8060790 , argc=2, ubp_av=0xb9c4, 
init=0x804fb20 <_init>, fini=0x80894d0 <_fini>, 
rtld_fini=0x4000dbb4 <_dl_fini>, stack_end=0xb9bc) at 
../sysdeps/generic/libc-start.c:129

Previous Comments:


[2001-08-30 13:32:38] [EMAIL PROTECTED]

The bug also exists when running PHP on Linux. And it may be reproduced with Mozilla, 
too. Please don't forget this one before 4.0.7 is released.



[2001-08-23 05:54:35] [EMAIL PROTECTED]

Reproduced with IE 5.5. The rfc1867.c has some bugs
in it after all..

Marked as fix before release. (4.0.7)

--Jani




[2001-08-21 05:42:02] [EMAIL PROTECTED]

Crashes with 1.3.14, 1.3.17 and 1.3.20.

I've tried it with IE5, IE5.5, Mozilla 0.9.3 and Netscape 6.1.

Whoa, just found it _doesn't_ crash with Netscape 4.08 or Opera 5.11.

I can't test it in Linux, as I'm currently sans-external-DSL-modem and therefore stuck 
in windows until a new one arrives.



[2001-08-21 05:28:51] [EMAIL PROTECTED]

Just one more thing: What version of Apache? 
And does this happen with any browser? IE / NS / Mozilla ?

--Jani




[2001-08-21 00:11:45] [EMAIL PROTECTED]

>From CVS as at 21/08/2001 16:15 NZDT using same form and uploading 2 images in the 
>fields supplied.

(gdb) bt
#0  0x1823fdbf in php_mime_split (
buf=0x82c '-' , "7d12252130332\r\nContent-Disposition: 
form-data; name=\"id\"\r\n\r\n3319", cnt=33534, 
boundary=0x819762a '-' , "7d12252130332", array_ptr=0x817eaec) 
at rfc1867.c:174
#1  0x18240a3b in rfc1867_post_handler (
content_type_dup=0x819760c "multipart/form-data; boundary=", '-' , "7d12252130332", arg=0x817eaec)
at rfc1867.c:472
#2  0x1823eb25 in sapi_handle_post (arg=0x817eaec) at SAPI.c:107
#3  0x18241a01 in php_treat_data (arg=0, str=0x0, destArray=0x0) at 
php_variables.c:250
#4  0x1823c2ce in php_hash_environment () at main.c:1097
#5  0x1823b6f0 in php_request_startup () at main.c:684
#6  0x18238cd6 in apache_php_module_main (r=0x819e71c, display_source_mode=0) at 
sapi_apache.c:67
#7  0x18239822 in send_php (r=0x819e71c, display_source_mode=0, filename=0x0) at 
mod_php4.c:575
#8  0x18239882 in send_parsed_php (r=0x819e71c) at mod_php4.c:590
#9  0x80758a1 in ap_invoke_handler ()
#10 0x8089fa8 in process_request_internal ()
#11 0x808a402 in ap_internal_redirect ()
#12 0x181d48d2 in mod_gzip_redir1_handler () from 
/usr/local/apache_test/libexec/mod_gzip.so
#13 0x181d2fa0 in mod_gzip_handler () from /usr/local/apache_test/libexec/mod_gzip.so
#14 0x80758a1 in ap_invoke_handler ()
#15 0x8089fa8 in process_request_internal 

[PHP-DEV] Bug #11998 Updated: Crash on multipart file form upload

[troels]

ID: 11998
Updated by: troels
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Reproducible crash
Operating System: FreeBSD 4.2-STABLE
PHP Version: 4.0CVS-2001-07-10
New Comment:

The bug also exists when running PHP on Linux. And it may be reproduced with Mozilla, 
too. Please don't forget this one before 4.0.7 is released.

Previous Comments:


[2001-08-23 05:54:35] [EMAIL PROTECTED]

Reproduced with IE 5.5. The rfc1867.c has some bugs
in it after all..

Marked as fix before release. (4.0.7)

--Jani




[2001-08-21 05:42:02] [EMAIL PROTECTED]

Crashes with 1.3.14, 1.3.17 and 1.3.20.

I've tried it with IE5, IE5.5, Mozilla 0.9.3 and Netscape 6.1.

Whoa, just found it _doesn't_ crash with Netscape 4.08 or Opera 5.11.

I can't test it in Linux, as I'm currently sans-external-DSL-modem and therefore stuck 
in windows until a new one arrives.



[2001-08-21 05:28:51] [EMAIL PROTECTED]

Just one more thing: What version of Apache? 
And does this happen with any browser? IE / NS / Mozilla ?

--Jani




[2001-08-21 00:11:45] [EMAIL PROTECTED]

>From CVS as at 21/08/2001 16:15 NZDT using same form and uploading 2 images in the 
>fields supplied.

(gdb) bt
#0  0x1823fdbf in php_mime_split (
buf=0x82c '-' , "7d12252130332\r\nContent-Disposition: 
form-data; name=\"id\"\r\n\r\n3319", cnt=33534, 
boundary=0x819762a '-' , "7d12252130332", array_ptr=0x817eaec) 
at rfc1867.c:174
#1  0x18240a3b in rfc1867_post_handler (
content_type_dup=0x819760c "multipart/form-data; boundary=", '-' , "7d12252130332", arg=0x817eaec)
at rfc1867.c:472
#2  0x1823eb25 in sapi_handle_post (arg=0x817eaec) at SAPI.c:107
#3  0x18241a01 in php_treat_data (arg=0, str=0x0, destArray=0x0) at 
php_variables.c:250
#4  0x1823c2ce in php_hash_environment () at main.c:1097
#5  0x1823b6f0 in php_request_startup () at main.c:684
#6  0x18238cd6 in apache_php_module_main (r=0x819e71c, display_source_mode=0) at 
sapi_apache.c:67
#7  0x18239822 in send_php (r=0x819e71c, display_source_mode=0, filename=0x0) at 
mod_php4.c:575
#8  0x18239882 in send_parsed_php (r=0x819e71c) at mod_php4.c:590
#9  0x80758a1 in ap_invoke_handler ()
#10 0x8089fa8 in process_request_internal ()
#11 0x808a402 in ap_internal_redirect ()
#12 0x181d48d2 in mod_gzip_redir1_handler () from 
/usr/local/apache_test/libexec/mod_gzip.so
#13 0x181d2fa0 in mod_gzip_handler () from /usr/local/apache_test/libexec/mod_gzip.so
#14 0x80758a1 in ap_invoke_handler ()
#15 0x8089fa8 in process_request_internal ()
#16 0x808a402 in ap_internal_redirect ()
#17 0x80602b2 in handle_dir ()
#18 0x80758a1 in ap_invoke_handler ()
#19 0x8089fa8 in process_request_internal ()
#20 0x808a012 in ap_process_request ()
#21 0x8080fdf in child_main ()
#22 0x808119d in make_child ()
#23 0x8081316 in startup_children ()
#24 0x8081924 in standalone_main ()
#25 0x808213c in main ()
#26 0x804f429 in _start ()
(gdb) 



[2001-08-20 19:48:36] [EMAIL PROTECTED]

I can not reproduce it with your form and with latest CVS.
Please provide a GDB backtrace of the crash (using latest CVS of PHP)

--Jani




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


Edit this bug report at http://bugs.php.net/?id=11998&edit=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 #12884 Updated: Content-Encoding: PHP sends incorrect Content-Length when gzip is used on a re

[troels]

ID: 12884
Updated by: troels
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: HTTP related
Operating System: 
PHP Version: 4.0.6
New Comment:

I don't think that it's fixed the way yngve expects: ob_get_length() is still not 
fixed as far as I know. 

However, a work-around involving sending a Content-Length header form the 
ob_gzhandler, has been committed to CVS.

See also discussion at
http://groups.google.com/groups?th=20970c04f298469f,2
http://groups.google.com/groups?th=723d03bc0ba6cbe5,8


Previous Comments:


[2001-08-22 01:25:40] [EMAIL PROTECTED]

this should be fixed in CVS. Could you please try
the latest snapshot to verify:

http://snaps.php.net/

--Jani




[2001-08-21 14:43:56] [EMAIL PROTECTED]


I am a developer at Opera Software, in charge of the HTTP protocol support in the 
Opera Browser. 

We recently received a report of a problem on http://www.amdforums.com . 

When I investigating this report I found that the problem was caused by an incorrect 
Content-Length header in combination with a Content-Encoding: gzip header. 

The length indicated by the Content-Length is actually the length of the original, 
uncompressed body, but it should have been the length of the compressed body 
(References: RFC 2616 section 4.4, 7.2 and 14.13). 

The mismatch between the indicated Content-Length and the actual amount of received 
data causes Opera to do repeated load attempts (This is a fallback primarily used to 
handle problems with pipelining and persistent connections).

This mismatch also destroys the pipelining and persistent connection capabilities in 
HTTP 1.1. I actually observed one  example where the HTTP header of the next 
(pipelined) request was received and added to the content of the gzipped file.

Investigating the PHP sourcecode I found that the code to add the Content-Length 
header was disabled.

I am still investigating workarounds that will handle this problem, but unless it is 
removed on the server side it will affect all Opera versions after v4.0, as well as 
any other HTTP useragent that uses HTTP pipelining and therefore have to trust the 
Content-Length headers

To fix this problem you will have to replace the Content-Length header with a proper 
header, or remove it. An alternative (for HTTP 1.1 clients) is to use the chunked 
transfer encoding.

This is an example session: 


GET / HTTP/1.1
User-Agent Mozilla/3.0 (Windows 2000; U) Opera 5.50  [en]
Host www.amdforums.com
Accept text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*
Accept-Language en
Accept-Charset iso-8859-1,*,utf-8
Accept-Encoding deflate, gzip, x-gzip, identity, *;q=0
Connection Keep-Alive, TE
TE deflate, gzip, chunked, identity, trailers 

(Cookie header removed)

with the following response from the server 

HTTP/1.1 200 OK
Date Mon, 13 Aug 2001 175609 GMT
Server Apache/1.3.19 (Unix)  (Red-Hat/Linux) PHP/4.0.6 mod_perl/1.24_01
X-Powered-By PHP/4.0.6
Content-Length 60928
Content-Encoding gzip
Vary Accept-Encoding
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Content-Type text/html 

followed by an entity body of 9562 bytes of gzipped data. 

The gzipped data expands to 60928 bytes of data, as specified in the content length 
header.






Edit this bug report at http://bugs.php.net/?id=12884&edit=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] Re: Output Compression Issues

[Troels Arvin]

On Thu, 16 Aug 2001 14:26:09 +0200, "Zeev Suraski" <[EMAIL PROTECTED]> wrote:
> Can anybody think of good reasons not to send the content-length header
> in case we're performing output buffering?

Personally: No.

- However, the docs for the output handling system seems to indicate
that output buffering "filters" may be nested. I could imagine that this
will pose troubles if Content-Length headers are sent along in each
output buffering module(?):
http://www.php.net/manual/en/function.ob-start.php

Quoting:

 Output buffers are stackable, that is, you may call ob_start() while 
 another ob_start() is active. Just make sure that you call 
 ob_end_flush() the appropriate number of times. If multiple output 
 callback functions are active, output is being filtered sequentially 
 through each of them in nesting order.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
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: Output Compression Issues

[Troels Arvin]

On Thu, 16 Aug 2001 07:44:50 +0200, "John Donagher" <[EMAIL PROTECTED]>
wrote:

> So, we really want to disable output compression when we are serving
> anything but HTML/text.

I agree on that. I have heard that some older versions of both major
browsers have trouble with compressed non-HTML content. - Or perhaps the
ob_gzhandler could be given an argument telling it to be conservative or
not?


- Oh, and please:
Could someone take a look at this bug which I really think is serious:
http://www.php.net/bugs.php?id=12631

As written, it's currently not possible to send proper Content-Length
headers along with gz-encoded PHP-output because it's not possible to
get the correct output-length information when using the gzhandler.

When Content-Lengh headers are not sent, then Apache is not capable of
using keep-alive == worse performance.

There are lines like this in zlib.c:

#if 0
} else {
char lenbuf[64];

sprintf(lenbuf,"Content-Length: %d",Z_STRLEN_P(return_value));
sapi_add_header(lenbuf,strlen(lenbuf), 1);
#endif

What does "#if 0" actually mean?

If it's too hard to change the output buffering system to return proper
content lengths, maybe it would be an idea to be able to tell
ob_end_flush() that you want a Content-Length header to be sent along?
(It seems that ob_gzhandler knows the correct Content-Length but is
unable to pass that information along to the output buffering system.)

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
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 #12776: 4.0.7RC1: array_walk crash

[troels]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.6
PHP Bug Type: Reproducible crash
Bug description:  4.0.7RC1: array_walk crash

In both PHP 4.0.2, 4.0.6 and 4.0.7RC1:

The following code crashes PHP:
'v');
array_walk($arr,'test');

// This will crash:
print "First value: ".$globalArray[0];

// This will not crash, but give the wrong
// result, and the final "done" will never be
// printed:
// print "First value: "; print $globalArray[0];

print "\nDone\n";

?>
It doesn't matter if the code is run from PHP as an Apache module or
command-line PHP.

Operating systems tested: RH Linux 6.1, RH Linux Rawhide (i.e. cutting-edge
Red Hat developer-version).

A GDB back-trace on the latter, using command-line PHP:
GNU gdb 5.0rh-5 Red Hat Linux 7.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `/home/troels/local-php/bin/php simple.php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libpam.so.0...done.
Loaded symbols for /lib/libpam.so.0
Reading symbols from /lib/i686/libm.so.6...done.
Loaded symbols for /lib/i686/libm.so.6
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
#0  0x400de721 in __kill () from /lib/i686/libc.so.6
(gdb) bt
#0  0x400de721 in __kill () from /lib/i686/libc.so.6
#1  0x080a4976 in _emalloc (size=1515870824, __zend_filename=0x80f349d
"zend_operators.c", 
__zend_lineno=1043, __zend_orig_filename=0x0, __zend_orig_lineno=0) at
zend_alloc.c:173
#2  0x080b039e in concat_function (result=0xbfffe324, op1=0x813853c,
op2=0xbfffe210)
at zend_operators.c:1043
#3  0x080cd63b in execute (op_array=0x81340e4) at ./zend_execute.c:1105
#4  0x080b37fe in zend_execute_scripts (type=8, file_count=3) at
zend.c:806
#5  0x0805b0c4 in php_execute_script (primary_file=0xb760) at
main.c:1308
#6  0x0805911e in main (argc=2, argv=0xb804) at cgi_main.c:737
#7  0x400cc6b7 in __libc_start_main (main=0x80588d0 , argc=2,
ubp_av=0xb804, 
init=0x80576a4 <_init>, fini=0x80d52f0 <_fini>, rtld_fini=0x4000db64
<_dl_fini>, 
stack_end=0xb7fc) at ../sysdeps/generic/libc-start.c:129(gdb)

The above back-trace was created from a core-file generated by PHP
4.0.7RC1. The "config.nice" from the build:
#! /bin/sh
#
# Created by configure

'./configure' \
'--prefix=/home/troels/local-php' \
'--without-mysql' \
'--disable-xml' \
'--disable-session' \
'--enable-debug' \
'--without-pcre-regex' \
"$@"


-- 
Edit bug report at: http://bugs.php.net/?id=12776&edit=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 #11643 Updated: SID redefined

[troels]

ID: 11643
Updated by: troels
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Open
Bug Type: Session related
Operating System: Linux
PHP Version: 4.0 Latest CVS (2001-06-24)
Assigned To: hholzgra
New Comment:

Oops. The bug is _not_ fixed yet. I misunderstood Hartmut
's comment.

Previous Comments:


[2001-08-12 19:40:15] [EMAIL PROTECTED]

According to 
http://cvs.php.net/diff.php/php4/ext/session/session.c?r1=1.213&r2=1.214&f=h&num=10, 
Hartmut has now succeeded in committing his session.c changes. That should mean that 
this bug is fixed in current CVS.



[2001-06-25 16:38:08] [EMAIL PROTECTED]

i've already noticed and fixed this, 
but my current session.c has conflicts
i ahve to resolve before checkin ...



[2001-06-24 13:10:03] [EMAIL PROTECTED]

session_destroy() and session_register() both defines the same symbol. When I set:

error_reporting = E_ALL

in php.ini file I got warning:

Warning: Constant sid already defined in 
/home/sites/home/users/zork/web/report/sid.php on line 5

in this saple code:



On web: http://biuro.pablosoft.com.pl/~zork/report/sid.php

Zork





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

[troels]

ID: 11643
Updated by: troels
Reported By: [EMAIL PROTECTED]
Old Status: Analyzed
Status: Closed
Bug Type: Session related
Operating System: Linux
PHP Version: 4.0 Latest CVS (2001-06-24)
Assigned To: hholzgra
New Comment:

According to 
http://cvs.php.net/diff.php/php4/ext/session/session.c?r1=1.213&r2=1.214&f=h&num=10, 
Hartmut has now succeeded in committing his session.c changes. That should mean that 
this bug is fixed in current CVS.

Previous Comments:


[2001-06-25 16:38:08] [EMAIL PROTECTED]

i've already noticed and fixed this, 
but my current session.c has conflicts
i ahve to resolve before checkin ...



[2001-06-24 13:10:03] [EMAIL PROTECTED]

session_destroy() and session_register() both defines the same symbol. When I set:

error_reporting = E_ALL

in php.ini file I got warning:

Warning: Constant sid already defined in 
/home/sites/home/users/zork/web/report/sid.php on line 5

in this saple code:



On web: http://biuro.pablosoft.com.pl/~zork/report/sid.php

Zork





Edit this bug report at http://bugs.php.net/?id=11643&edit=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 #12631: Fatal: ob_get_length() returns wrong value when compressed OB is on

[troels]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.6
PHP Bug Type: Output Control
Bug description:  Fatal: ob_get_length() returns wrong value when compressed OB is on

When output buffering is on, using the gzhandler, then ob_get_length()
returns the uncompressed content length in stead of the actual (compressed)
payload.

This is fatal if a Content-Length HTTP-header is sent and the browser
implements HTTP keep-alive. The result is a web-site which appears to be
down or with extremely slow responses.

Example PHP code:



If this is saved as http://localhost/ob.php then try the following wget
command:

wget --header="Accept-Encoding: gzip" --header="Connection: close" -S
http://localhost/ob.php
Notice that wget displays the following error message continuously:
Connection closed at byte 36. Retrying.

Also notice that the web-server told wget to expect 90 bytes (the
uncompressed payload).

-- 
Edit bug report at: http://bugs.php.net/?id=12631&edit=1


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

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

[Troels Arvin]

On Thu, 02 Aug 2001 19:16:26 +0200, "Stanislav Malyshev" <[EMAIL PROTECTED]>
wrote:

> TA>> By the way:
> TA>> I think that the decbin() function should bail out if you pass it
> a TA>> value which contains more bits than PHP is able to handle. -
> Perhaps TA>> with a hint about using GMP for large numbers.
> 
> I'd say "give a warning" istead of "bail out", but that's a good idea,
> generally.

OK. Here is a suggestion for an adjustment in math.c. The patch could
probably be improved: The check for strings with more than 31 chars
should probably be less hard-coded, but I'm not sure which contant to
use for determining maximum size of a LONG.

/Troels

--- php4-orig/ext/standard/math.c   Sun Aug  5 12:51:38 2001
+++ php4/ext/standard/math.cSun Aug  5 12:52:35 2001
@@ -813,6 +813,11 @@
}
 
convert_to_string_ex(arg);
+
+   if ((*arg)->value.str.len > 31) {
+   php_error(E_WARNING, "bindec: input string too long (max is a 31-bit 
+value)");
+   }
+
ret = _php_math_basetolong(*arg, 2);
 
RETVAL_LONG(ret);

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

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

[Troels Arvin]

On Thu, 02 Aug 2001 19:16:26 +0200, "Stanislav Malyshev" <[EMAIL PROTECTED]>
wrote:

> on the quick glance your patch looks OK.
OK. It seems that I don't have sufficient karma.

I tried to commit the below patch with the following commit message:
(gmp_init) Added extra (optional) argument to gmp_init():
   a base argument which indicates the number base. E.g.:
   gmp_init('1010101010',2); // feed gmp a binary value.
@- Added optional extra argument to gmp_init(). The extra argument
@  indicates which number base gmp should use when converting a
@  string to the gmp-number. (Troels)

Suggested patch is attached below (the patch is against current CVS).

/Troels

--- php4-orig/ext/gmp/gmp.c Sun Aug  5 12:51:42 2001
+++ php4/ext/gmp/gmp.c  Sun Aug  5 13:24:02 2001
@@ -178,7 +178,7 @@
 if(Z_TYPE_PP(zval) == IS_RESOURCE) { \
ZEND_FETCH_RESOURCE(gmpnumber, mpz_t *, zval, -1, GMP_RESOURCE_NAME, le_gmp);\
 } else {\
-   if(convert_to_gmp(&gmpnumber,zval) == FAILURE) {\
+   if(convert_to_gmp(&gmpnumber,zval,0) == FAILURE) {\
RETURN_FALSE;\
}\
ZEND_REGISTER_RESOURCE(NULL, gmpnumber, le_gmp);\
@@ -190,7 +190,7 @@
 
 /* {{{ convert_to_gmp
  * Convert zval to be gmp number */
-static int convert_to_gmp(mpz_t * *gmpnumber, zval **val) 
+static int convert_to_gmp(mpz_t * *gmpnumber, zval **val, int base) 
 {
int ret = 0;
 
@@ -207,11 +207,14 @@
case IS_STRING:
{
char *numstr = Z_STRVAL_PP(val);
-   if(numstr[0] == '0' && (numstr[1] == 'x' || numstr[1] == 'X')) 
{
-   ret = mpz_init_set_str(**gmpnumber, numstr+2, 16);
-   } else {
-   ret = mpz_init_set_str(**gmpnumber, numstr, 10);
+   if (base==0) {
+   if(numstr[0] == '0' && (numstr[1] == 'x' || numstr[1] 
+== 'X')) {
+   base=16;
+   } else {
+   base=10;
+   }
}
+   ret = mpz_init_set_str(**gmpnumber, numstr, base);
}
break;
default:
@@ -434,22 +437,30 @@
 }
 /* }}} */
 
-/* Remove the following function when you have succesfully modified config.m4
-   so that your module can be compiled into PHP, it exists only for testing
-   purposes. */
-
-/* {{{ proto resource gmp_init(mixed number)
+/* {{{ proto resource gmp_init(mixed number [, int base])
Initializes GMP number */
 ZEND_FUNCTION(gmp_init)
 {
-   zval **number_arg;
+   zval **number_arg, **base_arg;
mpz_t * gmpnumber;
+   int argc;
+   int base=0;
 
-   if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &number_arg) == FAILURE){
+   argc = ZEND_NUM_ARGS();
+   if (argc < 1 || argc > 2 || zend_get_parameters_ex(argc, &number_arg, 
+&base_arg) == FAILURE){
WRONG_PARAM_COUNT;
}
 
-   if(convert_to_gmp(&gmpnumber,number_arg) == FAILURE) {
+   if (argc==2) {
+   convert_to_long_ex(base_arg);
+   base = Z_LVAL_PP(base_arg);
+   if(base < 2 || base > 36) {
+   zend_error(E_WARNING, "Bad base for conversion: %d (should be 
+between 2 and 36)", base);
+   RETURN_FALSE;
+   }
+   }
+
+   if(convert_to_gmp(&gmpnumber,number_arg,base) == FAILURE) {
RETURN_FALSE;
}

-- 
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: Shared imap extension..

[Troels Arvin]

On Sun, 05 Aug 2001 11:52:02 +0200, "Jani Taskinen" <[EMAIL PROTECTED]>
wrote:

>>The shared imap extension used to be called "imap.so". Now it's called
>>"imap.a". Personally, I don't care, but maybe it will cause some
> 
> What was your configure line? It should create a .so NOT .a (works for
> me)
See below.

> Did you use phpize?
No.

PHP code-base:
PHP-snapshot php4-200108050135

Imap-devel package:
2000c. The package was built with ssl-support, but without kerberos
support, see
http://rpms.arvin.dk/imap-no_kerberos/
(Based on Red Hat Rawhide, but without Kerberos stuff.)

Contents of config.nice:
---
#! /bin/sh
#
# Created by configure

CFLAGS='-O2 -march=i686' \
CXXFLAGS='-O2 -march=i686' \
'./configure' \
'--prefix=/home/troels/local-php' \
'--without-mysql' \
'--disable-session' \
'--disable-xml' \
'--with-imap=shared' \
'--with-imap-ssl' \
'--without-pcre-regex' \
"$@"
---

Output from "./configure", relevant to this issue:
---
...
checking for IMAP support... yes, shared
...
creating ext/imap/Makefile
...
---

Output from "make", relevant to this issue:
---
...
make[1]: Entering directory `/home/troels/temp2/php4-200108050135/ext'
Making all in imap
make[2]: Entering directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[3]: Entering directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[3]: Nothing to be done for `all-p'.
make[3]: Leaving directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[2]: Leaving directory `/home/troels/temp2/php4-200108050135/ext/imap'
...
Making install in imap
make[2]: Entering directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[3]: Entering directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[3]: Nothing to be done for `install-p'.
make[3]: Leaving directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[2]: Leaving directory `/home/troels/temp2/php4-200108050135/ext/imap'
...
---

The imap.a file contains one object-file: php_imap.o

Content of ext/imap/libs.mk:
---
include $(top_builddir)/config_vars.mk
LTLIBRARY_OBJECTS = $(LTLIBRARY_SOURCES:.c=.lo) $(LTLIBRARY_OBJECTS_X)
LTLIBRARY_SHARED_OBJECTS = $(LTLIBRARY_OBJECTS:.lo=.slo)
$(LTLIBRARY_SHARED_NAME): $(LTLIBRARY_SHARED_OBJECTS) $(LTLIBRARY_DEPENDENCIES)
$(SHARED_LIBTOOL) --mode=link $(COMPILE) $(LDFLAGS) -o $@ -avoid-version 
-module -rpath $(phplibdir) $(LTLIBRARY_LDFLAGS) $(LTLIBRARY_OBJECTS) 
$(LTLIBRARY_SHARED_LIBADD)
$(SHARED_LIBTOOL) --mode=install cp $@ $(phplibdir)

targets = $(LTLIBRARY_SHARED_NAME)
---

Content of ext/imap/imap.la:
---
# imap.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.4 (1.920 2001/04/24 23:26:18)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='imap.a'

# Libraries that this one depends upon.
dependency_libs=' -lcrypto -lssl -lc-client'

# Version information for imap.
current=0
age=0
revision=0

# Is this an already installed library?
installed=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/home/troels/temp2/php4-200108050135/modules'
---

Content of ext/imap/Makefile:
---
top_srcdir   = /home/troels/temp2/php4-200108050135
top_builddir = /home/troels/temp2/php4-200108050135
srcdir   = /home/troels/temp2/php4-200108050135/ext/imap
builddir = /home/troels/temp2/php4-200108050135/ext/imap
VPATH= /home/troels/temp2/php4-200108050135/ext/imap

LTLIBRARY_NAME= libimap.la
LTLIBRARY_SOURCES = php_imap.c
LTLIBRARY_SHARED_NAME = imap.la
LTLIBRARY_SHARED_LIBADD = $(IMAP_SHARED_LIBADD)

include $(top_srcdir)/build/dynlib.mk
---

-- 
Greetings from Troels Arvin, Copenhagen, Denmark



-- 
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: Shared imap extension..

[Troels Arvin]

On Sun, 05 Aug 2001 11:52:02 +0200, "Jani Taskinen" <[EMAIL PROTECTED]>
wrote:

>>The shared imap extension used to be called "imap.so". Now it's called
>>"imap.a". Personally, I don't care, but maybe it will cause some
> 
> What was your configure line? It should create a .so NOT .a (works for
> me)
See below.

> Did you use phpize?
No.

PHP code-base:
PHP-snapshot php4-200108050135

Imap-devel package:
2000c. The package was built with ssl-support, but without kerberos
support, see
http://rpms.arvin.dk/imap-no_kerberos/
(Based on Red Hat Rawhide, but without Kerberos stuff.)

Contents of config.nice:
---
#! /bin/sh
#
# Created by configure

CFLAGS='-O2 -march=i686' \
CXXFLAGS='-O2 -march=i686' \
'./configure' \
'--prefix=/home/troels/local-php' \
'--without-mysql' \
'--disable-session' \
'--disable-xml' \
'--with-imap=shared' \
'--with-imap-ssl' \
'--without-pcre-regex' \
"$@"
---

Output from "./configure", relevant to this issue:
---
...
checking for IMAP support... yes, shared
...
creating ext/imap/Makefile
...
---

Output from "make", relevant to this issue:
---
...
make[1]: Entering directory `/home/troels/temp2/php4-200108050135/ext'
Making all in imap
make[2]: Entering directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[3]: Entering directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[3]: Nothing to be done for `all-p'.
make[3]: Leaving directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[2]: Leaving directory `/home/troels/temp2/php4-200108050135/ext/imap'
...
Making install in imap
make[2]: Entering directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[3]: Entering directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[3]: Nothing to be done for `install-p'.
make[3]: Leaving directory `/home/troels/temp2/php4-200108050135/ext/imap'
make[2]: Leaving directory `/home/troels/temp2/php4-200108050135/ext/imap'
...
---

The imap.a file contains one object-file: php_imap.o

Content of ext/imap/libs.mk:
---
include $(top_builddir)/config_vars.mk
LTLIBRARY_OBJECTS = $(LTLIBRARY_SOURCES:.c=.lo) $(LTLIBRARY_OBJECTS_X)
LTLIBRARY_SHARED_OBJECTS = $(LTLIBRARY_OBJECTS:.lo=.slo)
$(LTLIBRARY_SHARED_NAME): $(LTLIBRARY_SHARED_OBJECTS) $(LTLIBRARY_DEPENDENCIES)
$(SHARED_LIBTOOL) --mode=link $(COMPILE) $(LDFLAGS) -o $@ -avoid-version 
-module -rpath $(phplibdir) $(LTLIBRARY_LDFLAGS) $(LTLIBRARY_OBJECTS) 
$(LTLIBRARY_SHARED_LIBADD)
$(SHARED_LIBTOOL) --mode=install cp $@ $(phplibdir)

targets = $(LTLIBRARY_SHARED_NAME)
---

Content of ext/imap/imap.la:
---
# imap.la - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.4 (1.920 2001/04/24 23:26:18)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.

# The name that we can dlopen(3).
dlname=''

# Names of this library.
library_names=''

# The name of the static archive.
old_library='imap.a'

# Libraries that this one depends upon.
dependency_libs=' -lcrypto -lssl -lc-client'

# Version information for imap.
current=0
age=0
revision=0

# Is this an already installed library?
installed=no

# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''

# Directory that this library needs to be installed in:
libdir='/home/troels/temp2/php4-200108050135/modules'
---

Content of ext/imap/Makefile:
---
top_srcdir   = /home/troels/temp2/php4-200108050135
top_builddir = /home/troels/temp2/php4-200108050135
srcdir   = /home/troels/temp2/php4-200108050135/ext/imap
builddir = /home/troels/temp2/php4-200108050135/ext/imap
VPATH= /home/troels/temp2/php4-200108050135/ext/imap

LTLIBRARY_NAME= libimap.la
LTLIBRARY_SOURCES = php_imap.c
LTLIBRARY_SHARED_NAME = imap.la
LTLIBRARY_SHARED_LIBADD = $(IMAP_SHARED_LIBADD)

include $(top_srcdir)/build/dynlib.mk
---

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Bug #12241 Updated: imap.so: undefined symbol:

[Troels Arvin]

On Wed, 01 Aug 2001 03:04:29 +0200, "Jani Taskinen" <[EMAIL PROTECTED]>
wrote:

> I guess this problem exists only when it's configured as shared
> extension? If so, I know how to fix it..

I just tried the latest snapshot.

Now everything works.

One last strange thing:
The shared imap extension used to be called "imap.so". Now it's called
"imap.a". Personally, I don't care, but maybe it will cause some
confusion and a new wave of bug reports because people aren't aware that
their php.ini files need to be adjusted.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
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: gmp_init with a base argument

[Troels Arvin]

On Mon, 30 Jul 2001 22:13:32 +0200, I wrote:
> Because decbin is limited to 31 bit values, I thought that the gmp
> extension might be expanded a bit: If you add an optional base argument
> to gmp, then we actually have a -bit decbin. I think that
> would be nice.
[...]

I have received no comments about the above. The patch in question is
also at:
http://troels.arvin.dk/php-patches/gmp/gmp_init-with_base.patch.txt

The idea is that gmp_init() may be called with an optional extra
argument used to indicate the number base when interpreting strings.
This means that one may now feed gmp long binary values (which is
currently not possible without ugly hacks):
gmp_init('1010101010101010101010101010101010101010',2);

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

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

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Re: [PHP-DEV] Re: Bug #12241 Updated: imap.so: undefined symbol:

[Troels Arvin]

On Wed, 01 Aug 2001 03:04:29 +0200, "Jani Taskinen" <[EMAIL PROTECTED]>
wrote:

> I guess this problem exists only when it's configured as shared
> extension? 
True

> If so, I know how to fix it..
That would be great.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
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] gmp_init with a base argument

[Troels Arvin]

Hello,

Because decbin is limited to 31 bit values, I thought that the gmp
extension might be expanded a bit: If you add an optional base argument
to gmp, then we actually have a -bit decbin. I think that
would be nice.

Proposed patch below.
(The patch is for php 4.0.6; I can easily make one for php-cvs if
wanted.)

diff -u php-4.0.6-orig/ext/gmp/gmp.c php-4.0.6/ext/gmp/gmp.c
--- php-4.0.6-orig/ext/gmp/gmp.cThu May 24 14:41:52 2001
+++ php-4.0.6/ext/gmp/gmp.c Mon Jul 30 22:01:55 2001
@@ -160,7 +160,7 @@
 if(Z_TYPE_PP(zval) == IS_RESOURCE) { \
ZEND_FETCH_RESOURCE(gmpnumber, mpz_t *, zval, -1, GMP_RESOURCE_NAME, le_gmp);\
 } else {\
-   if(convert_to_gmp(&gmpnumber,zval) == FAILURE) {\
+   if(convert_to_gmp(&gmpnumber,zval,0) == FAILURE) {\
RETURN_FALSE;\
}\
ZEND_REGISTER_RESOURCE(NULL, gmpnumber, le_gmp);\
@@ -170,8 +170,8 @@
 #define INIT_GMP_NUM(gmpnumber) { gmpnumber=emalloc(sizeof(mpz_t)); 
mpz_init(*gmpnumber); }
 #define FREE_GMP_NUM(gmpnumber) { mpz_clear(*gmpnumber); efree(gmpnumber); }
 
-/* Convert zval to be gmp number */
-static int convert_to_gmp(mpz_t * *gmpnumber, zval **val) 
+/* Convert string to be gmp number */
+static int convert_to_gmp(mpz_t * *gmpnumber, zval **val, int base)
 {
int ret = 0;
 
@@ -188,11 +188,14 @@
case IS_STRING:
{
char *numstr = Z_STRVAL_PP(val);
-   if(numstr[0] == '0' && (numstr[1] == 'x' || numstr[1] == 'X')) 
{
-   ret = mpz_init_set_str(**gmpnumber, numstr+2, 16);
-   } else {
-   ret = mpz_init_set_str(**gmpnumber, numstr, 10);
+   if (base==0) {
+   if(numstr[0] == '0' && (numstr[1] == 'x' || numstr[1] 
+== 'X')) {
+   base=16;
+   } else {
+   base=10;
+   }
}
+   ret = mpz_init_set_str(**gmpnumber, numstr, base);
}
break;
default:
@@ -391,22 +394,31 @@
 }
 
 
-/* Remove the following function when you have succesfully modified config.m4
-   so that your module can be compiled into PHP, it exists only for testing
-   purposes. */
-
-/* {{{ proto resource gmp_init(mixed number)
+/* {{{ proto resource gmp_init(mixed number [, int base ])
Initializes GMP number */
 ZEND_FUNCTION(gmp_init)
 {
-   zval **number_arg;
+   zval **number_arg, **base_arg;
mpz_t * gmpnumber;
+   int argc;
+   int base=0;
 
-   if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &number_arg) == FAILURE){
+   argc = ZEND_NUM_ARGS();
+   if (argc < 1 || argc > 2 || zend_get_parameters_ex(argc, &number_arg, 
+&base_arg) == FAILURE){
WRONG_PARAM_COUNT;
}
 
-   if(convert_to_gmp(&gmpnumber,number_arg) == FAILURE) {
+   if (argc==2) {
+   convert_to_long_ex(base_arg);
+   base = Z_LVAL_PP(base_arg);
+   }
+
+   if(base < 2 || base > 36) {
+   zend_error(E_WARNING, "Bad base for conversion: %d (should be between 
+2 and 36)", base);
+   RETURN_FALSE;
+   }
+
+   if(convert_to_gmp(&gmpnumber,number_arg,base) == FAILURE) {
RETURN_FALSE;
}

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
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 #12450: Segfaults if recode is loaded after mysql or imap

[troels]

From: [EMAIL PROTECTED]
Operating system: Red Hat Linux 6.2
PHP version:  4.0.6
PHP Bug Type: Recode related
Bug description:  Segfaults if recode is loaded after mysql or imap

PHP segfaults if recode.so (php's recode extension as a shared library) is
loaded _after_ the imap or mysql extensions. Re-ordering the php.ini file
so that the "extension=recode.so" line is the first "extension=..."-line
stops the segfaults.

Recode versions tested: 3.5d, 3.6.

PHP versions tested: 4.0.6.

config.nice:


#! /bin/sh
#
# Created by configure

"./configure" \
"--prefix=/usr" \
"--libdir=/usr/lib/php4" \
"--includedir=/usr/include" \
"--datadir=/usr/share/php" \
"--with-config-file-path=/etc" \
"--enable-discard-path" \
"--enable-inline-optimization" \
"--enable-magic-quotes" \
"--enable-track-vars" \
"--enable-memory-limit" \
"--enable-wddx" \
"--enable-bcmath" \
"--enable-sigchild" \
"--with-xml" \
"--with-mm" \
"--with-openssl" \
"--enable-ftp=shared" \
"--enable-exif=shared" \
"--with-gd=shared,/usr" \
"--with-ttf" \
"--enable-gd-imgstrttf" \
"--with-png-dir=/usr" \
"--with-jpeg-dir=/usr" \
"--enable-sysvsem=shared" \
"--enable-sysvshm=shared" \
"--enable-shmop=shared" \
"--with-unixODBC=shared" \
"--with-mysql=shared,/usr" \
"--with-ldap=shared" \
"--with-pgsql=shared" \
"--with-gettext=shared" \
"--with-pspell=shared" \
"--with-snmp=shared" \
"--enable-ucd-snmp-hack" \
"--with-sybase-ct=shared,/usr" \
"--with-pdflib=shared" \
"--with-oci8=shared" \
"--with-swf=shared,/home/troels/rpm/BUILD/php-4.0.6/swflib" \
"--enable-sockets=shared" \
"--with-gmp=shared" \
"--with-dom=shared" \
"--with-qtdom=shared,/usr/lib/qt-2.3.0" \
"--with-iconv=shared" \
"--with-curl=shared" \
"--enable-apc=shared" \
"--with-ming=shared" \
"--with-imlib=shared" \
"--with-recode=shared" \
"--with-zlib=/usr" \
"$@"

php.ini:


extension_dir   =   /usr/lib/php4

;; Global PHP defaults

warn_plus_overloading   =   On  ; warn if the + operator is used
with strings
track_errors=   On  ; Store the last error/warning
message in $php_errormsg (boolean)
track_vars  =   On  ; enable the $HTTP_*_VARS[] arrays,
where * is one of

magic_quotes_gpc=   On  ; magic quotes for incoming
GET/POST/Cookie data
; many people think that the system
is a pain in the
; a**, but it probably does
represent a security
; feature for in-experienced PHP
developers. Turn it
; off if you don't want PHP to mess
with your incoming
; variables.
include_path= ".:/usr/share/php/PEAR:/usr/share/php/imlib"
session.save_path = "/var/state/php"
extension=php_apc.so
extension=domxml.so
extension=exif.so
extension=ftp.so
extension=gd-with_gif.so
extension=gettext.so
extension=gmp.so
extension=iconv.so
extension=imlib.so
extension=ldap.so
extension=pdf.so
extension=pgsql.so
extension=pspell.so
extension=sablot.so
extension=snmp.so
extension=sockets.so
extension=swf.so
extension=sybase_ct.so
extension=sysvshm.so
extension=sysvsem.so
extension=shmop.so
extension=odbc.so
extension=curl.so
extension=mysql.so
extension=recode.so


Back-trace:
===

GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libpam.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /usr/lib/libssl.so.0...done.
Reading symbols from /usr/lib/libcrypto.so.0...done.
Reading symbols from /usr/lib/libz.so.1...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /lib/libc.

[PHP-DEV] Re: Bug #12241 Updated: imap.so: undefined symbol: mxdriver in Unknown on line 0

[Troels Arvin]

On Thu, 19 Jul 2001 03:01:03 +0200, "jmmele" <[EMAIL PROTECTED]>
wrote:

> all the modules I compile are working but imap.so

I have found the same problem with PHP 4.0.6 - on two different Red Hat
Linux generations.

I know about all the "tricks" regarding --with-imap-ssl and
--with-imap-kerberos, but none of them helped. Neither did changing imap
version.

Now, I have found a hack which seems to work, for some strange reason:

Don't use --with-imap

Instead, after the rest of PHP has compiled, go to the php source-dir and
do:

gcc -fPIC -shared -DCOMPILE_DL_IMAP -DHAVE_IMAP \
  -I. -I./TSRM -I./main -I`/usr/include/apache -I./Zend \
  -I/usr/include/imap -I./ext/imap \
  `grep ^CPPFLAGS Zend/Makefile | cut -f2- -d=` -DHAVE_IMAP2000 \
  -DHAVE_IMAP_SSL ext/imap/php_imap.c -o modules/imap.so \
  -L.libs /usr/lib/c-client.a -lssl -lcrypto -lc

(Notice the _back_-ticks around the grep-expression.)

Note that there are no references to Kerberos. That's because I use a
version of imap-devel which doesn't have Kerberos bloat:
http://rpms.arvin.dk/imap-no_kerberos/

PS:
This php-imap problem did not exist in previous PHP versions.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

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

[Troels Arvin]

On Fri, 27 Jul 2001 23:00:54 +0200, "Brian Tanner" <[EMAIL PROTECTED]>
wrote:

> *If* there will be:
> 
> $_Get[]
> $_Post[]
> $_Cookie[]
> 
> -- can we also have something else to the tune of:
> 
> $_External or $_User or $_Something

Important point. It's stupid if we suddenly have to hard-code for
GET/POST/cookie-generated data. The interesting bit is to be aware of
what data which has external origin.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
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 #10578 Updated: Serious: Mac line-feeds not recognized as linefeeds in code any more

[troels]

ID: 10578
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Description: Serious: Mac line-feeds not recognized as linefeeds in code any more



Previous Comments:
---

[2001-05-01 09:00:41] [EMAIL PROTECTED]
Mac (r) linefeeds seem to be parsed as non-line feeds since
PHP 4.0.5 (no problem in 4.0.4pl1). In my opinion, that's a
serious show-stopper at many sites.

Demonstration and more information (including
configure-command) at http://schmidt.tv2.dk/public/linefeedbug/


---


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


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

Re: [PHP-DEV] Mac OS X newline patch

[Troels Arvin]

On Wed, 02 May 2001 23:25:36 +0200, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:

> Attached is a patch which should allow the scripting engine to also
> allow \r as line delimiters.
Thanks; it works. Bug #10578 has been closed.

> If someone on Mac OS X who has had
> problems can test this and send me feedback that would be great.
Note:
This was _not_ a Mac OS _X_ problem. It was general problem with
Mac-style newlines in text containing PHP code. Access to a Mac is not
needed to verify that the bug has been squashed.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
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 #10578 Updated: Serious: Mac line-feeds not recognized as linefeeds in code any more

[troels]

ID: 10578
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Description: Serious: Mac line-feeds not recognized as linefeeds in code any more

Andi Gutmans has fixed this bug through changes to
Zend/zend_language_scanner.l and Zend/zend_ini_scanner.l


Previous Comments:
---

[2001-05-01 09:00:41] [EMAIL PROTECTED]
Mac (r) linefeeds seem to be parsed as non-line feeds since
PHP 4.0.5 (no problem in 4.0.4pl1). In my opinion, that's a
serious show-stopper at many sites.

Demonstration and more information (including
configure-command) at http://schmidt.tv2.dk/public/linefeedbug/


---


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


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

Re: [PHP-DEV] 4.0.6

[Troels Arvin]

On Wed, 02 May 2001 21:58:03 +0200, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
>>I think that bug #10578 is a very serious problem which should be
>>looked at before thinking about releasing 4.0.6.
> 
> Do you have any idea what it could be? I don't have access to 
> Mac OS X.

It's not related to Mac OS X; PHP is executed on a Linux host.

The problem occurs when a web-developer using a Mac editor edits PHP
code: If he writes PHP code and his editor uses \r as linefeeds in the
PHP code, then the strange phenomenon may arise.

> Do you have an extremely short reproducing script?
It's best demonstrated by going to http://schmidt.tv2.dk/public/linefeedbug/

Note that there was no such problem with PHP 4.0.4pl1 and earlier.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
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 #10578: Serious: Mac line-feeds not recognized as linefeeds in code any more

[Troels Arvin]

On Tue, 01 May 2001 18:36:15 +0200, "Ukendt domæne" <[EMAIL PROTECTED]>
wrote:

> Demonstration and more information (including configure-command) at
> http://schmidt.tv2.dk/public/linefeedbug/

Zend/zend_language_scanner.l seems to have gone through some changes
between 4.0.4pl1 and 4.0.5 which could affect how PHP interprets
whitespace (including \r) in relation to one-line comments. However, I
have no lex knowledge.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

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

[Troels Arvin]

On Wed, 02 May 2001 13:52:58 +0200, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:

> I think we should make a list of known 4.0.5 bugs which need to be
> fixed for 4.0.6

I think that bug #10578 is a very serious problem which should be looked
at before thinking about releasing 4.0.6.

By the way:
The problem _could_ be related to bug #10609.

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

-- 
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 #10578: Serious: Mac line-feeds not recognized as linefeeds in code any more

[troels]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.5
PHP Bug Type: Scripting Engine problem
Bug description:  Serious: Mac line-feeds not recognized as linefeeds in code any more

Mac (\r) linefeeds seem to be parsed as non-line feeds since
PHP 4.0.5 (no problem in 4.0.4pl1). In my opinion, that's a
serious show-stopper at many sites.

Demonstration and more information (including
configure-command) at http://schmidt.tv2.dk/public/linefeedbug/



-- 
Edit Bug report at: http://bugs.php.net/?id=10578&edit=1



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

Re: [PHP-DEV] mcrypt & oracle 81

[Troels Arvin]

I artikel <[EMAIL PROTECTED]>, skrev
[EMAIL PROTECTED] :

> i'm trying to get PHP 4.0.4pl1 working with mcrypt 2.4.7 and oracle
> 8i...

My experience is that the two don't mix.

The manual says this about the mcrypt extension:
   Make sure you compile libmcrypt with the option 
   --disable-posix-threads

However, the OCI8 extension links the pthread library.

Maybe that could be an explanation?

-- 
Greetings from Troels Arvin, Copenhagen, Denmark

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