Re: [PHP-DEV] ODBC Prepare

[Adam Voigt]

Apologies if this was on the wrong list, since the problem was

what I thought was an un-implented feature of the library in PHP's source,

I assumed I should ask the PHP developer's.



I assumed it was un-implemented because I saw no reference to this

ability on the manual page for ODBC or ODBC_Prepare, and PEAR

seems to be doing it with just PHP code (not the odbc_prepare extension).





On Mon, 2003-02-10 at 21:58, Dan Kalowsky wrote:

This is really a support question and is being asked on the wrong list.



But in light of that... PHP's odbc_prepare function should work with 

the '?' option.  It really isn't the one deciding this though, as it's 

more your ODBC Driver.  As far as PEAR is concerned, I have little 

insight into that aspect of PHP.  Your best bet is to ask PEAR 

developers or read the source.



On Monday, February 10, 2003, at 11:48 AM, Adam Voigt wrote:



> According to a manual I found on the web for call's to "SQLPrepare"

> (referenced in ext/odbc/php_odbc.c) you can implant "?" in place of

> variables for statement execution. PearDB makes reference to this

> on:

>

> http://pear.php.net/manual/en/core.db.tut_execute.php

>

> So my question is, is PHP's ODBC programming just not setup to handle

> this (and is Pear doing this manually with PHP) or am I

> mis-understanding
    
    > the way the library works in PHP?

>

> Thanks,

>

> Adam Voigt

> [EMAIL PROTECTED]

>

 >---<

Dan Kalowsky"I've learned to fake it,

http://www.deadmime.org/~dankand just smile along."

[EMAIL PROTECTED]- "Candy",

[EMAIL PROTECTED]  Iggy Pop






-- 
Adam Voigt ([EMAIL PROTECTED])
The Cryptocomm Group
My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc








signature.asc
Description: This is a digitally signed message part

[PHP-DEV] ODBC Prepare

[Adam Voigt]

According to a manual I found on the web for call's to "SQLPrepare"
(referenced in ext/odbc/php_odbc.c) you can implant "?" in place of
variables for statement execution. PearDB makes reference to this
on:

http://pear.php.net/manual/en/core.db.tut_execute.php

So my question is, is PHP's ODBC programming just not setup to handle
this (and is Pear doing this manually with PHP) or am I
mis-understanding
the way the library works in PHP?

Thanks,

Adam Voigt
[EMAIL PROTECTED]

[PHP-DEV] Make Windows PHP Fork

[Adam Voigt]

Is it possible to make the php.exe under
window's fork, so it isn't visible in the
start bar? I ask because I would like to
make a PHP program that runs periodically
in the background, and I know how to start
it at computer start time, but it makes that
damned dos window pop up. There are
external programs to make it be hidden
but they require seperate install's which
makes it not an option. Any ideas?

Thanks very much,

Adam Voigt
[EMAIL PROTECTED]

Re: [PHP-DEV] memory usage

[Adam Maccabee Trachtenberg]

On Fri, 31 Jan 2003, Adam Maccabee Trachtenberg wrote:

> If PHP is built with the --enable-memory-limit configuration option, it
> stores the peak memory usage of each request in a note called
> mod_php_memory_usage. Add the memory usage information to a LogFormat
> with: 
> 
> %{mod_php_memory_usage}n

Er... by "note" I mean Apache note and LogFormat is for Apache's
access log.

-adam


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

Re: [PHP-DEV] memory usage

[Adam Maccabee Trachtenberg]

On 31 Jan 2003, Walt Boring wrote:

> Is there a way for me to log the peak memory usage for a php script for
> php 4.3.0 ?

If PHP is built with the --enable-memory-limit configuration option, it
stores the peak memory usage of each request in a note called
mod_php_memory_usage. Add the memory usage information to a LogFormat
with: 

%{mod_php_memory_usage}n

-adam

-- 
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!


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

Re: [PHP-DEV] [PATCH] jpeg2000 in php 4.3

[Adam Wright]

Have regenerated the diffs in unified format as well as fixed a minor bug in
the JP2 support. I've put together a small page at

http://www.j2g.org/php-dev/

It contains the patch, test script and a couple of example images in both
raw codestream and JP2 format.

adamw

- Original Message -
From: "Marcus Börger" <[EMAIL PROTECTED]>
To: "Adam Wright" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, January 16, 2003 7:40 PM
Subject: Re: [PHP-DEV] jpeg2000 in php 4.3


> At 13:50 16.01.2003, Adam Wright wrote:
> >I've completed a short patch which cleans up the JPEG 2000 raw codestream
> >support ("j2c", though I've renamed it jpeg2000 in the file for clarity)
in
> >getimagesize. It also adds JP2 support. I've put a context diff of it
> >against 4.3.x-dev from this morning up at...
>
> I have just updated my HEAD version and did a few changes and it works
> very well.
>
> >Small changes have been made to ext/standard/php_image.h with 99% of the
> >work in ext/standard/image.c. I've tried to apply CODING_STANDARDS, but
it's
> >probable I've messed up somewhere so I'm happy to make any changes or
> >regenerate the diffs in other formats.
>
> You did good coding and style (but we prefer unified diffs "diff -u").
>
> >If this gets applied, it might be worth adding something like the
following
> >to the documentation.
>
> It will be but it is to be discussed if it will go into 4.3.1: I'd say yes
> because
> the note in the manual.
>
> >"Note that JPEG 2000 and JP2 are capable of having components with
differing
> >bit depths. In this case, the value for "bits" is the highest bit depth
> >encountered. Also, JP2 files can contain multiple JPEG 2000 codestreams.
In
> >this case, getimagesize returns the values for the first codestream it
> >encounters in the root of the file."
>
> Yes such a note may be useful.
>
> >Hope it's useful.
> >
> >adamw
> >[EMAIL PROTECTED]
> >
> >PS - I looked around but couldn't find any patch submission guidelines.
Is
> >there a page people should read first?
>
> As said above diff -u is prefered.
>
> regards & thanks
> marcus
>
> by the way:could you send me a 1 x 1 jp2 file, because i am not able to
produce
> one my self?
>
>
>


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

Re: [PHP-DEV] jpeg2000 in php 4.3

[Adam Wright]

I've completed a short patch which cleans up the JPEG 2000 raw codestream
support ("j2c", though I've renamed it jpeg2000 in the file for clarity) in
getimagesize. It also adds JP2 support. I've put a context diff of it
against 4.3.x-dev from this morning up at...

http://www.j2g.org/patches/jpeg2000imgdiff.patch

Small changes have been made to ext/standard/php_image.h with 99% of the
work in ext/standard/image.c. I've tried to apply CODING_STANDARDS, but it's
probable I've messed up somewhere so I'm happy to make any changes or
regenerate the diffs in other formats.

If this gets applied, it might be worth adding something like the following
to the documentation.

"Note that JPEG 2000 and JP2 are capable of having components with differing
bit depths. In this case, the value for "bits" is the highest bit depth
encountered. Also, JP2 files can contain multiple JPEG 2000 codestreams. In
this case, getimagesize returns the values for the first codestream it
encounters in the root of the file."

Hope it's useful.

adamw
[EMAIL PROTECTED]

PS - I looked around but couldn't find any patch submission guidelines. Is
there a page people should read first?

- Original Message -
From: "Marcus Börger" <[EMAIL PROTECTED]>
To: "Adaloglou Maria" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, January 10, 2003 11:31 AM
Subject: Re: [PHP-DEV] jpeg2000 in php 4.3


> At 10:10 10.01.2003, Adaloglou Maria wrote:
> >As I have read in the manual about the getimagesize function that
> >"Note: JPEG2000 support will be added in PHP 4.3. "
> >Do you know if it is supported finaly?
>
> No - at the moment there is only support for jpc.
> sorry i haven't yet the time to read through the complete
> jpeg2000 specs.
>
> marcus
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

[Adam Wright]

Agreed, on second thoughts those weren't terribly great example choices.

I'm just coming from the point of view that you're generally better off not
alienating someone for posting a bug before they've had their caffeine
injection as they may in the future discover a legitimate bug which would be
usefully reported. I certainly agree that the report is "Bogus", it's just
the terminology I was questioning. I suppose it's a culture thing, but the
"bogus" status sounds rather harsh/rude to me (from the UK) even though I
know its never (generally ;) intended to be. Even something like "Invalid"
sounds better.

Guess it's just a personal preference. I'll go back to my lurking now :)

adamw

- Original Message -
From: "Ilia A." <[EMAIL PROTECTED]>
To: "Adam Wright" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 15, 2003 3:39 PM
Subject: Re: [PHP-DEV] Re: #21659 [Com]: sprintf


> On January 15, 2003 10:27 am, Adam Wright wrote:
> > Last ditch effort of "NotAPHPBug"? ;)
>
> This too may not be a correct solution all the time. Consider 75th
duplicate
> report of an invalid or even a resolved bug report. It may have been a bug
at
> some point, but certainly is not anymore. It is bogus, because the user
chose
> not to search in the bug database for similar reports before posting their
> report. Surely you can agree that such a report is bogus.
> I suppose we could introduce a dozen different more 'friendly' statuses to
> replace the existing bogus status, but why? Surely not for the purpose of
> making users who don't do the necessary research before posting their bug
> reports feel better about themselves.
>
> Ilia
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

Re: [PHP-DEV] Re: #21659 [Com]: sprintf

[Adam Wright]

Last ditch effort of "NotAPHPBug"? ;)

adamw

- Original Message -
From: "Derick Rethans" <[EMAIL PROTECTED]>
To: "Ilia A." <[EMAIL PROTECTED]>
Cc: "Adam Wright" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 15, 2003 3:21 PM
Subject: Re: [PHP-DEV] Re: #21659 [Com]: sprintf


> On Wed, 15 Jan 2003, Ilia A. wrote:
>
> > On January 15, 2003 10:14 am, Adam Wright wrote:
> > > Agreed in general. And whilst I'm here can I throw in my 2c about
"Bogus"?
> > > Although an accurate description, it's hardly likely to be perceived
as
> > > friendly. If you've taken the time to report a bug, even if you are in
> > > error, having it thrown back as "Bogus" seems pretty mean. How about a
less
> > > antagonistic wording? I'd put forward something like "NotaBug", which
gives
> > > the same information without putting people's backs up.
> >
> > "NotaBug" or similar may lead to confusion. Quite often the issue may
indeed
> > be a bug, however it is not a bug in PHP and is therefor bogus. By
marking
> > such a bug report "NotaBug" may lead to confusion.
> > IMO bogus is a fairly accurate representation of what the 'bogus' bug
reports
> > are, it is no more or less friendly then other bug status and is only a
> > problem (less 'friendly') if you choose to make it such.
>
> +1 on on that, but I do think that when a bug is set to bogus the reason
> why it is bogus should always be noted.
>
> Derick
>
> --
>
> -
>  Derick Rethans http://derickrethans.nl/
>  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> -
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

[PHP-DEV] Re: #21659 [Com]: sprintf

[Adam Wright]

Agreed in general. And whilst I'm here can I throw in my 2c about "Bogus"?
Although an accurate description, it's hardly likely to be perceived as
friendly. If you've taken the time to report a bug, even if you are in
error, having it thrown back as "Bogus" seems pretty mean. How about a less
antagonistic wording? I'd put forward something like "NotaBug", which gives
the same information without putting people's backs up.

adamw

- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 15, 2003 3:01 PM
Subject: #21659 [Com]: sprintf


> ID:   21659
>  Comment by:   [EMAIL PROTECTED]
>  Reported By:  [EMAIL PROTECTED]
>  Status:   Bogus
>  Bug Type: *General Issues
>  Operating System: linux
>  PHP Version:  4.3.0
>  New Comment:
> 
> Why has this bug been marked as Bogus when it's a Duplicate?  It seems
> to be increasingly common for this to happen -- when did it become
> standard policy to set duplicate report to Bogus? This is very
> confusing, when there is still a Duplicate status in the system. 
> Surely, if a bug is a duplicate of another, it's far better to set its
> status to Duplicate, so that it's obvious from a brief look that it
> *is* a duplicate (and it shows up in search results as such).  Setting
> it to Bogus is bogus, because it's patently not Bogus if it's the same
> issue as an Open bug.
> 
> And even if it is policy to set duplicate report to Bogus, that policy
> should be prominently documented, so that people don't get in a huff
> about bugs being dismissed as not a bug when their duplicate report is
> set to Bogus (which has happened more than once already!).
> 
> Cheers!
> 
> Mike
> 
> 
> Previous Comments:
> 
> 
> [2003-01-15 08:13:43] [EMAIL PROTECTED]
> 
> See bug #21658, it's the same so this one is not needed -> bogus.
> 
> 
> 
> [2003-01-15 08:10:55] [EMAIL PROTECTED]
> 
> Error with sprintf i obtain conversion from numbner in not printable
> caracter.
> various numebr of my application don't work now
> 
> see above
> 
> 
> 
> [2003-01-15 08:09:57] [EMAIL PROTECTED]
> 
> Please do not submit the same bug more than once. An existing
> bug report already describes this very problem. Even if you feel
> that your issue is somewhat different, the resolution is likely
> to be the same. Because of this, we hope you add your comments
> to the existing bug instead.
> 
> Thank you for your interest in PHP.
> 
> 
> 
> [2003-01-15 08:08:41] [EMAIL PROTECTED]
> 
> I obtain from php 4.30 and error using sprintf
> 
> My  php code generate
> a result file in which is it possible to see the bug:
> 
> 
> example:
> 
> 
> 
> sprintf(%.3f,2.04204204204) = 0.0�0
> sprintf(%.3f,2.1981981982) = 000.000
> sprintf(%.3f,1.07507507508) = 1.000
> sprintf(%.3f,1.98498498498) = 0.000
> sprintf(%.3f,0.318318318318) = 0.000
> sprintf(%.3f,0.90990990991) = 1.000
> sprintf(%.3f,0.660660660661) = 0.000
> sprintf(%.3f,2.27327327327) = 00.000
> 
> 
> sprintf generate strange non visible alfanumeric caracter 
> 
> 
> 
> 
> 
> 
> -- 
> Edit this bug report at http://bugs.php.net/?id=21659&edit=1
> 
> 

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

Re: [PHP-DEV] CGI and CLI (compromise proposal)

[Adam Maccabee Trachtenberg]

I'm 95% that PEAR works with cgi, but we should check with Stig to
make sure it doesn't assume that cli will always be installed. Since
pear and cli were both going live with 4.3 they may be coupled.

-adam

On Thu, 19 Dec 2002, Andrei Zmievski wrote:

> This gets my complete support. Let's go ahead with the changes.
> 
> On Thu, 19 Dec 2002, Edin Kadribasic wrote:
> > After having consulted with Andrei, Derick and others on irc here is
> > a proposal for a compromise:
> > 
> > On Unix:
> > 
> > 1. Both cgi and cli are built as 'php' in their respective sapi
> > directories (pretty much as it is today except that cgi gets renamed
> > back from php-cgi to just php).
> > 2. Make install will *not* install cli if cgi build was selected
> > (only cgi gets installed).
> > 3. A new install target 'install-cli' is introduced so that make
> > install-cli will overwrite whatever is in $(PREFIX)/bin/php.
> > 
> > On Windows:
> > 
> > 1. php.exe in the root of distribution is php cgi sapi.
> > 2. New cli directory is included with php.exe (cli) in it.
> > 
> > If this is an acceptable compromise I volunteer to do the changes
> > required.
> 
> -Andrei   http://www.gravitonic.com/
> * The great thing about standards is that there are so many to choose from. *
> 
> 

-- 
[EMAIL PROTECTED]
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!


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

Re: [PHP-DEV] month part

[Adam Voigt]

A. This is a list for the development OF php, not IN php.

B.:



$split = explode("/","06/07/2000");

$month = $split[0];



On Thu, 2002-12-19 at 09:04, Diana Castillo wrote:

How can I get a string containing the month part of a date the user types

in?

e.g. if they type in "06/07/200" I want to get "06"

Thanks,

Diana













-- 

PHP Development Mailing List 

To unsubscribe, visit: http://www.php.net/unsub.php






-- 
Adam Voigt ([EMAIL PROTECTED])
The Cryptocomm Group
My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc








signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] encryption functions

[Adam Voigt]

It would be a welcome addition but wouldn't this create legal

problems with the U.S. export laws in-reference to high powered

encryption technology/software?



On Wed, 2002-12-18 at 11:11, Derick Rethans wrote:

On 18 Dec 2002, Adam Voigt wrote:



> Check out the Mcrypt manual page:

> 

> http://us2.php.net/mcrypt

> 

> In the comments several people posted links to DLL (windows) version's

> of

> the MCRYPT library.



The main problems with the library where the dynamic loading of the 

ciphers. In mcrypt version 2.5.4 this is finally addressed (released 

yesterday). I'll see if I can compile the library so that we finally can 

add this extension to our windows distributions.



Derick



-- 



-

 Derick Rethans http://derickrethans.nl/ 

 PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/

-






-- 
Adam Voigt ([EMAIL PROTECTED])
The Cryptocomm Group
My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc








signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] encryption functions

[Adam Voigt]

Check out the Mcrypt manual page:



http://us2.php.net/mcrypt



In the comments several people posted links to DLL (windows) version's of

the MCRYPT library.



On Wed, 2002-12-18 at 10:40, Michael Bretterklieber wrote:

Hi,



I'm trying to provide samples for authenticating using MS-CHAP and my 

Radius PECL.



I need DES for generating the data., but it seems that des is only 

available via mcrypt-extension, but mcrypt only compiles under unix or 

am i wrong?



Its nearly useless to provide a sample for MS-CHAP only for unix, 

because MS-CHAP is often used with Windoze.



What should I do? I can add DES to my radius-PECL, but isn't it better 

to have an extension wich provides basic encryption functions for 

windows AND unix?



any suggestions?



bye,

-- 

--- --

Michael Bretterklieber- [EMAIL PROTECTED]   

JAWA Management Software GmbH - http://www.jawa.at

Liebenauer Hauptstr. 200-- privat 

A-8041 GRAZ GSM: ++43-(0)676-93 96 698   

Tel: ++43-(0)316-403274-12  E-mail:   [EMAIL PROTECTED]

Fax: ++43-(0)316-403274-10  http://www.bretterklieber.com

--- --

"...the number of UNIX installations has grown to 10, with more 

expected..." - Dennis Ritchie and Ken Thompson, June 1972







-- 

PHP Development Mailing List 

To unsubscribe, visit: http://www.php.net/unsub.php
    





-- 
Adam Voigt ([EMAIL PROTECTED])
The Cryptocomm Group
My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc








signature.asc
Description: This is a digitally signed message part

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/gd gd.c php_gd.h

[Adam Maccabee Trachtenberg]

This patch, or at least this part:

-#ifdef HAVE_GD_XPM
+#if defined(HAVE_GD_XPM) && defined(HAVE_GD_BUNDLED)

Needs to be merged into the 4.3.0. Something in the build broke my GD
support between RC2 and RC3. This fixes it.

-adam

On Wed, 11 Dec 2002, Ilia Alshanetsky wrote:

> iliaa Wed Dec 11 17:25:24 2002 EDT
> 
>   Modified files:  
> /php4/ext/gd  gd.c php_gd.h 
>   Log:
>   Fixed build with non-bundled GD. Hidden the anti-alias functions when 
>   non-bundled GD is used and made imagecreatefromxpm() unavailable because 
>   of a bug in the external GD library.
>   
>   
> Index: php4/ext/gd/gd.c
> diff -u php4/ext/gd/gd.c:1.238 php4/ext/gd/gd.c:1.239
> --- php4/ext/gd/gd.c:1.238Wed Dec 11 15:44:44 2002
> +++ php4/ext/gd/gd.c  Wed Dec 11 17:25:22 2002
> @@ -18,7 +18,7 @@
> +--+
>   */
>  
> -/* $Id: gd.c,v 1.238 2002/12/11 20:44:44 pajoye Exp $ */
> +/* $Id: gd.c,v 1.239 2002/12/11 22:25:22 iliaa Exp $ */
>  
>  /* gd 1.2 is copyright 1994, 1995, Quest Protein Database Center, 
> Cold Spring Harbor Labs. */
> @@ -224,7 +224,7 @@
>  #ifdef HAVE_GD_XBM
>   PHP_FE(imagecreatefromxbm,  NULL)
>  #endif
> -#ifdef HAVE_GD_XPM
> +#if defined(HAVE_GD_XPM) && defined(HAVE_GD_BUNDLED)
>   PHP_FE(imagecreatefromxpm,  NULL)
>  #endif
>   PHP_FE(imagecreatefromgd,   NULL)
> @@ -1441,7 +1441,7 @@
>   case PHP_GDIMG_TYPE_GD2PART:
>   im = (*func_p)(fp, Z_LVAL_PP(srcx), Z_LVAL_PP(srcy), 
>Z_LVAL_PP(width), Z_LVAL_PP(height));
>   break;
> -#ifdef HAVE_GD_XPM
> +#if defined(HAVE_GD_XPM) && defined(HAVE_GD_BUNDLED)
>   case PHP_GDIMG_TYPE_XPM:
>   im = gdImageCreateFromXpm(fn);
>   break;
> @@ -1508,7 +1508,7 @@
>  /* }}} */
>  #endif /* HAVE_GD_XBM */
>  
> -#ifdef HAVE_GD_XPM
> +#if defined(HAVE_GD_XPM) && defined(HAVE_GD_BUNDLED)
>  /* {{{ proto int imagecreatefromxpm(string filename)
> Create a new image from XPM file or URL */
>  PHP_FUNCTION(imagecreatefromxpm)
> @@ -2130,7 +2130,6 @@
>  {
>   zval **IM, **x1, **y1, **x2, **y2, **col;
>   gdImagePtr im;
> - int antialias=0;
>  
>   if (ZEND_NUM_ARGS() != 6 || zend_get_parameters_ex(6, &IM, &x1, &y1, &x2, &y2, 
>&col) == FAILURE) {
>   ZEND_WRONG_PARAM_COUNT();
> @@ -2145,14 +2144,11 @@
>   convert_to_long_ex(col);
>  
>  #ifdef HAVE_GD_BUNDLED
> - antialias = im->antialias;
> -#endif
> - if (antialias) {
> + if (im->antialias)
>   gdImageAALine(im, Z_LVAL_PP(x1), Z_LVAL_PP(y1), Z_LVAL_PP(x2), 
>Z_LVAL_PP(y2), Z_LVAL_PP(col));
> - } else {
> + else 
> +#endif   
>   gdImageLine(im, Z_LVAL_PP(x1), Z_LVAL_PP(y1), Z_LVAL_PP(x2), 
>Z_LVAL_PP(y2), Z_LVAL_PP(col));
> - }
> -  
>   
>   gdImageLine(im, Z_LVAL_PP(x1), Z_LVAL_PP(y1), Z_LVAL_PP(x2), Z_LVAL_PP(y2), 
>Z_LVAL_PP(col));
>   RETURN_TRUE;
> @@ -4074,7 +4070,7 @@
>   }
>  }
>  /* }}} */
> -#endif
> +/* End section: Filters */
>  
>  /* {{{ proto imagesetantialias(int im, bool on)
>  Should antialiased functions used or not*/
> @@ -4092,8 +4088,7 @@
>   RETURN_TRUE;
>  }
>  /* }}} */
> -
>
> -/* End section: Filters */
> +#endif
>  
>  /*
>   * Local variables:
> Index: php4/ext/gd/php_gd.h
> diff -u php4/ext/gd/php_gd.h:1.48 php4/ext/gd/php_gd.h:1.49
> --- php4/ext/gd/php_gd.h:1.48 Wed Dec 11 15:45:47 2002
> +++ php4/ext/gd/php_gd.h  Wed Dec 11 17:25:23 2002
> @@ -17,7 +17,7 @@
> +--+
>  */
>  
> -/* $Id: php_gd.h,v 1.48 2002/12/11 20:45:47 pajoye Exp $ */
> +/* $Id: php_gd.h,v 1.49 2002/12/11 22:25:23 iliaa Exp $ */
>  
>  #ifndef PHP_GD_H
>  #define PHP_GD_H
> @@ -112,12 +112,14 @@
>  PHP_FUNCTION(imagecreatefromgif);
>  PHP_FUNCTION(imagecreatefromjpeg);
>  PHP_FUNCTION(imagecreatefromxbm);
> -PHP_FUNCTION(imagecreatefromxpm);
>  PHP_FUNCTION(imagecreatefrompng);
>  PHP_FUNCTION(imagecreatefromwbmp);
>  PHP_FUNCTION(imagecreatefromgd);
>  PHP_FUNCTION(imagecreatefromgd2);
>  PHP_FUNCTION(imagecreatefromgd2part);
> +#if defined(HAVE_GD_XPM) && defined(HAVE_GD_BUNDLED)
> +PHP_FUNCTION(imagecreatefromxpm);
> +#endif
>  
>  PHP_FUNCTION(imagegammacorrect);
>  PHP_FUNCTION(imagedestroy);
> 
> 
> 
> 


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

[PHP-DEV] Bug or Not?

[Adam Voigt]

I have some data that can't contain certain character's, so I have

something akin to the following:



function getProper($string)

{

	$string = strip_tags($string);

	$string = str_replace("][","][",$string);

	$string = str_replace("'","'",$string);

	$string = str_replace("\"",""",$string);



	return($string);

}



Now, I have page which submit's to page2.php, on page2.php I have a

foreach loop on the $_POST array, for each iteration it prints the hidden

input in HTML, but before that it passes each value through the above function.

Now, when I view source everything is as expected, I see "'" instead of

a single quote and everything, when I hit submit, and am now on page3.php,

I do: print_r($_POST) and all the values have been re-interpreted into there

original values (so instead of ', I see a single quote (in view-source to)) and

my DB queriy is failing because of this, I can get around this by moving my replace

step to the page with the DB query, but I was wondering is this a bug or expected

behavior? Maybe it's just me, but if PHP is doing this, I wouldn't think it should be

interpreting the values you pass back and forth at all, just pass them.



Thanks.





-- 
Adam Voigt ([EMAIL PROTECTED])
The Cryptocomm Group
My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc








signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] Weird PHP Problem

[Adam Voigt]

Yep, NVARCHAR's get pissy at large sizes (in my experience anyway) when
PHP is interacting with them, (or any of the "N" variables for that
matter) change it to a TEXT and see what happens.

On Wed, 2002-11-27 at 06:20, Becky Gruebmeyer wrote:
> Ok...Using newest version of PHP on an NT IIS machine with a SQL 2000
> database. Here is the issue:
> 
> I have a nvarchar field with a size of 4000.
> I submit a text string from a form to this field.
> It will display on submit using echo nl2br($variable) and it will display
> fine.
> When I look in the database, it has all the information stored correctly.
> When I pull it back out of the database, it cuts it off and only displays
> the first part of the string.
> 
> Anyone have any ideas why?
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Adam Voigt ([EMAIL PROTECTED])
The Cryptocomm Group
My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc



signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] GD 2.0.6 make errors

[Adam Voigt]

Wrong list, try php-general or php-install, php-dev is for
discussion about the development of PHP not development in PHP.

On Thu, 2002-11-14 at 11:51, Clay wrote:
> Gcc 3.2
> Solaris 9
> 
> 2.0.1 works fine.  Any ideas?  Anyone compile 2.0.6 yet on any platform?
> 
> In file included from gd.c:83:
> gd_ctx.c: In function `_php_image_output_ctx':
> gd_ctx.c:70: structure has no member named `free'
> gd_ctx.c:98: structure has no member named `free'
> gd.c: In function `_php_image_type':
> gd.c:1014: structure has no member named `free'
> gd.c:1017: structure has no member named `free'
> gd.c: In function `_php_image_create_from':
> gd.c:1209: structure has no member named `free'
> make[3]: *** [gd.lo] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all-recursive] Error 1
> 
> Any ideas
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
-- 
Adam Voigt ([EMAIL PROTECTED])
The Cryptocomm Group
My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc



signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] MySQL UDF that runs PHP

[Adam Voigt]

I'm very intrigued, this looks pretty cool. I don't suppose there's
anyway you could link in the connectivity to the MySQL engine so you
didn't have to have the same connection overhead as external mysql
connections from standard PHP pages? Cause that would just be sweet.

Adam Voigt
[EMAIL PROTECTED]

On Tue, 2002-11-05 at 16:37, David Sklar wrote:
> Based on Edin Kadribasic's PHP "embed" SAPI module, I wrote a MySQL UDF that
> interprets PHP. You can get it here:
> 
> --> http://www.sklar.com/myphp-0.1.tar.gz
> 
> I'd be curious for any comments or suggestions folks have.
> 
> Thanks,
> 
> David Sklar
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



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

[PHP-DEV] Core Component

[Adam Voigt]

Just curious, someone asked me why isn't PEAR (specifically the DB
abstraction) directly written into the PHP engine (in C or whatever PHP
itself is written in) and I couldn't come up with an answer so I thought
I'd ask here.

Adam Voigt
[EMAIL PROTECTED]


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

[PHP-DEV] Problem w/ upgrade to 4.2.3

[Adam]

Just installed 4.2.3 from 4.2.2.  Now when I have a PHP script that takes
some time to process it will wait to send any of the HTML to the client.

On 4.2.2 I could just include the PHP code after the HTML that I wanted to
display, it would display the HTML before the PHP and when the PHP had
finished it would display the rest of the HTML.

Now it just waits for the PHP to finish to display ANY of the HTML on the
page.

What gives?  Does anyone know if this is the proper behavior?  Or is it
proper now and was broken before?  And I just happened to take advantage of
it.

Any input would be helpful.

Thanks,

Adam



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

[PHP-DEV] Configure Error's

[Adam Voigt]

Ok, under 4.2.3 or 4.0.3pre2, when running the configure line:

./configure --prefix=/usr/local/php_4.2.3 --without-mysql
--disable-session --disable-pcre-regex --disable-xml

Everything seems to go fine, till the end where it says:

creating ./config.status
creating php4.spec
sed: file conftest.s1 line 4: Unterminated `s' command
creating Zend/Makefile
sed: file conftest.s1 line 4: Unterminated `s' command
creating main/build-defs.h
sed: file conftest.s1 line 4: Unterminated `s' command
creating pear/scripts/pear
sed: file conftest.s1 line 4: Unterminated `s' command
creating pear/scripts/phpize
sed: file conftest.s1 line 4: Unterminated `s' command
creating pear/scripts/php-config
sed: file conftest.s1 line 4: Unterminated `s' command
creating pear/scripts/pearize
sed: file conftest.s1 line 4: Unterminated `s' command
creating pear/scripts/phptar
sed: file conftest.s1 line 4: Unterminated `s' command
creating TSRM/Makefile
sed: file conftest.s1 line 4: Unterminated `s' command
creating main/php_config.h
fastgen.sh: creating sapi/Makefile

Now, here's where the versions differ, with 4.3.0pre2, I can
still type "make" and it appears to be compiling ok, but when I
do "make" after those error's on 4.2.3, I get:

Making all in Zend
make[1]: Entering directory `/usr/local/php/php-4.2.3/Zend'
make[1]: *** No rule to make target `all'.  Stop.
make[1]: Leaving directory `/usr/local/php/php-4.2.3/Zend'

Any idea's?

Adam Voigt
[EMAIL PROTECTED]


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

Re: [PHP-DEV] [PATCH] ereg to pcre conversion

[Adam Maccabee Trachtenberg]

So you're planning on converting POSIX regexen to PCRE so people don't
need to worry about PCRE metacharacters that are POSIX literals? Seems
tricky. (e.g. is "\w" a backslash and a w or a "word" character? what
about search patterns of 10 instead of "10" they have different
meanings in egrep(), you'll need to convert this, too.)

-adam

On Thu, 31 Oct 2002, Ilia A. wrote:

> Currently PHP ships with two regular expression libraries that are both 
> installed by default, PCRE & regex. The regex library that is responsible for 
> ereg_* functions is fairly old and offers a very limited functionality 
> compared to the PCRE library. In most cases the PCRE functions are also much 
> faster then the old ereg functions.
> I would like to propose that we drop the old ereg library and use only
> a single regular expression library, PCRE. For BC purposes I've written a 
> patch (see attached file), which emulates the old ereg_* functions for people 
> who still rely on those, using PCRE.
> 
> This cleanup would mean we'd only need to maintain one set of regular 
> expression code, which as far as code goes is pretty complex as well as give 
> speed-up for people still using ereg. 
> Perhaps, at some future point this would allow us to drop the ereg_* functions 
> all together.
> 
> Ilia


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

Re: [PHP-DEV] Console Behavior

[Adam Voigt]

Figured it out, turns out I had actually bothered to copy the php.ini
from the recommended on the server it didn't work on, if I removed the
config file (forcing PHP to use the default options), it worked fine,
I narrowed the problem down to the output_buffering setting, changing
it from 4096 (probably designed for website hit performance) to 0 made
it work (with or without the call to flush()).

Now my only question is, shouldn't flush() force the buffer to be
sent out despite the config setting?

Adam Voigt
[EMAIL PROTECTED]

On Thu, 2002-10-31 at 10:30, Rasmus Lerdorf wrote:
> Running your code here gives me:
> 
> 8:27am thinkpad:~> ./foo
> 
> 
> Attach code? > 12345
> 
> 
> 12345
> 
> 
> 8:27am thinkpad:~>
> 
> Seems to work fine.
> 
> -Rasmus



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

Re: [PHP-DEV] Console Behavior

[Adam Voigt]

You are correct, I tried it on an identical system and it worked.
But it still refuses to work on my other system. They both
run RH8 with PHP 4.2.3, the only difference (that I can see)
is that I'm connecting to the box it doesn't work on through SSH,
I don't have a third box from which to test this theory handy
but it might have something to do with OpenSSH's buffering of
data or something, hmmm.

Anyway, thanks for helping me out, I would have
been banging my head against the wall all day had
I not discovered this discrepancy.

Adam Voigt
[EMAIL PROTECTED]

On Thu, 2002-10-31 at 10:30, Rasmus Lerdorf wrote:
> Running your code here gives me:
> 
> 8:27am thinkpad:~> ./foo
> 
> 
> Attach code? > 12345
> 
> 
> 12345
> 
> 
> 8:27am thinkpad:~>
> 
> Seems to work fine.
> 
> -Rasmus
> 
> On 31 Oct 2002, Adam Voigt wrote:
> 
> > Now I have this, same behavior as before, maybe I'm using the flush
> > function incorrectly but the manual seems to suggest this
> > is the way to use it:
> >
> > #!/usr/local/php_4.2.3/bin/php -q
> >  >
> > error_reporting(E_ALL);
> >
> > echo "\n\nAttach code? > ";
> >
> > flush();
> >
> > $f = fopen("php://stdin","r");
> > $data = fread($f,5);
> > fclose($f);
> >
> > echo "\n\n$data\n\n";
> >
> > ?>
> >
> > On Thu, 2002-10-31 at 10:21, Rasmus Lerdorf wrote:
> > > flush()
> > >
> >
> 



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

Re: [PHP-DEV] Console Behavior

[Adam Voigt]

Now I have this, same behavior as before, maybe I'm using the flush
function incorrectly but the manual seems to suggest this
is the way to use it:

#!/usr/local/php_4.2.3/bin/php -q
 ";

flush();

$f = fopen("php://stdin","r");
$data = fread($f,5);
fclose($f);

echo "\n\n$data\n\n";

?>

On Thu, 2002-10-31 at 10:21, Rasmus Lerdorf wrote:
> flush()
> 


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

[PHP-DEV] Console Behavior

[Adam Voigt]

Is this normal?
I have:

#!/usr/local/php_4.2.3/bin/php -q
 ";

$f = fopen("php://stdin","r");
$data = fread($f,5);
fclose($f);

echo "\n\n$data\n\n";

?>

And it refuses to echo "Attach code?" until after
I hit 5 keys on the console and hit enter, when infact
it is supposed to be a prompt for the 5 keys (ie,
display before you enter the keys) Is this expected?
If yes, any workaround?.

Adam Voigt
[EMAIL PROTECTED]




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

[PHP-DEV] Perl-Like Pre-Destined Array Designation

[Adam Voigt]

Ok, the other day a friend of mine showed me where you
could address a position in an array in perl, before you
even had the array returned. Essentially it would be
this in php:

echo explode(",",$somearray)[0];

Which would give you the first position of what was returned
from the explode function without having to set it to a variable.
I know PHP doesn't support this, but my question is, are you
going to add it? I just ask because I have seen several cases
were I would have liked that ability but wasn't able to.

Adam Voigt
[EMAIL PROTECTED]

P.S. Thanks for PHP by the way, I hesitate to think about programming
without it.


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

Re: [PHP-DEV] Thread Reading

[Adam Voigt]

Newbie's or people seeking help with bad security
standards, could give away the password to there SQL server, etc.
Maybe the phps parser or whatever it's called should automatically ***
out the password fields of all the db, ftp, etc. calls.

Adam Voigt
[EMAIL PROTECTED]

On Thu, 2002-09-19 at 13:05, Zeev Suraski wrote:
> At 12:27 19/09/2002, Yasuo Ohgaki wrote:
> >Dan Hardiker wrote:
> >>We are dealing with *idiots* here. Their CODE doesnt work, they are
> >>*learning* PHP, they want help on their *non-functional* code, easily,
> >>simply and quickly.
> >>We can already say "put this in a .php file then give us the URL to it"
> >>and cut n paste them a short script which will show_source their script.
> >>However this is TOO MUCH for most newbies and people I encounter daily in
> >>#php on dal.net - now if I asked them for a URL to their script, they give
> >>me http://whatever.com/script.php so I can see the error in action - I
> >>tell them "ok, rename it to phps". Voila - I get the source.
> >>THIS is where phps is SO useful.
> >
> >I'm not insisting we should remove phps, but discourage use of it :)
> 
> Can you explain why?
> 
> Zeev
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



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

[PHP-DEV] URL Rewriting Possible Bug

[Adam Voigt]

I'm not sure if this is something that can easily be
repaired or what not, but myself and another programmer
ran in to a problem converting some legacy software to
PHP (from an antiquated language called iHTML). We are
using id based sessions throughout the site, and on one
page we have PHP outputing we have a URL which says:

doc.write(" http://help.internetstore.com/"; +
foldersNode[4] + "')> "+foldersNode[3]+"")

And after the Session URL Rewriter gets through with it, we get:

doc.write(" http://help.internetstore.com/"; +
foldersNode[4] + "')> "+foldersNode[3]+"")

And that one throws Javascript errors. We know we can turn off
URL Rewrite on that one page or the entire site, or the entire
server, are possibly even use cookies, but it would be nice if it
would not attempt to parse it, since it does so incorrectly.

Any ideas?

Adam Voigt
[EMAIL PROTECTED]


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

Re: [PHP-DEV] 4.2.3

[Adam Maccabee Trachtenberg]

On Thu, 22 Aug 2002, Zeev Suraski wrote:

> I'll pack 4.2.3RC1 tomorrow morning, so if anybody has any last minute bug 
> fixes to put in, now's the time!

Shuffle fix didn't make it:

http://bugs.php.net/bug.php?id=18401

-adam

-- 
adam maccabee trachtenberg
[EMAIL PROTECTED]


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

RE: [PHP-DEV] PHP 4.3 and PHP 5

[Adam Maccabee Trachtenberg]

I am willing to accept this. I don't think it's the job of the PHP
group to fix thread-safetyness for all libraries on all
platforms. That's a herculean task. Plus, I'm sure we're not alone in
problem. Surely the mod_perl folks and [insert your favorite popular
Apache module here] have similar issues.

If we could say that PHP works on a certain subset of systems (my
proposal is that we limit ourselves to the current release versions of
popular OSes) with a certain set of extensions (again, I propose
everything that is enabled by default, if possible. I'm not sure how
large that set of extensions is) then that would be "good."

If that seems as if it would involve too many hours of QA (which it
certainly could), I think the list you're currently making listing
what does and doesn't work w/r/t threading is an acceptible
substitute. That way, even if we can't fix it, we can at least tell
you that your library is broken and switching to [insert thread-safe
substitute] will solve the problem.

If people choose not to switch, that's their problem, but we've at
least given them the information to make a decision before they tear
their hair out wondering why PHP keeps crashing.

-adam


On Wed, 21 Aug 2002, Rasmus Lerdorf wrote:

> But how do you propose we come up with perfect Apache 2.0 support? If we
> limit it to the pre-fork mpm, we can probably get quite close to perfect
> stability, but for any of the threaded mpms we are completely at the mercy
> of the threadsafetyness of all the various third party libraries on all
> the various platforms that PHP runs on. There is simply no way to ensure
> that PHP against Apache 2.0 with a threaded mpm will be production
> quality. The best we can do is pick a small set of extensions and a small
> set of platforms and say that with the limited set of extensions, against
> a specific set of versions of addon libraries on a specific version of
> that OS, yes, it should be production quality - maybe.
> 
> -Rasmus
> 
> On Wed, 21 Aug 2002, Adam Maccabee Trachtenberg wrote:
> 
> > On Wed, 21 Aug 2002, Zeev Suraski wrote:
> >
> > > I think that at this point we should switch from wish-list mode, to
> > > a down-to-earth realistic mode.  That is, not put everything that we
> > > want to see in the roadmap, but only things which are either
> > > pre-requisites or things we know with a great deal of certainty.
> >
> > I don't know what the timing of PHP 5 will be vis-a-vis Apache 2.0
> > stabilization, but it'd be real nice if we could have a "production
> > quality" Apache 2.0 module.
> >
> > I know there's been a lot of work on the module and I rememeber
> > reading that what it mostly needs now is burn-in and testing. (Maybe
> > there is some additional functionality or optimizations we also wish
> > to enable?)
> >
> > So, it could be that everything is perfect by 4.3, but I think it
> > would be "good," if we could tell everyone that 5.0 "works" with
> > Apache 2.0.
> >
> > That could be a nice sized carrot, for those looking for vegetables to
> > support a vegan lifestyle. :)
> >
> > -adam
> >
> > --
> > adam maccabee trachtenberg
> > [EMAIL PROTECTED]
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> 

-- 
adam maccabee trachtenberg
[EMAIL PROTECTED]


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

RE: [PHP-DEV] PHP 4.3 and PHP 5

[Adam Maccabee Trachtenberg]

On Wed, 21 Aug 2002, Zeev Suraski wrote:

> I think that at this point we should switch from wish-list mode, to
> a down-to-earth realistic mode.  That is, not put everything that we
> want to see in the roadmap, but only things which are either
> pre-requisites or things we know with a great deal of certainty.

I don't know what the timing of PHP 5 will be vis-a-vis Apache 2.0
stabilization, but it'd be real nice if we could have a "production
quality" Apache 2.0 module.

I know there's been a lot of work on the module and I rememeber
reading that what it mostly needs now is burn-in and testing. (Maybe
there is some additional functionality or optimizations we also wish
to enable?)

So, it could be that everything is perfect by 4.3, but I think it
would be "good," if we could tell everyone that 5.0 "works" with
Apache 2.0.

That could be a nice sized carrot, for those looking for vegetables to
support a vegan lifestyle. :)

-adam

-- 
adam maccabee trachtenberg
[EMAIL PROTECTED]


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

[PHP-DEV] Sort doesn't reindex all arrays (Bug #12572)

[Adam Maccabee Trachtenberg]

I want to propose the following patch to Zend to fix a minor
inconsistency. The sort() functions reindex arrays of length > 1, but
not of length == 1.

See http://bugs.php.net/bug.php?id=12572 for an example.

The patch is:

Index: zend_hash.c
===
RCS file: /repository/Zend/zend_hash.c,v
retrieving revision 1.86
diff -u -u -r1.86 zend_hash.c
--- zend_hash.c 1 Aug 2002 16:03:21 -   1.86
+++ zend_hash.c 17 Aug 2002 06:38:14 -
@@ -1115,7 +1115,7 @@
 
IS_CONSISTENT(ht);
 
-   if (ht->nNumOfElements <= 1) {  /* Doesn't require sorting */
+   if (ht->nNumOfElements < 1) {   /* Doesn't require sorting */
return SUCCESS;
}
arTmp = (Bucket **) pemalloc(ht->nNumOfElements * sizeof(Bucket *), 
ht->persistent);

If this seems good, can someone with Zend permission please apply?

Thanks.

-adam

-- 
adam maccabee trachtenberg
[EMAIL PROTECTED]


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

Re: [PHP-DEV] Re: #18401 [Opn->Ana]: shuffle() broken (fwd)

[Adam Maccabee Trachtenberg]

On Fri, 16 Aug 2002, Tim Converse wrote:

> --- Yasuo Ohgaki <[EMAIL PROTECTED]> wrote:
> If you don't believe me, take your algorithm and run it
> many times, tracking how often element i in the input moves
> to become element j in the output, and print the resulting
> counts out as an n-by-n table.  You'll see a bias towards
> elements moving one position back in the array.

Yasuo --

Look at the following code. The php_shuffle() function is the
algorithm currently in the CVS; yasuo_shuffle() is what you're
proposing.

The test() function is a simple script to call each *_shuffle()
function 100,000 times on a three-element array, record the
permutations, and print out a record of the results. You'll see that
php_shuffle() evenly divides the elements, while yours does not:

 $v) {
print "$k: $v: " . sprintf('%0.3f', $v / $times) . "%\n";
  }

}

test('php_shuffle');
test('yasuo_shuffle');
?>

This is what I get repeatedly:

php_shuffle
123: 16707: 0.167%
132: 16641: 0.166%
213: 16569: 0.166%
231: 16751: 0.168%
312: 16532: 0.165%
321: 16800: 0.168%

yasuo_shuffle
123: 14755: 0.148%
132: 18427: 0.184%
213: 18554: 0.186%
231: 18566: 0.186%
312: 14790: 0.148%
321: 14908: 0.149%

-adam

-- 
adam maccabee trachtenberg
[EMAIL PROTECTED]


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /main main.c php.h php_globals.h

[Adam Maccabee Trachtenberg]

On Sat, 10 Aug 2002, Marcus Börger wrote:

> +This can be done automaticall with the use of php_error_docref. Where the
> +docref parameter is either NULL or a manual reference describing the
> +error in detail. This must be an external url started by "http://"; or
> +the name of a manual page without the  file extension but with an optional
> +target anchor. In case of NULL the reference is generated from the
> +function being executed:
> +
> +php_error_docref("function.name#error" TSRMLS_CC, E_WHATEVER, "Desc.");
> +
> +You may use php_error_docref1/2 to display the executed functionname
> +followed by one or two important parameters. For example file base
> +functions should display the name of the file opened:
> +
> +php_error_docref1("function.fopen", filename TSRMLS_CC, E_WHATEVER, 
> "Desc.");
> +php_error_docref2("function.copy", file_source, file_dest, param2 
> TSRMLS_CC, E_WHATEVER, "Desc.");

Marcus --

Looks good. Here is a suggested revision. I think it makes things a
little clearer to people who aren't familiar with the error handling
functions.

This can be done automatically using php_error_docref(). The first
parameter, docref, is either NULL or URL of a page in the PHP manual
describing the error in detail.

If you pass NULL, the reference is generated from the name of the
function being executed:

php_error_docref("function.name#error" TSRMLS_CC, E_WHATEVER, "Desc.");

If you pass a URL, it can either be a full URL beginning with
"http://":

php_error_docref("http://www.php.net/manual/en/function.name#error.php"; 
  TSRMLS_CC, E_WHATEVER, "Desc.");

Or the name of a manual page without the file extension, but with an
optional target anchor:

php_error_docref("function.name#error" TSRMLS_CC, E_WHATEVER, "Desc.");

To display the one or two important parameters after the function
name, use php_error_docref1() or php_error_docref2(). For example,
file functions should display the name of the file opened:

php_error_docref1("function.fopen", filename
   TSRMLS_CC, EWHATEVER, "Desc.");

php_error_docref2("function.fopen", file_source, file_destination 
   TSRMLS_CC, EWHATEVER, "Desc.");

-adam

-- 
adam maccabee trachtenberg
[EMAIL PROTECTED]



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

[PHP-DEV] IPv6 support - status.

[Adam Go³êbiowski]

As far as I googled up, PHP currently supports IPv6 in ftp_*() functions, 
fopen() and gethostbyaddr(). Is that all? I'm curious about socket 
functions, as I would like to write a small application that uses IPv6. And 
I would like it to use socket_*() not fsockopen(). As I tested in php4.1.2, 
it lacks support for IPNG - I used AF_INET6 instead of AF_INET and 
getprotobyname('tcp6') instead of getprotobyname('tcp') in socket_create() 
and got errors that AF_INET6 constant is not defined. Has anything changed 
in recent versions?

-- 
http://www.mysza.eu.org/

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

Re: [PHP-DEV] Mac 8.6 Web Server with PHP

[Adam Maccabee Trachtenberg]

On Thu, 30 Aug 1956, J Abbott wrote:

> anyone know of a mac 8.6 compatible web server with PHP capibility?

http://www.tenon.com/products/webten/

It costs $495, however. I don't know of any free versions of PHP for
MacOS < X.

-adam

-- 
adam maccabee trachtenberg
[EMAIL PROTECTED]


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

Re: [PHP-DEV] Fw: [ANNOUNCE] PHP Security Advisory: Vulnerabilityin PHP versions 4.2.0 and4.2.1

[Adam Voigt]

This isn't a hacking board, if you want to break the law, learn how to
do it somewhere else.

Adam Voigt
[EMAIL PROTECTED]

On Tue, 2002-07-23 at 10:49, Anil Garg wrote:
> Hi,
> 
> I am not an expert in php but i would like to know how is the vulnerability
> exploited.
> 
> hope to get the right directions
> regards
> anil
> 
> >PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1
> >
> >
> > Issued on: July 22, 2002
> > Software:  PHP versions 4.2.0 and 4.2.1
> > Platforms: All
> >
> >
> >The PHP Group has learned of a serious security vulnerability in PHP
> >versions 4.2.0 and 4.2.1. An intruder may be able to execute arbitrary
> >code with the privileges of the web server. This vulnerability may be
> >exploited to compromise the web server and, under certain conditions,
> >to gain privileged access.
> >
> >
> > Description
> >
> >PHP contains code for intelligently parsing the headers of HTTP POST
> >requests. The code is used to differentiate between variables and files
> >sent by the user agent in a "multipart/form-data" request. This parser
> >has insufficient input checking, leading to the vulnerability.
> >
> >The vulnerability is exploitable by anyone who can send HTTP POST
> >requests to an affected web server. Both local and remote users, even
> >from behind firewalls, may be able to gain privileged access.
> >
> >
> > Impact
> >
> >Both local and remote users may exploit this vulnerability to
> compromise
> >the web server and, under certain conditions, to gain privileged
> access.
> >So far only the IA32 platform has been verified to be safe from the
> >execution of arbitrary code. The vulnerability can still be used on
> IA32
> >to crash PHP and, in most cases, the web server.
> >
> >
> > Solution
> >
> >The PHP Group has released a new PHP version, 4.2.2, which incorporates
> >a fix for the vulnerability. All users of affected PHP versions are
> >encouraged to upgrade to this latest version. The downloads web site at
> >
> >   http://www.php.net/downloads.php
> >
> >has the new 4.2.2 source tarballs, Windows binaries and source patches
> >from 4.2.0 and 4.2.1 available for download.
> >
> >
> > Workaround
> >
> >If the PHP applications on an affected web server do not rely on HTTP
> >POST input from user agents, it is often possible to deny POST requests
> >on the web server.
> >
> >In the Apache web server, for example, this is possible with the
> >following code included in the main configuration file or a top-level
> >.htaccess file:
> >
> >   
> >   Order deny,allow
> >   Deny from all
> >   
> >
> >Note that an existing configuration and/or .htaccess file may have
> >parameters contradicting the example given above.
> >
> >
> > Credits
> >
> >The PHP Group would like to thank Stefan Esser of e-matters GmbH for
> >discovering this vulnerability.
> >
> >
> > Copyright (c) 2002 The PHP Group.
> >
> >
> >
> > --
> > PHP Announcements Mailing List (http://www.php.net/)
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



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

Re: [PHP-DEV] www.php.net site not responding

[Adam Voigt]

Thats why I always use a mirror.

Try: http://us2.php.net/

Adam Voigt
[EMAIL PROTECTED]

On Mon, 2002-07-22 at 11:02, Monte Ohrt wrote:
> I see, it also took down smarty.php.net with it :( I suppose there is 
> only one physical server at our disposal?
> 
> Monte
> 
> 
> [EMAIL PROTECTED] wrote:
> > Hi,
> > 
> > it's full with downloads taking place... apache is not that suited for 
> > this. :(
> > 
> > Derick
> > 
> > On Mon, 22 Jul 2002, Monte Ohrt wrote:
> > 
> > 
> >>The site has not responded for at least 20 mins, although it is 
> >>pingable. I'm not sure who should get this message.
> >>
> >>Monte
> >>
> >>
> >>-- 
> >>PHP Development Mailing List <http://www.php.net/>
> >>To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> > 
> > 
> > ---
> >  Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
> >  Frequent ranting: http://www.derickrethans.nl/
> > ---
> >  PHP: Scripting the Web - [EMAIL PROTECTED]
> > All your branches are belong to me!
> > SRM: Script Running Machine - www.vl-srm.net
> > ---
> > 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



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

Re: [PHP-DEV] possible dos attack

[Adam Voigt]

What version of Apache and PHP are you running?
Are you connecting to a Microsoft SQL server or a Sybase Server (I ask
because of the reference to php_sybase_db, and since both would most
likely make reference to that.) Is there a pattern to the crashing?
(Heavy database activity?) If you are using FreeTDS to connect to a
Microsoft SQL Server what version are you running?

Adam Voigt
[EMAIL PROTECTED]

On Mon, 2002-07-15 at 13:17, Dan Stromberg wrote:
> We have a bunch of apache servers here with php compiled in.
> 
> They keep dying.  I think they're all tending to die at the same time.
> The servers on ports 8080 and 443 are fine; it's only the port 80 apaches
> that are dying.
> 
> I did a backtrace with gdb, and I get thousands of these:
> 
> #60961 0xef7d46e8 in ?? ()
> #60962 0xef7dfcc8 in ?? ()
> #60963 0xef7d2d8c in ?? ()
> #60964 0xef24c980 in _PROCEDURE_LINKAGE_TABLE_ () from /usr/lib/libthread.so.1
> #60965 0xef239308 in kill () from /usr/lib/libthread.so.1
> #60966 0x1516dc in sig_coredump ()
> #60967 0xef23b928 in __sighndlr () from /usr/lib/libthread.so.1
> #60968 
> #60969 dbexit () at dblib.c:561
> #60970 0xbb7a8 in zm_shutdown_sybase (type=-282964972, 
> module_number=-277216068) at php_sybase_db.c:254
> 
> It seems to me that either there's a weird recursive bug apache with php,
> or someone has found a DOS attack against apache with php by pelting it
> with a bad signal.
> 
> Any suggestions?  Restarting our apaches is quickly getting old.  It's
> been so easy to take apaches reliability for granted.
> 
> TIA.
> 
> BTW, thanks for the work you guys do on apache/php.
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 



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

Re: [PHP-DEV] PHP, Java integration failed: Red Hat 7.1, JDK 1.4,Apache 1.3x

[Adam Maccabee Trachtenberg]

William --

I've also spend a considerable amount of time trying to get this to
work on Redhat 7.2 (and maybe 7.1). I did a lot of coaxing and
reconfigurations.

Best I can say, it doesn't work with JDK 1.4. Once I tried 1.3.x,
everything went fine.

My guess is that something changed in the upgrade, but I don't have
time to figure out what.

-adam

On Thu, 20 Jun 2002, William John Burns wrote:

> All:
> 
> None of the many online user posts in setting up Java connectivity from 
> within PHP have worked. RPM or tarball.
> 
> Do you know of anyone who has an RPM of PHP, with the standard MySQL, 
> GD, Postgres, WDDX, etc...but also libphp_java.so correctly set-up?
> 
> The Windows PHP has Java support right off the bat with an edit the the 
> .ini file. On Win 98, no problems at all. But on my Linux paritions...
> 
> There are at least dozens of people trying to get this to work. All of 
> them could be helped with an RPM or a definitive answer. Why can't 
> someone release linux binaries with this sort of thing compiled in?
> 
> My system: Sun Java2 JDK 1.4.0, Red Hat 7.1, Apache 1.3x. I have tried 
> all versions of PHP tarballs since 4.04p1 And I'm not alone in this 
> frustration.
> 
> Yes, sometimes there is a libphp_java. There is always the .jar file. 
> But after editing the .ini, doing all manner of things with 
> LD_LIBRARY_PATH/ldconfig, nothing!
> 
> The best I ever got was a page that registered the .so module, but never 
> finished output. (I use a test page with phpinfo(), then and a sample 
> call to get a Java timestamp. In this circumstance, the page cuts off 
> before the sample Java timestamp and instance.
> 
> Any help or leads would be appreciated.
> 
> Regards,
> 
> WJ Burns
> 
> 
> 
> 


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

Re: [PHP-DEV] Re: Xdebug extension availability

[Adam Wright]

Very interesting! Possibly stupid question - Will it co-exist happily with
other Zend extensions (ala the Optimiser/Decoder)?

Thanks

adamw

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Yasuo Ohgaki" <[EMAIL PROTECTED]>
Cc: "PHP Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, May 01, 2002 3:59 PM
Subject: Re: [PHP-DEV] Re: Xdebug extension availability


> On Wed, 1 May 2002, Yasuo Ohgaki wrote:
>
> > I saw
> >
> > /* The contents of this file are subject to the Vulcan Logic Public
> >   * License Version 1.1 (the "License"); you may not use this file
> >   * except in compliance with the License. You may obtain a copy of
> >   * the License at http://www.vl-srm.net/vlpl/
> >
> > in srm_llist.[ch]
> >
> > I don't read the license statement, so I cannot tell if there
> > will be a problem or not.
>
> Ah ok, it's BSD style, modelled after the PHP one. So that won't be a
> problem.
>
> Derick
>
> ---
>  Did I help you? Consider a gift:
>   http://www.amazon.co.uk/exec/obidos/registry/SLCB276UZU8B
> ---
>   PHP: Scripting the Web - [EMAIL PROTECTED]
> All your branches are belong to me!
> SRM: Script Running Machine - www.vl-srm.net
> ---
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

Re: [PHP-DEV] PATCH - improvements for imap_headerinfo()

[Adam Kauffman]

These changes don't (although I realize you shouldn't just take my word
for it) break the functionality of imap_headerinfo().  It just is a
streamlined way of doing it.

The function as it stands does a mail_fetchheader_full(), takes the
result of that, and turns it into an envelope object.  Afterwards, it
has to free that object.  The c-client provides a way to get just the
envelope with mail_fetchenvelope().  It is beneficial to use this for a
few reasons:

1. As you can see it makes the code much simpler
2. It is faster.  For each message you don't have to fetch full headers
and turn them into an envelope object.  You can simply just get the
envelope object.
3. Simpler for the IMAP server.  Instead of making it do a BODY.PEEK, it
just has to fetch the envelope (which some IMAP servers cache).

Adam

On Wed, 2002-04-24 at 14:33, Jani Taskinen wrote:
> 
> What was this patch supposed to do again?
> At first glance it looks like it's modifying the 
> imap_headerinfo() function quite dramatically and 
> propably breaks it too..
> 
> Have you compared the output of this function without
> this patch and with it and does it return the same kind
> of object? (and send patches as attachements..)
> 
> --Jani


Index: php_imap.c
===
RCS file: /repository/php4/ext/imap/php_imap.c,v
retrieving revision 1.113
diff -u -r1.113 php_imap.c
--- php_imap.c	24 Apr 2002 15:29:52 -	1.113
+++ php_imap.c	24 Apr 2002 19:06:04 -
@@ -1567,10 +1567,9 @@
 {
 	zval **streamind, **msgno, **fromlength, **subjectlength, **defaulthost;
 	pils *imap_le_struct;
-	unsigned long length;
 	MESSAGECACHE *cache;
 	ENVELOPE *en;
-	char *mystring, dummy[2000], fulladdress[MAILTMPLEN];
+	char dummy[2000], fulladdress[MAILTMPLEN];
 	int myargc = ZEND_NUM_ARGS();
 	
 	if (myargc < 2 || myargc > 5 || zend_get_parameters_ex(myargc, &streamind, &msgno, &fromlength, &subjectlength, &defaulthost) == FAILURE) {
@@ -1605,13 +1604,8 @@
 		RETURN_FALSE;
 	}
 	
-	mystring = mail_fetchheader_full(imap_le_struct->imap_stream, Z_LVAL_PP(msgno), NIL, &length, NIL);
-	if (myargc == 5) {
-		rfc822_parse_msg(&en, NULL, mystring, length, NULL, Z_STRVAL_PP(defaulthost), NIL);
-	} else {
-		rfc822_parse_msg(&en, NULL, mystring, length, NULL, "UNKNOWN", NIL);
-	}
-	
+	en = mail_fetchenvelope(imap_le_struct->imap_stream, Z_LVAL_PP(msgno));
+
 	/* call a function to parse all the text, so that we can use the
 	   same function to parse text from other sources */
 	_php_make_header_object(return_value, en TSRMLS_CC);
@@ -1646,7 +1640,6 @@
 		mail_fetchsubject(fulladdress, imap_le_struct->imap_stream, Z_LVAL_PP(msgno), Z_LVAL_PP(subjectlength));
 		add_property_string(return_value, "fetchsubject", fulladdress, 1);
 	}
-	mail_free_envelope(&en);
 }
 /* }}} */
 



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

Re: [PHP-DEV] PATCH - improvements for imap_headerinfo()

[Adam Kauffman]

On Tue, 2002-04-23 at 18:23, Jani Taskinen wrote:
> 
> Please make a unified diff against the CVS HEAD (cvs diff -u).
> 
> --Jani

Index: php_imap.c
===
RCS file: /repository/php4/ext/imap/php_imap.c,v
retrieving revision 1.113
diff -u -r1.113 php_imap.c
--- php_imap.c  24 Apr 2002 15:29:52 -  1.113
+++ php_imap.c  24 Apr 2002 18:00:45 -
@@ -1567,10 +1567,9 @@
 {
zval **streamind, **msgno, **fromlength, **subjectlength,
**defaulthost;pils *imap_le_struct;
-   unsigned long length;
MESSAGECACHE *cache;
ENVELOPE *en;
-   char *mystring, dummy[2000], fulladdress[MAILTMPLEN];
+   char dummy[2000], fulladdress[MAILTMPLEN];
int myargc = ZEND_NUM_ARGS();

if (myargc < 2 || myargc > 5 || zend_get_parameters_ex(myargc,
&streamind, &msgno, &fromlength, &subjectlength, &defaulthost) ==
FAILURE) {
@@ -1605,16 +1604,7 @@
RETURN_FALSE;
}

-   mystring = mail_fetchheader_full(imap_le_struct->imap_stream,
Z_LVAL_PP(msgno), NIL, &length, NIL);
-   if (myargc == 5) {
-   rfc822_parse_msg(&en, NULL, mystring, length, NULL,
Z_STRVAL_PP(defaulthost), NIL);
-   } else {
-   rfc822_parse_msg(&en, NULL, mystring, length, NULL,
"UNKNOWN", NIL);
-   }
-
-   /* call a function to parse all the text, so that we can use the
-  same function to parse text from other sources */
-   _php_make_header_object(return_value, en TSRMLS_CC);
+   en = mail_fetchenvelope(imap_le_struct->imap_stream,
Z_LVAL_PP(msgno));

/* now run through properties that are only going to be returned
   from a server, not text headers */
@@ -1646,7 +1636,6 @@
mail_fetchsubject(fulladdress,
imap_le_struct->imap_stream, Z_LVAL_PP(msgno),
Z_LVAL_PP(subjectlength));
add_property_string(return_value, "fetchsubject",
fulladdress, 1);
}
-   mail_free_envelope(&en);
 }
 /* }}} */
 



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

RE: [PHP-DEV] sections in httpd.conf?

[adam]

> There are no plans for this.  I looked at it for Apache 1.3 and there is
> no clean way to do it.  Yes, I know mod_perl can do it, but it is a very
> very ugly hack.  It may be easier and cleaner to do it for Apache 2.0.
> Haven't looked at that yet.
>
Thanks Rasmus. If there's no clean way to do it, PHP is probably better off
without it right now. I hope you'll have at it again some time when you have
a moment.

Also thanks to Adam for his post on mod_vhost_alias. I'm aware of the module
Adam, but it's not as flexible as PerlSections, which can be used to
configure almost any aspect of the Apache server. This is particularly
useful when dealing with hosting "plans" or even custom-configured hosting
solutions. The client's VirtualHost config can be pulled from a relational
database, which can of course be linked to the client themselves, and
billing, etc.

An intriguing concept that follows on from this is the storage of client
configurations on a central database server. This would be very useful for a
medium-large web hosting facility that wishes to offer custom configurations
instead of plain ol' plans. Security would naturally be a concern, but if
communications between machines were secured correctly, it should be quite
interesting to play with on a machine running freeVSD.

adam


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

Re: [PHP-DEV] sections in httpd.conf?

[Adam Voigt]

I think your talking about being able to create virtual hosts with PHP on
the fly, I can't be sure though as I have been lucky enough not have had
to use perl =). But if that is what you would like to do, I would suggest just
using mod_vhost_alias in Apache (http://httpd.apache.org/docs/mod/mod_vhost_alias.html)
which allows you to just create a directory of like "whatever.com" under whatever
web path you specify, and poof, that domain is setup. It's a lot safer to have
Apache do such things then PHP or even Perl, messing with the Apache config
file.

Adam Voigt
[EMAIL PROTECTED]

On Tue, 9 Apr 2002 12:19:15 +0100, adam <[EMAIL PROTECTED]> wrote:
> Hi there,
> 
> [Please copy replies off-list.]
> 
> Are there any plans to introduce on-the-fly Apache configuration in PHP,
> similar to mod_perl's PerlSections? As an administrator of a Cobalt RaQ
> server (sorry), I discovered PerlSections a couple of years ago; and have
> experimented with, for example, generating VirtualHosts from client records
> in a MySQL database. I would love to be able to do this in PHP.
> 
> Apologies if the topic has been covered before, I did a search but only
> turned up stuff slightly related.
> 
> Cheers,
> adam beecher
> 
> 
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

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

[PHP-DEV] sections in httpd.conf?

[adam]

Hi there,

[Please copy replies off-list.]

Are there any plans to introduce on-the-fly Apache configuration in PHP,
similar to mod_perl's PerlSections? As an administrator of a Cobalt RaQ
server (sorry), I discovered PerlSections a couple of years ago; and have
experimented with, for example, generating VirtualHosts from client records
in a MySQL database. I would love to be able to do this in PHP.

Apologies if the topic has been covered before, I did a search but only
turned up stuff slightly related.

Cheers,
adam beecher


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

[PHP-DEV] Error Handling

[Adam Voigt]

At our web hosting facillity we have several developers (each who recieve a seperate
email when an error occurs on the site there working on) and we would like to have 
extra
data included in the log files which are written (such as the $_POST, $_GET, $_ENV, and
$_SERVER arrays), this would help us to figure out more precisely why exactly an error
occured for a particular user. I already looked at the error_append entry which allows 
you
to append code to an error message but it appears that does not carry over to the log 
file,
is there anyway to make all these arrays dump into the error log after each error 
entry (I
know there is probably a way to do it with some combination of OR and 
die(customError()) or
something, but it would be nice if the built in error handling could do it.).

Thanks,

Adam Voigt
[EMAIL PROTECTED]

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

Re: [PHP-DEV] configure broken: Iconv detection still not right...

[Adam Maccabee Trachtenberg]

It happens with me w/ latest CVS.

autoconf 2.13, automake 1.4p5, libtool 1.4.

-adam


On Wed, 20 Mar 2002, Jani Taskinen wrote:

> 
> And this happens with latest CVS?
> Which autoconf/automake/etc versions you have?
> 
> --Jani
> 
> 
> 
> On Wed, 20 Mar 2002, Wez Furlong wrote:
> 
> >Hey guys,
> >
> >There's something screwy with the iconv detection/config that's
> >mangling configure - it's generating code like this:
> >
> >Line 28183 or so of configure:
> >
> > case $iconv_lib_name in
> >c|c_r|pthread*
> >   fi
> >;;
> >*)
> >
> >   LIBS="-l$iconv_lib_name $LIBS"
> >
> >;;
> >    esac
> >
> >The "fi" looks totally bogus to me, and it looks like there is
> >a missing ) after pthread* 
> >
> >--Wez.
> >
> >
> >
> >
> >
> >
> 
> 

-- 
adam maccabee trachtenberg
[EMAIL PROTECTED]


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

[PHP-DEV] CVS Account Request: adamf1

[Adam Fedder]

primary for translate documentation to Polish language

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/msession msession.c

[Adam Dickmeiss]

On Sun, Feb 10, 2002 at 12:20:55PM +0100, Sebastian Bergmann wrote:
> "Stig S. Bakken" wrote:
> > Well, shouldn't Mark, who maintains the code in question, be the one to
> > decide whether a couple of extra ifdefs makes his code unmaintainable?
> 
>   Well, needs msession a ''prime time seat'' in /php4/ext/, or wouldn't
>   we all be better off putting it into /pear/?

I certainly are one of those that don't like ifdefs. It's a bad sign
and it's difficult to test - read - the code. Having said that, msession
have few ifdefs compared to many other modules. We could throw
mysql and gd away  - they have more ifdefs! (pear is not a garbage can.
If it is treated as such, nobody will move).

What is interesting is that GD tops. I love GD but is one of the
nastiest modules to ./configure.

Actually a few ifdefs that reflect the changes in Zend is not that bad (what
is bad is the change of the interface). At least the #ifdefs force programmers' to
watch out! Furthermore, code that do have ifdefs is easier to move to pear.
As for the documentation it's the same story. If an interface changes over
time AND that is reflected in the code (because of ifdefs) they know that
this interface have changed between PHP versions.

For code that is going to stay within ext I think we should *allow* for
ifdefs that make the code work with at least the previous stable
version. The obvious good reason is testing. For example if somebody
breaks apache apxs (which did happen), it's good that I can test code
with the previous releasee to be able to continue coding on the module.

-- Adam

> 
> -- 
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
> 
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/msession msession.c

[Adam Dickmeiss]

On Mon, Feb 04, 2002 at 06:12:24PM -0500, [EMAIL PROTECTED] wrote:
> >> If you want to maintain compatibility to 4.0.6, do it someplace
> >> else. Anything in PHP cvs should be compatible with the latest CVS.
> >> Or move your extension elsewhere.
> 
> I appreciate your position, but the source checked in *IS* compatible with
> the latest version of PHP and uses the latest APIs. The only difference is
> that rather than delete backward compatibility, #ifdef constructs are used
> to choose.
> 
> We have been down this road before. There is a reasonable expectation that
> extensions may differ subtly from extension to extension. I see no need to
> fork my source for 4.0.x and 4.1.x compatibility when it is simple enough to
> do with macros and maintain one source file.

+1 for that statement.

-- Adam


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

Re: [PHP-DEV] Bug #12748 Updated: changing allow_url_fopen from"off" to "on" crashes fopen()

[Adam Maccabee Trachtenberg]

On 4 Feb 2002 [EMAIL PROTECTED] wrote:

>  ID:   12748
>  Updated by:   [EMAIL PROTECTED]
> -Summary:  changing allow_url_fopen from "off" to "on" crashes
>fopen()
>  Reported By:  [EMAIL PROTECTED]

The "Summary" diff doesn't appear to be working correctly.

-adam

-- 
adam maccabee trachtenberg
[EMAIL PROTECTED]


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

[PHP-DEV] Closing bugs 14452, 14602, 14616, 14824

[Adam Dickmeiss]

The bugs 14452, 14602, 14616, 14824 all seem to be the same.
Maybe it's a libtool bug - maybe not. What I do know, however, is
that if the Zend intermediate library built only add libs that
Zend need, the bug doesn't occur. The fix below introduces define
ZEND_EXTRA_LIBS that are the libs used by Zend (usually very few).

I don't have karma to apply the fix. And if I had, I'd ask people
anyway.

-- Adam Dickmeiss

Index: Makefile.in
===
RCS file: /repository/php4/Makefile.in,v
retrieving revision 1.105
diff -u -r1.105 Makefile.in
--- Makefile.in 24 Jan 2002 12:55:08 -  1.105
+++ Makefile.in 1 Feb 2002 22:13:19 -
@@ -14,7 +14,7 @@
$(TSRM_LIB)
 
 LTLIBRARY_LDFLAGS = -rpath $(phptempdir) $(EXTRA_LDFLAGS) $(LDFLAGS) $(PHP_RPATHS)
-LTLIBRARY_LIBADD = $(LTLIBRARY_DEPENDENCIES) $(EXTRA_LIBS)
+LTLIBRARY_LIBADD = $(LTLIBRARY_DEPENDENCIES) $(EXTRA_LIBS) $(ZEND_EXTRA_LIBS)
 
 PROGRAM_NAME = php
 PROGRAM_SOURCES  = stub.c
Index: configure.in
===
RCS file: /repository/php4/configure.in,v
retrieving revision 1.296
diff -u -r1.296 configure.in
--- configure.in30 Jan 2002 23:46:44 -  1.296
+++ configure.in1 Feb 2002 22:13:19 -
@@ -825,6 +825,8 @@
 
 PHP_REGEX
 
+EXTRA_LIBS="$EXTRA_LIBS $DLIBS $LIBS"
+unset LIBS LDFLAGS
 
 dnl Configuring Zend and TSRM.
 dnl -
@@ -849,7 +851,7 @@
   INCLUDES="$INCLUDES -I\$(top_srcdir)/TSRM"
 fi
 
-EXTRA_LIBS="$EXTRA_LIBS $DLIBS $LIBS"
+ZEND_EXTRA_LIBS="$LIBS"
 unset LIBS LDFLAGS
 
 PHP_CONFIGURE_PART(Configuring TSRM)
@@ -1001,6 +1003,7 @@
 PHP_SUBST_OLD(EXTENSION_DIR)
 PHP_SUBST(EXTRA_LDFLAGS)
 PHP_SUBST_OLD(EXTRA_LIBS)
+PHP_SUBST_OLD(ZEND_EXTRA_LIBS)
 PHP_SUBST(INCLUDES)
 PHP_SUBST_OLD(INCLUDE_PATH)
 PHP_SUBST_OLD(INSTALL_IT)
Index: Zend/Makefile.am
===
RCS file: /repository/Zend/Makefile.am,v
retrieving revision 1.43
diff -u -r1.43 Makefile.am
--- Zend/Makefile.am2001/09/19 08:26:11 1.43
+++ Zend/Makefile.am2002/02/01 22:16:37
@@ -15,7 +15,8 @@
zend_list.c zend_indent.c zend_builtin_functions.c zend_sprintf.c \
zend_ini.c zend_qsort.c
 
-libZend_la_LDFLAGS = @EXTRA_LIBS@
+libZend_la_LDFLAGS = 
+libZend_la_LIBADD = @ZEND_EXTRA_LIBS@
 
 # automake isn't too clever about "non-standard" use of lex and yacc
 
Index: Zend/configure.in
===
RCS file: /repository/Zend/configure.in,v
retrieving revision 1.31
diff -u -r1.31 configure.in
--- Zend/configure.in   2000/12/02 13:26:41 1.31
+++ Zend/configure.in   2002/02/01 22:16:38
@@ -35,9 +35,9 @@
 LIBZEND_ENABLE_DEBUG
 LIBZEND_OTHER_CHECKS
 
-EXTRA_LIBS="$LIBS"
+ZEND_EXTRA_LIBS="$LIBS"
 LIBS=""
-AC_SUBST(EXTRA_LIBS)
+AC_SUBST(ZEND_EXTRA_LIBS)
 AC_OUTPUT(Makefile)
 
 # Local Variables:

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

[PHP-DEV] CVS Account Request: rambik

[Adam Rambousek]

Translation of PHP-GTK manual to czech

-- 
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] Moving extensions to PECL

[Adam Dickmeiss]

On Tue, Jan 01, 2002 at 07:55:33PM +0100, Egon Schmid wrote:
> From: "Martin Jansen" <[EMAIL PROTECTED]>
> 
> > On Tue, 1 Jan 2002 18:36:57 +0100, Egon Schmid wrote:
> >
> > >Well, I know librians will love the YAZ extension. I suggest to
> move
> > >the documentation in a new part in the PHP Manual. I think of a
> > >split of the original Function Reference in something like Basic
> > >Function Reference and Extended Function Reference.
> >
> > If yaz is going to become part of PECL (= part of PEAR),
> documentation
> > should be placed in the PEAR manual. Everything else is less
> intuitive
> > and will irritate people IMO.
> 
> Are you sure that librians find the PEAR documentation? As I can see
> PEAR and PHP documentation differs in many things. I think Adam
> would be glad if he can maintain the YAZ functions as before.

They probably won't find the PEAR documentation currently. I guess
it wouldn't take that much to change the structure of the PHP web
site a little, to make it more visible.

-- Adam

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

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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: PHP 5

[Adam Dickmeiss]

On Tue, Jan 01, 2002 at 05:56:53PM -, Jim Winstead wrote:
> Andi Gutmans <[EMAIL PROTECTED]> wrote:
> > The Zend Engine 2 has made lots of progress.
> 
> is there an up-to-date summary of the changes beyond the original ze2
> proposal? example scripts that show the new features?
> 
> > Unrelated, I'm still waiting to hear exactly what mechanism the PEAR guys 
> > implemented for PECL. I know that if it's not a really cool easy to use 
> > mechanism I would prefer to wait until we write one. One of the main 
> > strengths of PHP is that everything is bundled together and is easy to 
> > setup. We shouldn't make it much harder on people. Although we're planning 
> > on only move the unimportant extensions out of PHP I still think it should 
> > be extremely easy to get a list of available extensions (maybe even a part 
> > of the ./configure process) and to easily download/configure/install them.
> 
> having everything bundled is a strength for people who install from
> source, but it really doesn't do much to help people who haved installed
> from a distribution or are in a shared-hosting situation. those are the
> places where something like perl's cpan really shines (and where the
> pear/pecl stuff presumably will too).

I think a lot of people are installing from source, so it's very
important that's easy to do so. Distributios are outdated and as
long as you wan't "just" one new feature of the extensions you're
bound to install from source anyway.

> i'd really love to see the existing pear/pecl stuff brought out into the
> open more, even if it is not fully baked. i think the fact that it is
> relatively hidden makes it extremely difficult for people to know where
> things are headed, how close (or far) they are, and how to help.

The main benefit of the PECL is the independent release-cycle. It'll
force less people to install PHP from source when they need stuff from
a newly updated extension.

> (and 'unimportant' is a dangerous word. obviously that depends on the
> situation.)

IMHO, all extensions should be PECL. If it's easier to have some
extensions part of core PHP 'cause they're important, then it's a
sign of bad PECL design. PHP should be the glue for SAPI,
extensions (PECL, I hope) and Zend. No more.

-- Adam

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

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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] Moving extensions to PECL

[Adam Dickmeiss]

On Mon, Dec 31, 2001 at 01:38:48PM -0500, Jon Parise wrote:
> I think the following "standard" extensions should be moved to
> PECL:
> 
> ext/cybercash
> ext/icap
> ext/pfpro
> ext/yaz
> 
> This is definitely not an inclusive list; it's just a start.  I
> can't imagine a lot of people using these modules, so they seem
> like good candidates for removal from the base PHP distribution.
> 
> Are there any well-founded objections to this (either in practice
> or principle)?

I'll be happy to move yaz away. I hope that moved away extensions
will not be "invisible" in the future. We use yaz and a lot of our
users in the Libraries world are too.

If this means that the documentation for YAZ which I wrote will no
longer be translated to other languages we can live with that.

The good thing about the move is that extensions will have an
independant release-cycle so that they don't have to wait for
official PHP releases, etc.

Note, that as extensions move away from the core, it'll be not
be obvious when there are Zend API changes unless we're informed.
(so far, people have patched yaz for Zend API changes, thank you).

So what's the procedure? Creating pear/XML/yaz and move stuff
to that directory? Moving documentation? How?

-- Adam

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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] Need karma to close bugs 14602, 14616

[Adam Dickmeiss]

I need karma to remove @EXTRA_LIBS@ from Zend/Makefile.am in the
defintion of libZend_la_LDFLAGS to solve bugs #14602 and #14616.
Zend people please respond this.

CVS account: dickmeiss

Happy new year,
  Adam

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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 #14616: Linking PHP with external static Libtool libraries fails.

[adam]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.1.0
PHP Bug Type: Compile Failure
Bug description:   Linking PHP with external static Libtool libraries fails.

This bug exists when PHP is linked with external
static Libtool library and PHP itself is shared.

Compile external support library as static. YAZ in this
example:
 cd yaz-1.8.3
 ./configure --prefix=/usr
 make 
 make install

 cd ../php-4.1.0:
 ./configure --with-apxs=... --with-yaz

and you'd get an output like this:

..
/bin/sh ../libtool --silent --mode=link gcc  -g -O2 -prefer-pic  -o
libZend.la  -ldl -lyaz -lcrypt -lresolv -lm -ldl -lnsl  -lresolv
-lcrypt  zend_language_parser.lo zend_language_scanner.lo
zend_ini_parser.lo zend_ini_scanner.lo zend_alloc.lo zend_compile.lo
zend_c
onstants.lo zend_dynamic_array.lo zend_execute.lo zend_execute_API.lo
zend_highlight.lo zend_llist.lo zend_opcode.lo zend_operators.l
o zend_ptr_stack.lo zend_stack.lo zend_variables.lo zend.lo zend_API.lo
zend_extensions.lo zend_hash.lo zend_list.lo zend_indent.lo z
end_builtin_functions.lo zend_sprintf.lo zend_ini.lo
make[1]: Leaving directory `/home/adam/proj/php-4.1.0/Zend'
...
/bin/sh /home/adam/proj/php-4.1.0/libtool --silent --mode=link gcc  -I.
-I/home/adam/proj/php-4.1.0/ -I/home/adam/proj/php-4.1.0/main
 -I/home/adam/proj/php-4.1.0 -I/home/adam/proj/apache/include
-I/home/adam/proj/php-4.1.0/Zend -I/home/adam/proj/php-4.1.0/ext/mysql/
libmysql -I/home/adam/proj/php-4.1.0/ext/xml/expat  -DLINUX=22
-DUSE_HSREGEX -DUSE_EXPAT -I/home/adam/proj/php-4.1.0/TSRM -g -O2 -pre
fer-pic   -o libphp4.la -rpath /home/adam/proj/php-4.1.0/libs
-avoid-version   stub.lo  Zend/libZend.la sapi/apache/libsapi.la main/l
ibmain.la regex/libregex.la ext/mysql/libmysql.la ext/pcre/libpcre.la
ext/posix/libposix.la ext/session/libsession.la ext/standard/li
bstandard.la ext/xml/libxml.la ext/yaz/libyaz.la TSRM/libtsrm.la -ldl -lyaz
-lcrypt -lresolv -lm -ldl -lnsl -lresolv -lcrypt
/usr/lib/libyaz.a(odr_bool.o): In function `odr_bool':
/home/adam/proj/yaz/odr/odr_bool.c(.text+0x0): multiple definition of
`odr_bool'
Zend/.libs/libZend.al(odr_bool.o)(.text+0x0):/home/adam/proj/yaz/odr/odr_bool.c:
first defined here
/usr/lib/libyaz.a(ber_bool.o): In function `ber_boolean':
[many more multiple symbols]

The log indicates that all YAZ symbols are included twice.
Apparenly the Zend link step includes YAZ verbatim even
though no symbols should be needed to built that.

Fixes:

1) removing /usr/lib/libyaz.la makes it work. Now the
   Zend link step doesn't include YAZ and it works.

2) removing the linkage of yaz from the Zend link step
   obviously makes it work too (and fixes the problem
   for all libraries).

3) build shared YAZ library is a fix too.
   (./configure --enabled-shared for YAZ).

The problem doesn't occur with PHP 4.0.6. It is a problem
with latest CVS (16 Dec 2001).

This problem persists for other libraries than YAZ.
Andrew Sitnikov reports he had trouble with linking of
'-lmm -lmhash' (had to remove them from Zend/Makefile).

If this is a libtool bug and there's no fix for that, my
suggestion would be that Zend doesn't link with
YAZ or other extension libraries. That is the value of
libZend_la_LDFLAGS in Zend/Makefile.am 
should not include @EXTRA_LIBS@.


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

[Adam Dickmeiss]

I'd like to ask the motivation for adding EXTRA_LIBS in the
setting of libZend_la_LIBS in Zend/Makefile.am.

libZend.la is a convenience library. It's always linked to a an
executable or shared object, later. EXTRA_LIBS includes all external
support libraries that have no relevance to Zend. The setting breaks
shared PHP build when (e.g. APXS) and external libraries are Libtool
static.

libZend_la_LIBS has had this for a long time. It wasn't a problem with
PHP 4.0.6, but it is with PHP 4.1.0 and latest CVS that uses a newer
version of Libtool.

I've reported this issue earlier on the list and have had no reply.
Please prove me wrong on this!

Cheers,
  Adam

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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] Linking PHP with static Libtool libraries

[Adam Dickmeiss]

This patch makes Zend includes its "own" set of libraries, so
that external support libs used by PHP extensions are linked once
when building PHP lib. I simply define ZEND_LIBS. I cannot tell what
impact this would otherwise have. I'm not that familiar with the PHP code.
I guess, AC_SUBST(ZEND_LIBS) has to be used in PHP's configure.in as well.

Index: Makefile.am
===
RCS file: /repository/Zend/Makefile.am,v
retrieving revision 1.43
diff -u -r1.43 Makefile.am
--- Makefile.am 2001/09/19 08:26:11 1.43
+++ Makefile.am 2001/12/16 02:15:47
@@ -15,7 +15,7 @@
zend_list.c zend_indent.c zend_builtin_functions.c zend_sprintf.c \
zend_ini.c zend_qsort.c
 
-libZend_la_LDFLAGS = @EXTRA_LIBS@
+libZend_la_LDFLAGS = @ZEND_LIBS@
 
 # automake isn't too clever about "non-standard" use of lex and yacc
 
Index: configure.in
===
RCS file: /repository/Zend/configure.in,v
retrieving revision 1.31
diff -u -r1.31 configure.in
--- configure.in2000/12/02 13:26:41 1.31
+++ configure.in2001/12/16 02:15:47
@@ -35,9 +35,9 @@
 LIBZEND_ENABLE_DEBUG
 LIBZEND_OTHER_CHECKS
 
-EXTRA_LIBS="$LIBS"
+ZEND_LIBS="$LIBS"
 LIBS=""
-AC_SUBST(EXTRA_LIBS)
+AC_SUBST(ZEND_LIBS)
 AC_OUTPUT(Makefile)
 
 # Local Variables:

---

--
  Adam

not On Fri, Dec 14, 2001 at 07:44:28PM +0200, Jani Taskinen wrote:
> 
> Does this happen with latest CVS?
> 
> --Jani
> 
> 
> On Fri, 14 Dec 2001, Adam Dickmeiss wrote:
> 
> >I have the following problem. On UNIX, PHP fails to link with
> >a static library generated by Libtool. Problem occurs with PHP 4.1.0
> >but not PHP 4.0.6. The YAZ extension, for example, which I maintain
> >generates by default a static Libtool library only. So After doing
> >   cd yaz-1.8.3
> >   ./configure --prefix=/usr
> >   make
> >   make install
> >
> >two files are created, namely /usr/lib/libyaz.a and /lib/lib/libyaz.la.
> >
> >For PHP I do :
> >   ./configure --with-yaz [other options]
> >
> >and get the folloing make output:
> >..
> >/bin/sh ../libtool --silent --mode=link gcc  -g -O2 -prefer-pic  -o libZend.la  
>-ldl -lyaz -lcrypt -lresolv -lm -ldl -lnsl  -lresolv
> >-lcrypt  zend_language_parser.lo zend_language_scanner.lo zend_ini_parser.lo 
>zend_ini_scanner.lo zend_alloc.lo zend_compile.lo zend_c
> >onstants.lo zend_dynamic_array.lo zend_execute.lo zend_execute_API.lo 
>zend_highlight.lo zend_llist.lo zend_opcode.lo zend_operators.l
> >o zend_ptr_stack.lo zend_stack.lo zend_variables.lo zend.lo zend_API.lo 
>zend_extensions.lo zend_hash.lo zend_list.lo zend_indent.lo z
> >end_builtin_functions.lo zend_sprintf.lo zend_ini.lo
> >make[1]: Leaving directory `/home/adam/proj/php-4.1.0/Zend'
> >...
> >/bin/sh /home/adam/proj/php-4.1.0/libtool --silent --mode=link gcc  -I. 
>-I/home/adam/proj/php-4.1.0/ -I/home/adam/proj/php-4.1.0/main
> > -I/home/adam/proj/php-4.1.0 -I/home/adam/proj/apache/include 
>-I/home/adam/proj/php-4.1.0/Zend -I/home/adam/proj/php-4.1.0/ext/mysql/
> >libmysql -I/home/adam/proj/php-4.1.0/ext/xml/expat  -DLINUX=22 -DUSE_HSREGEX 
>-DUSE_EXPAT -I/home/adam/proj/php-4.1.0/TSRM -g -O2 -pre
> >fer-pic   -o libphp4.la -rpath /home/adam/proj/php-4.1.0/libs -avoid-version   
>stub.lo  Zend/libZend.la sapi/apache/libsapi.la main/l
> >ibmain.la regex/libregex.la ext/mysql/libmysql.la ext/pcre/libpcre.la 
>ext/posix/libposix.la ext/session/libsession.la ext/standard/li
> >bstandard.la ext/xml/libxml.la ext/yaz/libyaz.la TSRM/libtsrm.la -ldl -lyaz -lcrypt 
>-lresolv -lm -ldl -lnsl -lresolv -lcrypt
> >/usr/lib/libyaz.a(odr_bool.o): In function `odr_bool':
> >/home/adam/proj/yaz/odr/odr_bool.c(.text+0x0): multiple definition of `odr_bool'
> >Zend/.libs/libZend.al(odr_bool.o)(.text+0x0):/home/adam/proj/yaz/odr/odr_bool.c: 
>first defined here
> >/usr/lib/libyaz.a(ber_bool.o): In function `ber_boolean':
> >[many more multiple symbols]
> >
> >The log indicates that all YAZ symbols are included twice. Apparenly the
> >Zend link step includes YAZ verbatim even though NO symbols should be needed
> >to built that.
> >
> >Solutions / work-arounds:
> >
> >1) removing /usr/lib/libyaz.la makes it work. Suddenly, the Zend link step
> >   doesn't include YAZ so everything is fine. Libtool bug?
> >
> >2) removing the linkage of yaz from the Zend link step obviously makes it
> >   work too.
> >
> >3) build shared YAZ objects is a fix too. (./configure --enabled-shared for YAZ).
> >
> >The problem doesn't occur with PHP 4.0.6.

Re: [PHP-DEV] Linking PHP with static Libtool libraries

[Adam Dickmeiss]

I also upgraded Libtool of PHP. Result the same :(

$ ./libtool --version
ltmain.sh (GNU libtool) 1.4.2a (1.922.2.79 2001/11/28 21:50:31)

I'm using apxs:
$ ./configure --with-yaz --with-apxs=/home/adam/proj/apache/bin/apxs

-- Adam

On Fri, Dec 14, 2001 at 05:55:02PM +0100, Adam Dickmeiss wrote:
> I have the following problem. On UNIX, PHP fails to link with
> a static library generated by Libtool. Problem occurs with PHP 4.1.0
> but not PHP 4.0.6. The YAZ extension, for example, which I maintain
> generates by default a static Libtool library only. So After doing
>cd yaz-1.8.3
>./configure --prefix=/usr
>make
>make install
> 
> two files are created, namely /usr/lib/libyaz.a and /lib/lib/libyaz.la.
> 
> For PHP I do : 
>./configure --with-yaz [other options]
> 
> and get the folloing make output:
> ..
> /bin/sh ../libtool --silent --mode=link gcc  -g -O2 -prefer-pic  -o libZend.la  -ldl 
>-lyaz -lcrypt -lresolv -lm -ldl -lnsl  -lresolv 
> -lcrypt  zend_language_parser.lo zend_language_scanner.lo zend_ini_parser.lo 
>zend_ini_scanner.lo zend_alloc.lo zend_compile.lo zend_c
> onstants.lo zend_dynamic_array.lo zend_execute.lo zend_execute_API.lo 
>zend_highlight.lo zend_llist.lo zend_opcode.lo zend_operators.l
> o zend_ptr_stack.lo zend_stack.lo zend_variables.lo zend.lo zend_API.lo 
>zend_extensions.lo zend_hash.lo zend_list.lo zend_indent.lo z
> end_builtin_functions.lo zend_sprintf.lo zend_ini.lo  
> make[1]: Leaving directory `/home/adam/proj/php-4.1.0/Zend'
> ...
> /bin/sh /home/adam/proj/php-4.1.0/libtool --silent --mode=link gcc  -I. 
>-I/home/adam/proj/php-4.1.0/ -I/home/adam/proj/php-4.1.0/main
>  -I/home/adam/proj/php-4.1.0 -I/home/adam/proj/apache/include 
>-I/home/adam/proj/php-4.1.0/Zend -I/home/adam/proj/php-4.1.0/ext/mysql/
> libmysql -I/home/adam/proj/php-4.1.0/ext/xml/expat  -DLINUX=22 -DUSE_HSREGEX 
>-DUSE_EXPAT -I/home/adam/proj/php-4.1.0/TSRM -g -O2 -pre
> fer-pic   -o libphp4.la -rpath /home/adam/proj/php-4.1.0/libs -avoid-version   
>stub.lo  Zend/libZend.la sapi/apache/libsapi.la main/l
> ibmain.la regex/libregex.la ext/mysql/libmysql.la ext/pcre/libpcre.la 
>ext/posix/libposix.la ext/session/libsession.la ext/standard/li
> bstandard.la ext/xml/libxml.la ext/yaz/libyaz.la TSRM/libtsrm.la -ldl -lyaz -lcrypt 
>-lresolv -lm -ldl -lnsl -lresolv -lcrypt
> /usr/lib/libyaz.a(odr_bool.o): In function `odr_bool':
> /home/adam/proj/yaz/odr/odr_bool.c(.text+0x0): multiple definition of `odr_bool'
> Zend/.libs/libZend.al(odr_bool.o)(.text+0x0):/home/adam/proj/yaz/odr/odr_bool.c: 
>first defined here
> /usr/lib/libyaz.a(ber_bool.o): In function `ber_boolean':
> [many more multiple symbols]
> 
> The log indicates that all YAZ symbols are included twice. Apparenly the
> Zend link step includes YAZ verbatim even though NO symbols should be needed
> to built that.
> 
> Solutions / work-arounds:
> 
> 1) removing /usr/lib/libyaz.la makes it work. Suddenly, the Zend link step
>doesn't include YAZ so everything is fine. Libtool bug?
> 
> 2) removing the linkage of yaz from the Zend link step obviously makes it
>work too.
> 
> 3) build shared YAZ objects is a fix too. (./configure --enabled-shared for YAZ).
> 
> The problem doesn't occur with PHP 4.0.6. Probably due to the fact that
> it uses libtool 1.3.5.
> 
> The problem currently only exists with YAZ (I guess most other packages
> are shared objects ONLY). But it would really be convenient if extensions
> could use static libraries as well.
> 
> If this is a libtool bug and there's no easy fix for that, my suggestion would be
> that Zend doesn't link with YAZ or other extension libraries. Fix 2) above.
> 
> -- Adam
> 
> -- 
> Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
> Index Data  T: +45 33410100   Mob.: 212 212 66
> 
> -- 
> 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]

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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] Linking PHP with static Libtool libraries

[Adam Dickmeiss]

On Fri, Dec 14, 2001 at 07:44:28PM +0200, Jani Taskinen wrote:
> 
> Does this happen with latest CVS?
Yes.

> --Jani
> 
> 
> On Fri, 14 Dec 2001, Adam Dickmeiss wrote:
> 
> >I have the following problem. On UNIX, PHP fails to link with
> >a static library generated by Libtool. Problem occurs with PHP 4.1.0
> >but not PHP 4.0.6. The YAZ extension, for example, which I maintain
> >generates by default a static Libtool library only. So After doing
> >   cd yaz-1.8.3
> >   ./configure --prefix=/usr
> >   make
> >   make install
> >
> >two files are created, namely /usr/lib/libyaz.a and /lib/lib/libyaz.la.
> >
> >For PHP I do :
> >   ./configure --with-yaz [other options]
> >
> >and get the folloing make output:
> >..
> >/bin/sh ../libtool --silent --mode=link gcc  -g -O2 -prefer-pic  -o libZend.la  
>-ldl -lyaz -lcrypt -lresolv -lm -ldl -lnsl  -lresolv
> >-lcrypt  zend_language_parser.lo zend_language_scanner.lo zend_ini_parser.lo 
>zend_ini_scanner.lo zend_alloc.lo zend_compile.lo zend_c
> >onstants.lo zend_dynamic_array.lo zend_execute.lo zend_execute_API.lo 
>zend_highlight.lo zend_llist.lo zend_opcode.lo zend_operators.l
> >o zend_ptr_stack.lo zend_stack.lo zend_variables.lo zend.lo zend_API.lo 
>zend_extensions.lo zend_hash.lo zend_list.lo zend_indent.lo z
> >end_builtin_functions.lo zend_sprintf.lo zend_ini.lo
> >make[1]: Leaving directory `/home/adam/proj/php-4.1.0/Zend'
> >...
> >/bin/sh /home/adam/proj/php-4.1.0/libtool --silent --mode=link gcc  -I. 
>-I/home/adam/proj/php-4.1.0/ -I/home/adam/proj/php-4.1.0/main
> > -I/home/adam/proj/php-4.1.0 -I/home/adam/proj/apache/include 
>-I/home/adam/proj/php-4.1.0/Zend -I/home/adam/proj/php-4.1.0/ext/mysql/
> >libmysql -I/home/adam/proj/php-4.1.0/ext/xml/expat  -DLINUX=22 -DUSE_HSREGEX 
>-DUSE_EXPAT -I/home/adam/proj/php-4.1.0/TSRM -g -O2 -pre
> >fer-pic   -o libphp4.la -rpath /home/adam/proj/php-4.1.0/libs -avoid-version   
>stub.lo  Zend/libZend.la sapi/apache/libsapi.la main/l
> >ibmain.la regex/libregex.la ext/mysql/libmysql.la ext/pcre/libpcre.la 
>ext/posix/libposix.la ext/session/libsession.la ext/standard/li
> >bstandard.la ext/xml/libxml.la ext/yaz/libyaz.la TSRM/libtsrm.la -ldl -lyaz -lcrypt 
>-lresolv -lm -ldl -lnsl -lresolv -lcrypt
> >/usr/lib/libyaz.a(odr_bool.o): In function `odr_bool':
> >/home/adam/proj/yaz/odr/odr_bool.c(.text+0x0): multiple definition of `odr_bool'
> >Zend/.libs/libZend.al(odr_bool.o)(.text+0x0):/home/adam/proj/yaz/odr/odr_bool.c: 
>first defined here
> >/usr/lib/libyaz.a(ber_bool.o): In function `ber_boolean':
> >[many more multiple symbols]
> >
> >The log indicates that all YAZ symbols are included twice. Apparenly the
> >Zend link step includes YAZ verbatim even though NO symbols should be needed
> >to built that.
> >
> >Solutions / work-arounds:
> >
> >1) removing /usr/lib/libyaz.la makes it work. Suddenly, the Zend link step
> >   doesn't include YAZ so everything is fine. Libtool bug?
> >
> >2) removing the linkage of yaz from the Zend link step obviously makes it
> >   work too.
> >
> >3) build shared YAZ objects is a fix too. (./configure --enabled-shared for YAZ).
> >
> >The problem doesn't occur with PHP 4.0.6. Probably due to the fact that
> >it uses libtool 1.3.5.
> >
> >The problem currently only exists with YAZ (I guess most other packages
> >are shared objects ONLY). But it would really be convenient if extensions
> >could use static libraries as well.
> >
> >If this is a libtool bug and there's no easy fix for that, my suggestion would be
> >that Zend doesn't link with YAZ or other extension libraries. Fix 2) above.
> >
> >-- Adam
> >
> >
> 
> 
> -- 
> 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]

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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] Linking PHP with static Libtool libraries

[Adam Dickmeiss]

I have the following problem. On UNIX, PHP fails to link with
a static library generated by Libtool. Problem occurs with PHP 4.1.0
but not PHP 4.0.6. The YAZ extension, for example, which I maintain
generates by default a static Libtool library only. So After doing
   cd yaz-1.8.3
   ./configure --prefix=/usr
   make
   make install

two files are created, namely /usr/lib/libyaz.a and /lib/lib/libyaz.la.

For PHP I do : 
   ./configure --with-yaz [other options]

and get the folloing make output:
..
/bin/sh ../libtool --silent --mode=link gcc  -g -O2 -prefer-pic  -o libZend.la  -ldl 
-lyaz -lcrypt -lresolv -lm -ldl -lnsl  -lresolv 
-lcrypt  zend_language_parser.lo zend_language_scanner.lo zend_ini_parser.lo 
zend_ini_scanner.lo zend_alloc.lo zend_compile.lo zend_c
onstants.lo zend_dynamic_array.lo zend_execute.lo zend_execute_API.lo 
zend_highlight.lo zend_llist.lo zend_opcode.lo zend_operators.l
o zend_ptr_stack.lo zend_stack.lo zend_variables.lo zend.lo zend_API.lo 
zend_extensions.lo zend_hash.lo zend_list.lo zend_indent.lo z
end_builtin_functions.lo zend_sprintf.lo zend_ini.lo  
make[1]: Leaving directory `/home/adam/proj/php-4.1.0/Zend'
...
/bin/sh /home/adam/proj/php-4.1.0/libtool --silent --mode=link gcc  -I. 
-I/home/adam/proj/php-4.1.0/ -I/home/adam/proj/php-4.1.0/main
 -I/home/adam/proj/php-4.1.0 -I/home/adam/proj/apache/include 
-I/home/adam/proj/php-4.1.0/Zend -I/home/adam/proj/php-4.1.0/ext/mysql/
libmysql -I/home/adam/proj/php-4.1.0/ext/xml/expat  -DLINUX=22 -DUSE_HSREGEX 
-DUSE_EXPAT -I/home/adam/proj/php-4.1.0/TSRM -g -O2 -pre
fer-pic   -o libphp4.la -rpath /home/adam/proj/php-4.1.0/libs -avoid-version   stub.lo 
 Zend/libZend.la sapi/apache/libsapi.la main/l
ibmain.la regex/libregex.la ext/mysql/libmysql.la ext/pcre/libpcre.la 
ext/posix/libposix.la ext/session/libsession.la ext/standard/li
bstandard.la ext/xml/libxml.la ext/yaz/libyaz.la TSRM/libtsrm.la -ldl -lyaz -lcrypt 
-lresolv -lm -ldl -lnsl -lresolv -lcrypt
/usr/lib/libyaz.a(odr_bool.o): In function `odr_bool':
/home/adam/proj/yaz/odr/odr_bool.c(.text+0x0): multiple definition of `odr_bool'
Zend/.libs/libZend.al(odr_bool.o)(.text+0x0):/home/adam/proj/yaz/odr/odr_bool.c: first 
defined here
/usr/lib/libyaz.a(ber_bool.o): In function `ber_boolean':
[many more multiple symbols]

The log indicates that all YAZ symbols are included twice. Apparenly the
Zend link step includes YAZ verbatim even though NO symbols should be needed
to built that.

Solutions / work-arounds:

1) removing /usr/lib/libyaz.la makes it work. Suddenly, the Zend link step
   doesn't include YAZ so everything is fine. Libtool bug?

2) removing the linkage of yaz from the Zend link step obviously makes it
   work too.

3) build shared YAZ objects is a fix too. (./configure --enabled-shared for YAZ).

The problem doesn't occur with PHP 4.0.6. Probably due to the fact that
it uses libtool 1.3.5.

The problem currently only exists with YAZ (I guess most other packages
are shared objects ONLY). But it would really be convenient if extensions
could use static libraries as well.

If this is a libtool bug and there's no easy fix for that, my suggestion would be
that Zend doesn't link with YAZ or other extension libraries. Fix 2) above.

-- Adam

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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 #14443 Updated: Double-free causes segfault in domxml

[adam]

ID: 14443
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Reproducible crash
Operating System: Linux Redhat 7.1
PHP Version: 4.0.6
New Comment:

I just looked at the php4 code in the CVS tree and it 
appears that this bug is already fixed, in a better way 
than I did it.  We'll have to look into upgrading to 4.1 I 
guess.  Thank you.

Adam


Previous Comments:


[2001-12-11 21:48:45] [EMAIL PROTECTED]

The code has changed quite a lot since 4.0.6. I can't reproduce the crash with the 
current CVS version. Please give it yourself a try.

Feedback.

PS: Patches not against CVS are most of the time useless because code tends to change 
a lot.



[2001-12-11 21:02:16] [EMAIL PROTECTED]

The domxml extension frees memory twice when an XPath 
query is used which results in an empty nodelist.  I'm 
providing a PHP script which reproduces the bug, and a 
patch to fix it.  

How to reproduce:

$xml = 'xml fragment';
$doc = xmldoc($xml);
$xh = $doc->xpath_new_context();
$nodes = xpath_eval($xh, 
   "xpath expression which doesn't match anything");

When the xpath expression doesn't match any nodes, then 
the xmlXPathObjectPtr which gets created by the query gets 
freed twice.  Usually a segfault won't occur unless you do 
8 or more non-matching XPath queries, since a single 
double-free won't always cause a segfault.  But if you run 
php with ElectricFence, a malloc debugging library, then a 
single non-matching XPath query will generate the 
double-free error.  

The bug is caused in the php_xpathptr_eval() function in 
php_domxml.c.  It calls xmlXPathEval() and saves the 
result in xpathobjp.  It then inserts xpathobjp into a 
zend list, le_xpathobjectp.  Later in the function, it 
checks whether xpathobjp contains an empty nodeset, and if 
it does, it calls xmlXPathFreeObject(xpathobjp) and 
returns FALSE.  But it didn't remove the xpathobjp pointer 
from the zend list before deleting it, so when PHP exits 
and cleans up the objects, the pointer sitting on the 
le_xpathobjp list gets freed again.  I fixed the bug by 
checking whether the nodeset is empty before it gets put 
on the zend list, and if it is empty, I free it and just 
return FALSE from the function.  

I'm appending my patch to php_domxml.c, a PHP program that 
triggers the bug in php 4.0.6, and also a stack trace 
showing where the crash occurs.

-- patch to php_domxml.c --
*** php-4.0.6-orig/ext/domxml/php_domxml.c  Thu May 24 
08:41:46 2001
--- php-4.0.6/ext/domxml/php_domxml.c   Tue Dec 11 
01:06:08 2001
***
*** 1681,1686 
--- 1681,1690 
if (!xpathobjp) {
RETURN_FALSE;
}
+   if (xpathobjp->type == XPATH_NODESET && 
!xpathobjp->nodesetval) {
+   xmlXPathFreeObject(xpathobjp);
+   RETURN_FALSE;
+   }
  
ret = zend_list_insert(xpathobjp, le_xpathobjectp);
zend_list_addref(ret);
-- end patch --

-- STACK TRACE --
Program received signal SIGSEGV, Segmentation fault.
chunk_free (ar_ptr=0x402fea00, p=0x8185180) at 
malloc.c:3180
3180in malloc.c
(gdb) bt
#0  chunk_free (ar_ptr=0x402fea00, p=0x8185180) at 
malloc.c:3180
#1  0x4024acd4 in __libc_free (mem=0x8185188) at 
malloc.c:3154
#2  0x4039b747 in xmlXPathFreeObject () from 
/usr/lib/libxml2.so.2
#3  0x40019f9d in php_free_xpath_object (rsrc=0x818514c) 
at php_domxml.c:188
#4  0x080c84b3 in list_entry_destructor (ptr=0x818514c) at 
zend_list.c:179
#5  0x080c70fa in zend_hash_apply_deleter (ht=0x8133fd0, 
p=0x8171b5c)
at zend_hash.c:615
#6  0x080c722a in zend_hash_graceful_destroy 
(ht=0x8133fd0) at zend_hash.c:666
#7  0x080c85e0 in zend_destroy_rsrc_list () at 
zend_list.c:234
#8  0x080bb42d in shutdown_executor () at 
zend_execute_API.c:179
#9  0x080c3265 in zend_deactivate () at zend.c:540
#10 0x0805de9d in php_request_shutdown (dummy=0x0) at 
main.c:660
#11 0x0805cfdd in main (argc=4, argv=0xb7f4) at 
cgi_main.c:751
#12 0x401e6627 in __libc_start_main (main=0x805c740 
, argc=4, 
ubp_av=0xb7f4, init=0x805ad5c <_init>, 
fini=0x80f4920 <_fini>, 
rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xb7ec)
at ../sysdeps/generic/libc-start.c:129
-- END STACK TRACE --

-- program to demonstrate bug --
Call this program with the serverid parameter set to 1 or 
2 will work fine, but call it with serverid=3 and it will 
segfault.




  

   cambridge.knumi.com 
   mms://cambridge.knumi.com/mysore-customer0 

   realxfer 
   xferreal 
   mysore-customer0 
   deleted-mysore-customer0 

   
http://cambridge.knumi.com/cgi-bin

[PHP-DEV] Bug #14443: Double-free causes segfault in domxml

[adam]

From: [EMAIL PROTECTED]
Operating system: Linux Redhat 7.1
PHP version:  4.0.6
PHP Bug Type: Reproducible crash
Bug description:  Double-free causes segfault in domxml

The domxml extension frees memory twice when an XPath 
query is used which results in an empty nodelist.  I'm 
providing a PHP script which reproduces the bug, and a 
patch to fix it.  

How to reproduce:

$xml = 'xml fragment';
$doc = xmldoc($xml);
$xh = $doc->xpath_new_context();
$nodes = xpath_eval($xh, 
   "xpath expression which doesn't match anything");

When the xpath expression doesn't match any nodes, then 
the xmlXPathObjectPtr which gets created by the query gets 
freed twice.  Usually a segfault won't occur unless you do 
8 or more non-matching XPath queries, since a single 
double-free won't always cause a segfault.  But if you run 
php with ElectricFence, a malloc debugging library, then a 
single non-matching XPath query will generate the 
double-free error.  

The bug is caused in the php_xpathptr_eval() function in 
php_domxml.c.  It calls xmlXPathEval() and saves the 
result in xpathobjp.  It then inserts xpathobjp into a 
zend list, le_xpathobjectp.  Later in the function, it 
checks whether xpathobjp contains an empty nodeset, and if 
it does, it calls xmlXPathFreeObject(xpathobjp) and 
returns FALSE.  But it didn't remove the xpathobjp pointer 
from the zend list before deleting it, so when PHP exits 
and cleans up the objects, the pointer sitting on the 
le_xpathobjp list gets freed again.  I fixed the bug by 
checking whether the nodeset is empty before it gets put 
on the zend list, and if it is empty, I free it and just 
return FALSE from the function.  

I'm appending my patch to php_domxml.c, a PHP program that 
triggers the bug in php 4.0.6, and also a stack trace 
showing where the crash occurs.

-- patch to php_domxml.c --
*** php-4.0.6-orig/ext/domxml/php_domxml.c  Thu May 24 
08:41:46 2001
--- php-4.0.6/ext/domxml/php_domxml.c   Tue Dec 11 
01:06:08 2001
***
*** 1681,1686 
--- 1681,1690 
if (!xpathobjp) {
RETURN_FALSE;
}
+   if (xpathobjp->type == XPATH_NODESET && 
!xpathobjp->nodesetval) {
+   xmlXPathFreeObject(xpathobjp);
+   RETURN_FALSE;
+   }
  
ret = zend_list_insert(xpathobjp, le_xpathobjectp);
zend_list_addref(ret);
-- end patch --

-- STACK TRACE --
Program received signal SIGSEGV, Segmentation fault.
chunk_free (ar_ptr=0x402fea00, p=0x8185180) at 
malloc.c:3180
3180in malloc.c
(gdb) bt
#0  chunk_free (ar_ptr=0x402fea00, p=0x8185180) at 
malloc.c:3180
#1  0x4024acd4 in __libc_free (mem=0x8185188) at 
malloc.c:3154
#2  0x4039b747 in xmlXPathFreeObject () from 
/usr/lib/libxml2.so.2
#3  0x40019f9d in php_free_xpath_object (rsrc=0x818514c) 
at php_domxml.c:188
#4  0x080c84b3 in list_entry_destructor (ptr=0x818514c) at 
zend_list.c:179
#5  0x080c70fa in zend_hash_apply_deleter (ht=0x8133fd0, 
p=0x8171b5c)
at zend_hash.c:615
#6  0x080c722a in zend_hash_graceful_destroy 
(ht=0x8133fd0) at zend_hash.c:666
#7  0x080c85e0 in zend_destroy_rsrc_list () at 
zend_list.c:234
#8  0x080bb42d in shutdown_executor () at 
zend_execute_API.c:179
#9  0x080c3265 in zend_deactivate () at zend.c:540
#10 0x0805de9d in php_request_shutdown (dummy=0x0) at 
main.c:660
#11 0x0805cfdd in main (argc=4, argv=0xb7f4) at 
cgi_main.c:751
#12 0x401e6627 in __libc_start_main (main=0x805c740 
, argc=4, 
ubp_av=0xb7f4, init=0x805ad5c <_init>, 
fini=0x80f4920 <_fini>, 
rtld_fini=0x4000dcd4 <_dl_fini>, stack_end=0xb7ec)
at ../sysdeps/generic/libc-start.c:129
-- END STACK TRACE --

-- program to demonstrate bug --
Call this program with the serverid parameter set to 1 or 
2 will work fine, but call it with serverid=3 and it will 
segfault.




  

   cambridge.knumi.com 
   mms://cambridge.knumi.com/mysore-customer0 

   realxfer 
   xferreal 
   mysore-customer0 
   deleted-mysore-customer0 

   
http://cambridge.knumi.com/cgi-bin/deletemediafiles.pl 




   colo3.knumi.net 
   rtsp://colo3.knumi.net/mysore-customer0 

   realxfer 
   krs@9555 
   mysore-customer0 
   deleted-mysore-customer0 

   
http://cambridge.knumi.com/cgi-bin/deletemediafiles.pl 




  

EOT;

$serverArray = array();
if (!isset($serverid)) {
  $serverid = 2;
}

$doc = xmldoc($xml);
$xp = $doc->xpath_new_context();

readServer($xp, "media", $serverid, "real");
print_r($serverArray);

function readServer($xp, $sType, $sId, $sSubType) 
{
  global $serverArray;

  $xPath = "/config/" . $sType . "serverlist/" . $sType . 
 "server[@type='$sSubType' and @id='$sId']/";

  $serverArray[$sType][$sId][$sSubType]["host"] = 
 getNodeValue($xp, $xPath . "host");
  $serverArray[$sType][$sId

Re: [PHP-DEV] Patch: Nested comments

[Adam Wright]

But in C, you can #if 0 whole blocks out regardless. I'm in favour of a
change like this (if not this specific one) in 4.2.

adamw

- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Anders Johannsen" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, November 27, 2001 5:21 PM
Subject: Re: [PHP-DEV] Patch: Nested comments


> I don't think this should be changed and we should stick to the way it is
> in C. (It is also not BC and even if I thought it's a good idea, which I
> don't, I don't think it's worth it).
>
> Andi
>
> At 11:48 AM 11/27/2001 +0100, Anders Johannsen wrote:
> >This patch allows for nested 'C-style' comments, which can be useful
> >especially while debugging.
> >
> >  > /* comments
> > /* now /* nest */ */
> >
> > /*/*/*/*
> > */*/*/*/
> > */
> > ?>
> >
> >Since comments are handled purely lexical, there should be virtually no
> >performance hit.
> >
> >The following two examples show how errors are handled:
> >
> >1)
> >  > /*
> > */
> > */
> > ?>
> >
> >2)
> >  > /*
> > /*
> > */
> > ?>
> >
> >Ad 1) This will yield a zend_error(E_COMPILE_ERROR,"Invalid nesting of
> >comments") on the
> >last line. Unpatched, a parse error is the most likely result.
> >
> >Ad 2) A zend_error(E_COMPILE_WARNING, "unterminated comment starting line
> >%d", CG(comment_start_line)) is raised.
> >
> >The attached patch is against latest CVS
> >
> >Best regards,
> >Anders Johannsen
> >--
> >[EMAIL PROTECTED]
> >
> >Index: zend_globals.h
> >===
> >RCS file: /repository/Zend/zend_globals.h,v
> >retrieving revision 1.80
> >diff -u -r1.80 zend_globals.h
> >--- zend_globals.h  2001/10/23 01:19:16 1.80
> >+++ zend_globals.h  2001/11/27 10:08:06
> >@@ -82,6 +82,7 @@
> > int comment_start_line;
> > char *heredoc;
> > int heredoc_len;
> >+unsigned int comment_nest_level;
> >
> > zend_op_array *active_op_array;
> >
> >Index: zend_language_scanner.l
> >===
> >RCS file: /repository/Zend/zend_language_scanner.l,v
> >retrieving revision 1.40
> >diff -u -r1.40 zend_language_scanner.l
> >--- zend_language_scanner.l 2001/09/22 00:06:27 1.40
> >+++ zend_language_scanner.l 2001/11/27 10:08:07
> >@@ -1,5 +1,4 @@
> >  %{
> >-
> >  /*
> >
> >+--+
> > | Zend
> >Engine  |
> >@@ -125,6 +124,7 @@
> >  {
> > CG(heredoc) = NULL;
> > CG(heredoc_len)=0;
> >+   CG(comment_nest_level)=0;
> >  }
> >
> >
> >@@ -1057,24 +1057,39 @@
> > }
> >  }
> >
> >+"*/" {
> >+   zend_error(E_COMPILE_ERROR,"Invalid nesting of comments");
> >+}
> >+
> >  "/*" {
> > CG(comment_start_line) = CG(zend_lineno);
> > BEGIN(ST_COMMENT);
> >+CG(comment_nest_level) = 1;
> > yymore();
> >  }
> >
> >-
> >-[^*]+ {
> >+[^/*]+ {
> > yymore();
> >  }
> >
> >+"/*" {
> >+CG(comment_nest_level)++;
> >+yymore();
> >+}
> >+
> >  "*/" {
> >-   HANDLE_NEWLINES(yytext, yyleng);
> >-   BEGIN(ST_IN_SCRIPTING);
> >-   return T_COMMENT;
> >+CG(comment_nest_level)--;
> >+
> >+if (CG(comment_nest_level) == 0) {
> >+HANDLE_NEWLINES(yytext, yyleng);
> >+   BEGIN(ST_IN_SCRIPTING);
> >+   return T_COMMENT;
> >+} else {
> >+ yymore();
> >+}
> >  }
> >
> >-"*" {
> >+"*"|"/" {
> > yymore();
> >  }
> >
> >
> >
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

[PHP-DEV] Bug #13601 Updated: File download with Content-Length specified fails with IE5.5

[adam]

ID: 13601
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Apache related
Operating System: Linux (Red Hat 7)
PHP Version: 4.0.6
New Comment:


Not tham I am specifically aware of, but it is highly possible that my ISP (BT 
Internet) has some kind of proxy.

Incidentally, I have tried a couple of different ISPs with the same result.

I would guess that this IS a proxying-related issue.

Previous Comments:


[2001-11-21 12:25:12] [EMAIL PROTECTED]

Are you sure there isn't some transparent proxy involved?




[2001-11-20 06:55:25] [EMAIL PROTECTED]

As stated in my original submission, EITHER going through a proxy, OR simply dialling 
up through an ISP, you get the problem.

Connecting directly over a LAN, you do not.

Please re-open.



[2001-11-14 06:41:49] [EMAIL PROTECTED]

No feedback. Closing.



[2001-10-23 06:23:12] [EMAIL PROTECTED]

I would guess this has something to do with proxy being 
in between..is there one?

--Jani




[2001-10-22 03:58:23] [EMAIL PROTECTED]

Yes.

In the script,

$size=filesize($file);

Where $file is the filename and path.

To prove that it's correct, I have printed the value. Also, both NS and IE (when it 
works, ie. not through a proxy), display the correct file size and bytes remaining, 
etc.





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


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


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

[PHP-DEV] Bug #13601 Updated: File download with Content-Length specified fails with IE5.5

[adam]

ID: 13601
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Apache related
Operating System: Linux (Red Hat 7)
PHP Version: 4.0.6
New Comment:

As stated in my original submission, EITHER going through a proxy, OR simply dialling 
up through an ISP, you get the problem.

Connecting directly over a LAN, you do not.

Please re-open.

Previous Comments:


[2001-11-14 06:41:49] [EMAIL PROTECTED]

No feedback. Closing.



[2001-10-23 06:23:12] [EMAIL PROTECTED]

I would guess this has something to do with proxy being 
in between..is there one?

--Jani




[2001-10-22 03:58:23] [EMAIL PROTECTED]

Yes.

In the script,

$size=filesize($file);

Where $file is the filename and path.

To prove that it's correct, I have printed the value. Also, both NS and IE (when it 
works, ie. not through a proxy), display the correct file size and bytes remaining, 
etc.





[2001-10-21 01:08:59] [EMAIL PROTECTED]

Is the $size correct for the file?





[2001-10-08 13:55:47] [EMAIL PROTECTED]

The following code:

$size = filesize($userfile);
$fp=fopen($userfile,"r");

header("Pragma: no-cache");// HTTP/1.0
header("Cache-Control: no-cache, must-revalidate");// HTTP/1.1
header("Content-Type: application/octet-stream");
if(preg_match("/MSIE 5.5/", $HTTP_USER_AGENT))
header("Content-Disposition: filename=$userfile");  
else
header("Content-Disposition: attachment; filename=$userfile"); 
header("Content-Length: $size");
header("Content-Transfer-Encoding: binary\n");
fpassthru($fp);

when run under Linux/Apache results in a zero length file on MS IE 5.5 when connecting 
via an ISP or proxy. I have tried various ISPs all with the same result. All is fine 
with Netscape, or with a direct LAN connection.

Also, if the same PHP script is run under Windows NT 4.0 / IIS 5.0 all is well. 

By removing the line: header("Content-Length: $size"); the download is successful, but 
we lose any progress bar so this workaround is far from ideal.





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


Edit this bug report at http://bugs.php.net/?id=13601&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] username of a currently logged in user

[Adam Wright]

Heya,

Just FYI, php-dev is for developing PHP (not developing *with* PHP) - You're
better off on [EMAIL PROTECTED]

$PHP_AUTH_USER is the right variable - Odds on, if there really is a user
logged in, you've in a function and have forgotten to globalise it (it's not
implicitly global).

adamw

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 30, 2001 3:38 PM
Subject: [PHP-DEV] username of a currently logged in user


> Hi,
> I've written a site using PHP that relies on htaccess authentication. This
> is all working fine, but I am having problems finding the username of the
> currently logged-in user (which I need to be able to change passwords). I
> thought $user contained the user, or $PHP_AUTH_USER but neither of these
> hold anything...
> any ideas?
> Cheers
> Rob
> -
> Rob Gudgeon
> BT Systems Engineer
> Distributed Platform Strategy & Design
> BT Affinitis - Computing Partners
> Phone: 020 7250 5156
> Mobile: 07720 052692
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

[PHP-DEV] Re: Bug #13856 Updated: bad option in 'configure --help'

[Adam Czysciak]

Hej,

  Wlasnie otrzymalem od Ciebie taki mail
  I've just received such a mail from You:

Temat/Subject: Bug #13856 Updated: bad option in 'configure --help'
Data/Date: 28 Oct 2001 14:20:30 -

  To jest potwierdzenie generowane automatycznie i oznacza
tylko tyle, ze Twoj mail dotarl w 100%.

  This is just a confirmation generated automatically. It
means that your mail has been successfully delivered.

-- 
Zycze milego dnia,
Have a nice day,
  Adam vel acc
  [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 #13856: bad option in 'configure --help'

[Adam Czysciak]

Hej,

  Wlasnie otrzymalem od Ciebie taki mail
  I've just received such a mail from You:

Temat/Subject: Bug #13856: bad option in 'configure --help'
Data/Date: 28 Oct 2001 12:34:24 -

  To jest potwierdzenie generowane automatycznie i oznacza
tylko tyle, ze Twoj mail dotarl w 100%.

  This is just a confirmation generated automatically. It
means that your mail has been successfully delivered.

-- 
Zycze milego dnia,
Have a nice day,
  Adam vel acc
  [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 #13601 Updated: File download with Content-Length specified fails with IE5.5

[adam]

ID: 13601
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: Apache related
Operating System: Linux (Red Hat 7)
PHP Version: 4.0.6
New Comment:

Yes.

In the script,

$size=filesize($file);

Where $file is the filename and path.

To prove that it's correct, I have printed the value. Also, both NS and IE (when it 
works, ie. not through a proxy), display the correct file size and bytes remaining, 
etc.



Previous Comments:


[2001-10-21 01:08:59] [EMAIL PROTECTED]

Is the $size correct for the file?





[2001-10-08 13:55:47] [EMAIL PROTECTED]

The following code:

$size = filesize($userfile);
$fp=fopen($userfile,"r");

header("Pragma: no-cache");// HTTP/1.0
header("Cache-Control: no-cache, must-revalidate");// HTTP/1.1
header("Content-Type: application/octet-stream");
if(preg_match("/MSIE 5.5/", $HTTP_USER_AGENT))
header("Content-Disposition: filename=$userfile");  
else
header("Content-Disposition: attachment; filename=$userfile"); 
header("Content-Length: $size");
header("Content-Transfer-Encoding: binary\n");
fpassthru($fp);

when run under Linux/Apache results in a zero length file on MS IE 5.5 when connecting 
via an ISP or proxy. I have tried various ISPs all with the same result. All is fine 
with Netscape, or with a direct LAN connection.

Also, if the same PHP script is run under Windows NT 4.0 / IIS 5.0 all is well. 

By removing the line: header("Content-Length: $size"); the download is successful, but 
we lose any progress bar so this workaround is far from ideal.





[2001-10-08 13:52:25] [EMAIL PROTECTED]

The following code:

$size = filesize($file);

header("Pragma: no-cache");// HTTP/1.0
header("Cache-Control: no-cache, must-revalidate");// HTTP/1.1
header("Content-Type: application/octet-stream");
if(preg_match("/MSIE 5.5/", $HTTP_USER_AGENT))
header("Content-Disposition: filename=$userfile");  
else
header("Content-Disposition: attachment; filename=$userfile"); 
header("Content-Length: $size");
header("Content-Transfer-Encoding: binary\n");
fpassthru($fp);

when run under Linux/Apache results in a zero length file on MS IE 5.5 when connecting 
via an ISP or proxy. I have tried various ISPs all with the same result. All is fine 
with Netscape, or with a direct LAN connection.

Also, if the same PHP script is run under Windows NT 4.0 / IIS 5.0 all is well. 

By removing the line: header("Content-Length: $size"); the download is successful, but 
we lose any progress bar so this workaround is far from ideal.







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


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

[PHP-DEV] question re: Bug id #5428

[Adam Wisniewski]

Hi all,

Link "http://bugs.php.net/bug-dos-and-donts.php"; is mentioned @
"http://bugs.php.net/bug.php?id=5428";, any idea if this link is still
working or around anywhere, or would it even be helpful to me.

I'm getting "segmentation fault (11)" when executing Sablotron's
xslt_process() function.
apache-1.3.19 / php-4.0.6 / Sablot-0.70 / expat-1.95.2



Thanks for any help,


Adam Wisniewski
TouchBase Consulting
1583 Woodgate Trail
Oshawa, Ontario
l1g 8c8
[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] Anybody tested the Apache module recently?

[Adam Dickmeiss]

Zeev,

how do you test before commit? I mean, what web server do you use
for development?

-- Adam

On Sun, Aug 26, 2001 at 02:48:14AM +0300, Zeev Suraski wrote:
> I think that was some breakage I was responsible for (I committed a fix 
> about 30 minutes later, only apparently I never actually finished editing 
> the commit message, so it never left my machine).
> 
> It should be fixed now.  Please let me know if it isn't.
> 
> Zeev
> 
> At 02:43 26-08-01, Rasmus Lerdorf wrote:
> >It seems to have completely broken as of a CVS update of a few minutes
> >ago.  Most of the time I get no output, but sometimes I get a very very
> >long row of ZZ's or sometimes I get
> >ZZZ?Ì?*Z?Ì?*Z
> >
> >Repeatedly loading a phpinfo() tends to toggle back and forth.  Single
> >stepping through things looks normal.  zif_phpinfo() is getting called and
> >everything looks fine.  So it is something lower level.  Output bufferring
> >changes messing things up?
> >
> >relevant php.ini settings:
> >
> >output_buffering= Off
> >output_handler  =
> >implicit_flush  = Off
> >zlib.output_compression = Off
> >
> >Same thing happens on a simple echo "Hello World" script.
> >An strace on that shows:
> >
> >{sin_family=AF_INET, sin_port=htons(42216), 
> >sin_addr=inet_addr("127.0.0.1")}}, [16]) = 3
> >rt_sigaction(SIGUSR1, {SIG_IGN}, {0x8074490, [], SA_INTERRUPT|0x400}, 
> >8) = 0
> >getsockname(3, {sin_family=AF_INET, sin_port=htons(80), 
> >sin_addr=inet_addr("127.0.0.1")}}, [16]) = 0
> >setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
> >alarm(300)  = 0
> >read(3, "GET /t.php HTTP/1.0\r\nConnection:"..., 4096) = 334
> >rt_sigaction(SIGUSR1, {SIG_IGN}, {SIG_IGN}, 8) = 0
> >time(NULL)  = 998782781
> >alarm(300)  = 300
> >alarm(0)= 300
> >stat64("/home/rasmus/phpweb/t.php", {st_mode=S_IFREG|0664, st_size=30, 
> >...}) = 0
> >alarm(300)  = 0
> >umask(077)  = 022
> >umask(022)  = 077
> >setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={30, 0}}, NULL) = 0
> >rt_sigaction(SIGPROF, {0x402102b0, [PROF], SA_RESTART|0x400}, 
> >{0x402102b0, [PROF], SA_RESTART|0x400}, 8) = 0
> >rt_sigprocmask(SIG_UNBLOCK, [PROF], NULL, 8) = 0
> >getcwd("/usr/local/home/rasmus/phpweb", 4095) = 30
> >chdir("/home/rasmus/phpweb")= 0
> >open("/home/rasmus/phpweb/t.php", O_RDONLY) = 4
> >getcwd("/usr/local/home/rasmus/phpweb", 4095) = 30
> >lstat64("/home", {st_mode=S_IFLNK|0777, st_size=15, ...}) = 0
> >readlink("/home", "/usr/local/home", 4095) = 15
> >lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> >lstat64("/usr/local", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
> >lstat64("/usr/local/home", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
> >lstat64("/usr/local/home/rasmus", {st_mode=S_IFDIR|0777, st_size=12288, 
> >...}) = 0
> >lstat64("/usr/local/home/rasmus/phpweb", {st_mode=S_IFDIR|0755, 
> >st_size=4096, ...}) = 0
> >lstat64("/usr/local/home/rasmus/phpweb/t.php", {st_mode=S_IFREG|0664, 
> >st_size=30, ...}) = 0
> >ioctl(4, TCGETS, 0xbfffe110)= -1 ENOTTY (Inappropriate ioctl 
> >for device)
> >fstat64(4, {st_mode=S_IFREG|0664, st_size=30, ...}) = 0
> >mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
> >= 0x40018000
> >read(4, "\n", 8192) = 30
> >read(4, "", 4096)   = 0
> >read(4, "", 8192)   = 0
> >ioctl(4, TCGETS, 0xbfffd0d0)= -1 ENOTTY (Inappropriate ioctl 
> >for device)
> >close(4)= 0
> >munmap(0x40018000, 4096)= 0
> >chdir("/usr/local/home/rasmus/phpweb")  = 0
> >alarm(300)  = 300
> >alarm(0)= 300
> >writev(3, [{"HTTP/1.1 200 OK\r\nDate: Sat, 25 A"..., 173}, 
> >{"ZZZ\204\314\217*\0\0\0\0\0"..., 4096}], 2) = 4269
> >rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0
> >setitimer(ITIMER_PROF, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
> >umask(022)  = 022
> >alarm(0)  

Re: [PHP-DEV] RSHUTDOWN, ISAPI

[Adam Dickmeiss]

Checked the latest CVS last week. The resources are now destroyed
and RSHUTDOWN is called always. So *something* is fixed.. 

Cheers,
   Adam

On Tue, Jun 26, 2001 at 05:47:49PM +0200, Adam Dickmeiss wrote:
> On Tue, Jun 26, 2001 at 04:57:34PM +0300, Zeev Suraski wrote:
> > If it indeed happens, it is a bug.  How did you check it?
> 
> When testing the YAZ extention I saw that for long searches (to
> a remote database) and repeated HTTP requests, the RSHUTDOWN wasn't
> called. I tried logging to a file open/close on each request to track
> it in RSHUTDOWN. The problem for this extension is that the resouces
> (each Z39.50 database session) are not freed. I then tried using proper
> resources as offered by the Zend API. Did something like
> 
>  le_link = zend_register_list_destructors_ex (yaz_close_link, 0,
>   "YAZ link", module_number);
> 
> and used ZEND_REGISTER_RESOURCE, etc. That didn't make a difference
> (yaz_close_link not being called). Either I do something wrong, or the
> resource management may be affected as well.
> 
> One obvious mistake I might have done is that the first thread is
> still running in my waiting for a search response from the database.
> I've verified that my wait (yaz_wait that is) really does return.
> So the request is done - no browser will read it - obviously.
> 
> Thank you for responding to this. 
> 
> Cheers,
>   Adam
> 
> > Zeev
> > 
> > At 10:26 26/6/2001, Adam Dickmeiss wrote:
> > >Hi,
> > >
> > >when running PHP using IIS in ISAPI (threaded) mode I notice that
> > >when a HTTP request is received before the current is finished,
> > >the RSHUTDOWN is not called for the first request (first thread).
> > >Hence, RSHUTDOWN is called once, but RINIT is called twice.
> > >
> > >Is that a bug or is that expected behavior?
> > >
> > >I compiled and used the latest CVS (that is - about one week ago).
> > >
> > >Cheers,
> > >   Adam
> > >
> > >--
> > >Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
> > >Index Data  T: +45 33410100   Mob.: 212 212 66
> > >
> > >--
> > >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/
> 
> -- 
> Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
> Index Data  T: +45 33410100   Mob.: 212 212 66
> 
> -- 
> 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]

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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 #12737: index bug concerning "00" and "08"

[Adam Wright]

0n defines octal representation (which is why 00 though 08 go 'wrong'). See
http://php.net/manual/en/language.types.integer.php

So, this isn't a bug in PHP.

adamw

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 14, 2001 11:03 AM
Subject: [PHP-DEV] Bug #12737: index bug concerning "00" and "08"


> From: [EMAIL PROTECTED]
> Operating system: Linux 2.2.19 #10 SMP i686
> PHP version:  4.0.5
> PHP Bug Type: Arrays related
> Bug description:  index bug concerning "00" and "08"
>
> Using 0 padded integers as index for an array:
> - does not work for 0 and 8
> - scrambles the order of the elements
>
> ---
> $a[00] = "string0";
> $a[01] = "string1";
> $a[02] = "string2";
> $a[03] = "string3";
> $a[04] = "string4";
> $a[05] = "string5";
> $a[06] = "string6";
> $a[07] = "string7";
> $a[08] = "string8";
> $a[09] = "string9";
>
> echo implode(";", $a);
> 
>
> This yields:
>
> string9;string1;string2;string3;string4;string5;string6;string7
> --
> Edit bug report at: http://bugs.php.net/?id=12737&edit=1
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP 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] undefined symbol: zendtext

[Adam Dickmeiss]

On Mon, Aug 06, 2001 at 09:25:19PM +0200, Jani Taskinen wrote:
> 
> I'm getting this with latest CVS. On apache startup.
> After Zeev's latest commits. I have tried a clean checkout too..no help.
> 
> --Jani

Removing a few lines fixes the Apache build...

Index: zend_indent.c
===
RCS file: /repository/Zend/zend_indent.c,v
retrieving revision 1.14
diff -u -r1.14 zend_indent.c
--- zend_indent.c   2001/08/06 13:48:51 1.14
+++ zend_indent.c   2001/08/06 21:39:23
@@ -26,13 +26,8 @@
 #include "zend_compile.h"
 #include "zend_indent.h"
 
-#ifndef ZTS
-extern char *zendtext;
-extern int zendleng;
-#else
 #define zendtext LANG_SCNG(yy_text)
 #define zendleng LANG_SCNG(yy_leng)
-#endif

Cheers,
  Adam

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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 #12572: sort() doesn't reindex 1 element arrays at 0

[adam]

From: [EMAIL PROTECTED]
Operating system: Redhat Linux 7.0
PHP version:  4.0.6
PHP Bug Type: Arrays related
Bug description:  sort() doesn't reindex 1 element arrays at 0

sort() reindexes arrays of length > 1 at 0, but doesn't do
this for 1 element arrays. The following patch, fixes this
minor inconsistancy. Please review it carefully, my C is
rusty and I don't normally play with these files. It does
build and seem to run correctly for me, with limited testing.

-adam

Here is an example:

$array = array(2 => 'foo', 'bar');
sort($array);
print_r($array);

Array
(
[0] => bar
[1] => foo
)

But, 

$array = array(2 => 'foo');
sort($array);
print_r($array);

Array
(
[2] => foo
)

--- zend_hash.c Sun Aug  5 01:17:22 2001
+++ /home/adam/zend_hash.c  Sun Aug  5 00:54:21 2001
@@ -1097,6 +1097,13 @@
IS_CONSISTENT(ht);
 
if (ht->nNumOfElements <= 1) {  /* Doesn't require sorting */
+
if (ht->nNumOfElements == 1 && renumber) { /* Renumber 1
element arrays to O */
+
p = ht->pListHead;
+
p->nKeyLength = 0;
+
p->h = 0;
+
ht->nNextFreeElement = 1;
+
zend_hash_rehash(ht);
+
}
 
return SUCCESS;
}
arTmp = (Bucket **) pemalloc(ht->nNumOfElements *
sizeof(Bucket *), ht->persistent);


-- 
Edit bug report at: http://bugs.php.net/?id=12572&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] Bug #12566 Updated: Cascaded ternaries evaluateincorrectly

[Adam Maccabee Trachtenberg]

On Sun, 5 Aug 2001, Jeroen van Wolffelaar wrote:

> On http://marc.theaimsgroup.com/?w=4&r=1&s=trachtenberg&q=a ,
> I could only find messages about break/continue in switch statements...

The subject line is misleading. We shifted into talking about ?:.

See me at the bottom of:

http://marc.theaimsgroup.com/?l=php-dev&m=97896924723440&w=4

and the follow ups.

-adam

-- 
adam maccabee trachtenberg
[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] Bug #12566 Updated: Cascaded ternaries evaluateincorrectly

[Adam Maccabee Trachtenberg]

It's not a "bug," but a "feature." :)

PHP has the inverse associativity of ?: compared to C (and every other
language). This was originally a mistake, but now "it won't be changed,"
due to historical reasons.

See some messages I had on php-dev back around the first week of January,
2001 on this topic. FWIW, I would like to change it.

-adam

On 4 Aug 2001 [EMAIL PROTECTED] wrote:

> ID: 12566
> Updated by: jeroen
> Reported By: [EMAIL PROTECTED]
> Status: Open
> Bug Type: *Programming Data Structures
> Operating System: Linux
> PHP Version: 4.0.6
> New Comment:
> 
> Confirmed in latest CVS:
> 
> ---
> echo TRUE ? 'one' : TRUE ? 'two' : 'unknown';
> => two
> ---
> echo TRUE ? 'one' : FALSE ? 'two' : 'unknown';
> => two
> ---
> This definitely is a bug, and IMO a serious one. A parse error would be acceptable 
>IMO (then use ( and )), but this isn't.
> 
> Previous Comments:


-- 
adam maccabee trachtenberg
[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 #12476: a function that splits a string into equal parts while retaining whole words

[adam]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  a function that splits a string into equal parts while retaining 
whole words

//perhaps a function like this
'.$columns[1];

?>

//outputting

blah blah blah

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


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

[PHP-DEV] Bug #12203: Inconsistent __FILE__ contents when using require/require_once

[adam]

From: [EMAIL PROTECTED]
Operating system: Red Hat 7.1
PHP version:  4.0.4pl1
PHP Bug Type: Filesystem function related
Bug description:  Inconsistent __FILE__ contents when using require/require_once

Not sure if this is a bug or a feature, or what the correct result should
be, but...

Related to bug #6636, require_once() and include_once() used on a soft link
will result in the __FILE__ constant containing only the filename of the
link, whereas include() and require() will result in __FILE__ containing
the full path and filename of the linked file.

ln -s /path/to/file.php /path/to/link.php

CASE ONE:
require_once('/path/to/link.php');

// returns 'link.php'
echo __FILE__;

CASE TWO:
require('/path/to/link.php');

// returns '/path/to/file.php'
echo __FILE__;
-- 
Edit bug report at: http://bugs.php.net/?id=12203&edit=1


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

[PHP-DEV] Expat XML problem

[Adam Wright]

./configure --with-xml=shared used to enable shared module support for the
Expat module, but as of 4.0.6 it doesn't seem to work. Expat support does
get compiled in, but not as a dynamic module. Is this a new bug, or just me
being dense?

adamw


-- 
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] RSHUTDOWN, ISAPI

[Adam Dickmeiss]

On Tue, Jun 26, 2001 at 04:57:34PM +0300, Zeev Suraski wrote:
> If it indeed happens, it is a bug.  How did you check it?

When testing the YAZ extention I saw that for long searches (to
a remote database) and repeated HTTP requests, the RSHUTDOWN wasn't
called. I tried logging to a file open/close on each request to track
it in RSHUTDOWN. The problem for this extension is that the resouces
(each Z39.50 database session) are not freed. I then tried using proper
resources as offered by the Zend API. Did something like

 le_link = zend_register_list_destructors_ex (yaz_close_link, 0,
  "YAZ link", module_number);

and used ZEND_REGISTER_RESOURCE, etc. That didn't make a difference
(yaz_close_link not being called). Either I do something wrong, or the
resource management may be affected as well.

One obvious mistake I might have done is that the first thread is
still running in my waiting for a search response from the database.
I've verified that my wait (yaz_wait that is) really does return.
So the request is done - no browser will read it - obviously.

Thank you for responding to this. 

Cheers,
  Adam

> Zeev
> 
> At 10:26 26/6/2001, Adam Dickmeiss wrote:
> >Hi,
> >
> >when running PHP using IIS in ISAPI (threaded) mode I notice that
> >when a HTTP request is received before the current is finished,
> >the RSHUTDOWN is not called for the first request (first thread).
> >Hence, RSHUTDOWN is called once, but RINIT is called twice.
> >
> >Is that a bug or is that expected behavior?
> >
> >I compiled and used the latest CVS (that is - about one week ago).
> >
> >Cheers,
> >   Adam
> >
> >--
> >Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
> >Index Data  T: +45 33410100   Mob.: 212 212 66
> >
> >--
> >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/

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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] RSHUTDOWN, ISAPI

[Adam Dickmeiss]

Hi,

when running PHP using IIS in ISAPI (threaded) mode I notice that
when a HTTP request is received before the current is finished,
the RSHUTDOWN is not called for the first request (first thread).
Hence, RSHUTDOWN is called once, but RINIT is called twice.

Is that a bug or is that expected behavior?

I compiled and used the latest CVS (that is - about one week ago).

Cheers,
  Adam

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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] multiselects and arrays

[Adam Wright]

Just from my point of view, I've got a lot of legacy code that relies on the
fact that multiple inputs/query variables with the same name override one
another. Changing this behaviour would break a lot of code methinks, but
would probably make more sense in the longterm.

adamw

- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "Max Vysotskiy" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, May 10, 2001 4:39 PM
Subject: Re: [PHP-DEV] multiselects and arrays


> On Thu, 10 May 2001, Max Vysotskiy wrote:
> > Thanx
> > But why not just to convert plain field names without [] to arrays??
> > Is there any reasons to not doing this?
>
> That's been a pet peeve of mine as well. I think that if PHP sees
> multiple variables with the same name in POST data, it should make an
> array out of them..
>
> -Andrei
> * All of the above is my opinion, unless specified otherwise. *
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

Re: [PHP-DEV] Re: [PHP-QA] 4.0.6

[Adam Trachtenberg]

On Wed, 2 May 2001, Andi Gutmans wrote:

> The COM problem would have been found IMO if we had released a bigger RC.

I think the COM problem would have been found if somebody ran the test
suite immediately before releasing 4.0.5 final. I think modifying the RC
process to ensure that the last thing we do before releasing is to make
sure the release passes the validation suite is a simpler step than
opening the QA process to thousands of less qualified testers.

I know the QAT does its best to build and validate the RCs on as many
platforms and configurations as possible. But, always adding in new
features, to go along with bug fixes, makes it harder to gather all the
testers together to review each RC. If we had less RCs or the RCs modified
fewer files, it'd be easier to ensure like mistakes like COM don't slip
through the cracks.

We always have minor buglets in the RCs. It's much easier for the QAT to
locate them internally than to wade through all the excess bug reports
that will come in. Mozilla makes their daily builds easily available,
which is great. OTOH, one of their biggest QA problems is getting people
to handle the huge amount of bug reports -- many of which are dups,
missing info, or bogus.

-adam

-- 
/ adam maccabee trachtenberg | visit college life online \
\ [EMAIL PROTECTED]   | http://www.student.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] Bug #10381: array_sum() on an undefined variable kills php

[Adam Wright]

Seems to be fixed in the latest CVS.

adamw

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, April 18, 2001 3:58 PM
Subject: [PHP-DEV] Bug #10381: array_sum() on an undefined variable kills
php


> From: [EMAIL PROTECTED]
> Operating system: Red Hat Linux 6.2
> PHP version:  4.0.4pl1
> PHP Bug Type: Reproduceable crash
> Bug description:  array_sum() on an undefined variable kills php
>
> Using array_sum() on an undefined causes php to core dump.
>
> uname:
> Linux redbox 2.2.17-14enterprise #1 SMP Mon Feb 5 18:31:31 EST 2001 i686
unknown
>
> configure:
> './configure' '--with-apache=../apache_1.3.19' '--enable-gd-imgstrttf'
'--with-gd' '--with-ttf' '--with-ldap' '--with-mysql=/usr' '--with-readline'
'--enable-sysvsem' '--enable-sysvshm' '--enable-shmop' '--with-zlib'
'--with-imap' '--with-imap-ssl' '--with-kerberos'
'--with-oracle=/opt/oracle/8.1.7' '--with-oci8=/opt/oracle/8.1.7'
'--with-gdbm' '--enable-dbase' '--with-snmp' '--enable-ucd-snmp-hack'
'--with-gettext' '--enable-track-vars' '--enable-versioning' '--enable-ftp'
'--enable-bcmath' '--with-pgsql' '--enable-calendar'
>
> [root@redbox address_book]# ls -l test.php
> -rwxr-xr-x1 root root   50 Apr 18 16:54 test.php
> [root@redbox address_book]# cat test.php
> #!/usr/local/bin/php -q
> 
> [root@redbox address_book]# ./test.php
> Segmentation fault (core dumped)
>
> If $a is defined this doesn't happen:
>
> [root@redbox address_book]# cat test.php
> #!/usr/local/bin/php -q
> 
> [root@redbox address_book]# ./test.php
> 0
>
>
> --
> Edit Bug report at: http://bugs.php.net/?id=10381&edit=1
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP 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] timezones and thread safety

[Adam Trachtenberg]

On Tue, 17 Apr 2001, Stephen van Egmond wrote:

> I'm a little bit baffled about why you would want to change the time
> zone while a system is up and running.   Isn't this the kind of thing
> you set and forget?

I guess that depends upon if you're interested in figuring out what time
it is someplace else...

-adam

-- 
/ adam maccabee trachtenberg | visit college life online \
\ [EMAIL PROTECTED]   | http://www.student.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] Segfault with current cvs

[Adam Dickmeiss]

Hi,

this patch seems to fix this.

RCS file: /repository/php4/ext/standard/dir.c,v
retrieving revision 1.59
diff -u -r1.59 dir.c
--- dir.c   2001/04/08 21:57:13 1.59
+++ dir.c   2001/04/09 19:28:43
@@ -141,7 +141,7 @@
 #endif
 tmpstr[0] = DEFAULT_SLASH;
 tmpstr[1] = '\0';
-REGISTER_STRING_CONSTANT("DIRECTORY_SEPARATOR", tmpstr, 0);
+REGISTER_STRING_CONSTANT("DIRECTORY_SEPARATOR", tmpstr, CONST_PERSISTENT);
 
return SUCCESS;
 }

Cheers,
  Adam

On Mon, Apr 09, 2001 at 03:15:36PM -0400, Jon Parise wrote:
> On Mon, Apr 09, 2001 at 09:11:42PM +0200, Jani Taskinen wrote:
> 
> > >Today's build is giving me this when I try to start Apache with PHP
> > >compiled as a DSO:
> > >
> > >Program received signal SIGSEGV, Segmentation fault.
> > >0x281cc7b1 in _efree (ptr=0x282c8650) at zend_alloc.c:227
> > >227 REMOVE_POINTER_FROM_LIST(p);
> > >
> > >./configure \
> > >--with-apxs=/usr/local/apache/bin/apxs \
> > >--with-config-file-path=/usr/local/apache/conf \
> > >--enable-ftp \
> > >--with-gettext \
> > >--with-imap=/usr/local \
> > >--without-mysql \
> > >--with-pgsql=/usr/local/pgsql \
> > >--enable-sockets \
> > >--enable-sysvsem \
> > >--enable-sysvshm \
> > >--enable-xml
> > >
> > >Any thoughts?
> >
> > Umm..backtrace?
> > 
> > --Jani
> 
> Woops.  Sorry about that.  I was rushing before.
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x281cc7b1 in _efree (ptr=0x282c8650) at zend_alloc.c:227
> 227 REMOVE_POINTER_FROM_LIST(p);
> (gdb) bt
> #0  0x281cc7b1 in _efree (ptr=0x282c8650) at zend_alloc.c:227
> #1  0x281e41c5 in _zval_dtor (zvalue=0x80d9140) at zend_variables.c:62
> #2  0x281d1e6e in free_zend_constant (c=0x80d9140) at zend_constants.c:31
> #3  0x281e8c97 in zend_hash_destroy (ht=0x80b9380) at zend_hash.c:564
> #4  0x281d221c in zend_shutdown_constants () at zend_constants.c:153
> #5  0x281e4ccf in zend_shutdown () at zend.c:444
> #6  0x281f63f4 in php_module_shutdown () at main.c:925
> #7  0x281f63bc in php_module_shutdown_wrapper (sapi_globals=0x282ae800) at main.c:900
> #8  0x281f44ec in apache_php_module_shutdown_wrapper () at mod_php4.c:694
> #9  0x8050b75 in run_cleanups ()
> #10 0x804f22b in ap_clear_pool ()
> #11 0x805fee4 in standalone_main ()
> #12 0x806083c in main ()
> #13 0x804eaa1 in _start ()
> 
> -- 
> 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]

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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_odbc.c code question

[Adam Trachtenberg]

On Mon, 2 Apr 2001, Dan Kalowsky wrote:

> In the current php_odbc.c file the following lines exist:
> 
> #ifndef HAVE_DBMAKER
> if ((*pv_onoff)) {
> #else
> if (pv_onoff && (*pv_onoff)) {
> #endif
> 
> these can be found in the odbc_autocommit function does anyone know
> why this has been #ifdef'ed around?  

Quoth the CVS logs:

"Added DBMaker support (patch by Pax Tsai...)"

from ssb on Nov 28 1999.

-adam

-- 
/ adam maccabee trachtenberg | visit college life online \
\ [EMAIL PROTECTED]   | http://www.student.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] non-thread-safe yet pthreads-friendly build of PHP?

[Adam Dickmeiss]

Hi,

this whole "feature" have caused me several headhaches too..

There seem to be some consencus on this mailing list at least, that
this error is related to GLIBC. Ulrich Drepper, GLIBC maintainer, doesn't
see it that way. I sent a small program that illustrates this behaviour,
and the response was "This is not bug. Live with it". 

And sure, I can live with it.. However, it would make life easier
if we could make Apache modules that could be loaded by a stock RPM
/ debian Apache package, whatever.. wihtout having to rebuild all
the time. Afterall, that's the whole point of loadable modules.

If this is a feature and not a bug at least the package maintainers
could build the Apacher core server with pthread linked it in.

Allow me to attach the test scenario.. Note that it works fine on
Solaris 2.6... The generated program main-wt works OK since it is
linked with pthread -- the other, main-wot, without threads, dies
with a SEGV.

[snip] sub.c:
int sub(void) { return 1; }

[snip] main.c:

#include 
#include 
#include 

int main(int argc, char **argv)
{
void *h;

h = dlopen ("./sub.so", RTLD_NOW|RTLD_GLOBAL);
if (!h)
{
printf ("dlopen failed\n");
exit (1);
}
gethostbyname("slashdot.org");
dlclose (h);

exit (0);
}

[snip] Makefile
all: sub.so main-wt main-wot

sub.so: sub.c
gcc -D_REENTRANT -shared sub.c -o sub.so -lpthread

main-wt: main.c
gcc main.c -o main-wt -ldl -lpthread

main-wot: main.c
gcc main.c -o main-wot -ldl

clean:
rm -f main-wt main-wot sub.so core

[end]


On Tue, Mar 27, 2001 at 06:03:49PM -0600, Jason Greene wrote:
> I have ran into this issue many times, with the sudden system call switch between
> a threaded and non-threaded mode.  In one scenario I had a problem where a 3rd party 
>module
> (chilisoft) was linked against an so that was linked against libpthread.
> 
> I had an issue where signals where not being utilized correctly
> (SIGALRM would no longer work after one try) which would break keep-alive in apache.
> 
> My first fix was a patch to the source to reset non-blocking on SIGALRM with every 
>request.
> Later I discovered just compiling the webserver with -lthread and -lpthread solved 
>all problems.
> 
> I am currently developing an Intermail module, which uses threads as well, and have 
>had no problems.
> (the same applies to the php/java module.)
> 
> I definitely think this is something that is not as well known as it should be.
> 
> -Jason
> 
[snip]

Cheers,
   Adam

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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] please remove pgsql warning on fetch_row - includes diff

[Adam Wright]

Heya,

Using your example...

  while (@pg_fetch_row()) {
   ...
   }

will suppress the warnings just for the call to pg_fetch_row.

adamw

- Original Message -
From: "Marc Boeren" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, March 26, 2001 10:47 AM
Subject: [PHP-DEV] please remove pgsql warning on fetch_row - includes diff


>
> Hi!
>
> The PostgreSQL module issues a warning when trying to fetch a row with an
> invalid rownumber. pg_fetch_row also returns false.
> I would ask if someone could remove the warning that is issued. The docs
> says the function returns false, this should be enough, I think.
> I would really like to construct a while-loop
> while (pg_fetch_row()) {
>   ...
>   }
>
> In fact, in the dbx-module I am doing exactly that, and the postgresql
> addition generates the warning even though the loop is ended
successfully...
>
> To make it easier, I attached a diff that removes said warning. I'm not
> really sure if this is how a patch is submitted (do you need a diff for
> that?), but if I'm doing something wrong maybe anyone can show me how it's
> done.
>
> Cheerio, Marc.
>
>
>
>
>  <>
>






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


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

Re: [PHP-DEV] PHP 4.0 Bug #9766: IRCG trouble

[Adam Dickmeiss]

Hi Sasha,

bug is closed. It was a stack overflow which is why it
was so difficult to track. Refer to the bug database.

Cheers,
  Adam

On Fri, Mar 16, 2001 at 04:56:28PM +0100, Sascha Schumann wrote:
> Hi Adam,
> 
> > the good thing is that the binary works! I am, however, still
> > unable to produce a binary myself that doesn' crash.
> > I've tried to upgrade to glibc 2.1.2 from 2.1.1. I've also tried
> > to recompile the whole thing on a Redhat 7.1 beta (Fisher) with kernel
> > 2.4.2-ac3 and glibc 2.2.1-3 installed and the PHP CVS snapshot from today.
> 
> Wow, you are putting quite a lot of energy into this :-)
> 
> > Perhaps I'm not compiling the stuff correctly. I used
> > the MANUAL method as described in the readme from the ircg
> > extension: - 1=install st, 2=instal IRCG, 3=unpack thttpd,
> > 4=php install, 5=patch thttpd, 6=compile,install thttpd.
> 
> Looks allright.  If thttpd starts up, it is very unlikely
> that you did something wrong during building it.
> 
> > On the Redhat 7.1 beta the GDB trace is somewhat more informative:
> >
> > #0  0x080ec730 in irc_cmd_RPL_NAMREPLY (conn=0x8186650, msg=0x4001a8f4)
> > at irc_dispatcher.c:189
> > 189 ep = irc_locate_channel(conn, msg->para[2].c);
> [..]
> > (gdb) print *msg
> > $2 = {cmd = {c = 0x4001aa13 "353", len = 3, a = 4}, nickname = {
> [..]
> 
> We are dereferencing a pointer in line 189, but that pointer
> seems to be valid.  So, I don't see any reason why it would
> segfault at that point.
> 
> As you are seeing this problem on multiple Linux
> installations, I'd recommened to use the install_ircg.sh
> script from
> 
> http://schumann.cx/ircg/install_ircg.sh
> 
> and set CFLAGS in line 19 to "-g".  Also make sure that you
> don't have any old header files/libraries hanging around.
> 
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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 #9766: IRCG trouble

[Adam Dickmeiss]

Hi,

the good thing is that the binary works! I am, however, still
unable to produce a binary myself that doesn' crash.
I've tried to upgrade to glibc 2.1.2 from 2.1.1. I've also tried
to recompile the whole thing on a Redhat 7.1 beta (Fisher) with kernel
2.4.2-ac3 and glibc 2.2.1-3 installed and the PHP CVS snapshot from today.

Perhaps I'm not compiling the stuff correctly. I used
the MANUAL method as described in the readme from the ircg
extension: - 1=install st, 2=instal IRCG, 3=unpack thttpd,
4=php install, 5=patch thttpd, 6=compile,install thttpd.

On the Redhat 7.1 beta the GDB trace is somewhat more informative:

#0  0x080ec730 in irc_cmd_RPL_NAMREPLY (conn=0x8186650, msg=0x4001a8f4)
at irc_dispatcher.c:189
189 ep = irc_locate_channel(conn, msg->para[2].c);
(gdb) bt
#0  0x080ec730 in irc_cmd_RPL_NAMREPLY (conn=0x8186650, msg=0x4001a8f4)
at irc_dispatcher.c:189
#1  0x080ece23 in dispatch_message (conn=0x8186650, msg=0x4001a8f4)
at irc_dispatcher.c:459
#2  0x080ed1da in irc_dispatcher (dummy=0x8186650) at irc_dispatcher.c:587
#3  0x4005cddf in _st_thread_main () at sched.c:608
(gdb) print conn
$1 = (irconn_t *) 0x8186650
(gdb) print *msg
$2 = {cmd = {c = 0x4001aa13 "353", len = 3, a = 4}, nickname = {
c = 0x4001aa05 "server.my.net 353", len = 10, a = 11}, para = {{
  c = 0x4001aa17 "adam-gamma", len = 10, a = 11}, {c = 0x4001aa22 "=", 
  len = 1, a = 2}, {c = 0x4001aa24 "#TitanChat", len = 10, a = 11}, {
  c = 0x4001aa30 "@adam-gamma ", len = 12, a = 13}, {
  c = 0x4001aa35 "-gamma ", len = 3, a = 4}, {c = 0x4001aa39 "ma ", 
  len = 9, a = 10}, {
  c = 0x4001aa43 "er.my.net 366 adam-gamma #TitanChat :End of /NAMES list.\r\n", 
len = 9, a = 10}, {
  c = 0x4001aa4d "366 adam-gamma #TitanChat :End of /NAMES list.\r\n", 
  len = 8, a = 9}, {
  c = 0x4001aa56 "gamma #TitanChat :End of /NAMES list.\r\n", len = 14, 
  a = 15}, {c = 0x4001aa65 "t :End of /NAMES list.\r\n", len = 10, 
  a = 11}, {c = 0x4001aa70 "NAMES list.\r\n", len = 10, a = 11}, {
  c = 0x4001aa7b "\r\n", len = 12, a = 13}, {
  c = 0x4001aa88 " 366 adam-gamma #TitanChat :End of /NAMES list.\r\n", 
  len = 11, a = 12}, {
  c = 0x4001aa94 "mma #TitanChat :End of /NAMES list.\r\n", len = 11, 
  a = 12}, {c = 0x4001aaa0 "at :End of /NAMES list.\r\n", len = 15, 
  a = 16}, {c = 0x4001aab1 " list.\r\n", len = 28, a = 29}, {c = 0x0, 
  len = 0, a = 0}, {c = 0x0, len = 0, a = 0}, {c = 0x0, len = 0, a = 0}, {
  c = 0x0, len = 0, a = 0}}, nr_para = 4}
(gdb) print *conn
$3 = {username = "adam-gamma\000tr_replace(\"\\n\", \"\", ", 
  username_len = 10 '\n', c = 0x8184da0, hooks = {0x8068af4 , 
0x806896c , 0x8068b60 , 0x8068ca0 , 
0x8068a98 , 0x80685c4 , 0x8067928 , 
0x80688c4 , 0, 0x8068688 , 
0x8068bbc , 0x80686e4 , 
0x8068740 , 0x806879c , 
0x8068850 , 0x80687f8 , 
0x8068cfc , 0x8068c18 }, server = {
__ss_family = 2, __ss_align = 1950741204, 
__ss_padding = "elect name=ptarget>';\n\tlast_selected_user = already_written ? 
window.userlist.document.forms[0].ptarget.options[window.u"}, 
  server_len = 16, sockpf = 2, status = 1 '\001', data = 0x8186650, 
  dispatcher = 0x4001aeec, channels = {slh_first = 0x818e380}, irc_msgbuf = {
slh_first = 0x0}, ident = "foo\000\000.sel", ident_len = 3 '\003', 
  password = "\000tedIndex].value : \"\";\n\tvar i, j", 
  realname = "Mozilla/5.0 (X11; U; Linux 2.4.0 i686; en-US; 0.8) Gecko/2001021"}

---
  Cheers,
 Adam

On Fri, Mar 16, 2001 at 10:00:35AM +0100, Sascha Schumann wrote:
> On Fri, 16 Mar 2001, Adam Dickmeiss wrote:
> 
> > OK, see http://www.php.net/bugs.php?id=9766&edit=1
> 
> Thanks.
> 
> In order to exclude bugs in the compiler/C library, can you
> please give this version a try?
> 
> http://schumann.cx/ircg/ircg-2.1-x86-linux.tar.gz
> 
> You can replace your thttpd copy with the bin/ircg file.  The
> effect you are seeing might be related to a bug in glibc
> 2.1.1.
> 
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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 #9766: IRCG trouble

[Adam Dickmeiss]

OK, see http://www.php.net/bugs.php?id=9766&edit=1

Thx

On Thu, Mar 15, 2001 at 08:30:52PM +0100, Sascha Schumann wrote:
> Hi,
> 
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x80ef6e5 in irc_cmd_RPL_NAMREPLY (conn=0x8189bb0, msg=0x401f591c)
> > at irc_dispatcher.c:181
> > 181 {
> 
> can you please provide further information by appending it to
> the bug report?
> 
> What kind of optimization are you using (-O3 or higher)?
> 
> What gcc version (gcc -v) and C library (ls -l /lib/libc-*)
> are you using?
> 
> What does the following show upon joining a channel?
> 
> $ export IRCG_OPTIONS=E
> $ thttpd -D -C /path/to/conf
> 
> - Sascha Experience IRCG
>   http://schumann.cx/http://schumann.cx/ircg
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]

-- 
Adam Dickmeiss  mailto:[EMAIL PROTECTED]  http://www.indexdata.dk
Index Data  T: +45 33410100   Mob.: 212 212 66

-- 
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 #9766: IRCG trouble

[adam]

From: [EMAIL PROTECTED]
Operating system: Redhat 6.0 / GNU Linux 2.2.5
PHP version:  4.0 Latest CVS (15/03/2001)
PHP Bug Type: Reproduceable crash
Bug description:  IRCG trouble

Crash in either ircg_set_current or ircg_join when
running the IRCG sample scripts as produced by Sasha.

We've installed
  latest php4 CVS (as of 15 march)
  thttpd 2.20b
  st 1.0 and st 1.1
  IRCG 2.1
  hybrid ircd (on localhost port 6667)

The trace below may be misleading because of the threads
involved.

Program received signal SIGSEGV, Segmentation fault.
0x80ef6e5 in irc_cmd_RPL_NAMREPLY (conn=0x8189bb0, msg=0x401f591c)
at irc_dispatcher.c:181
181 {
(gdb) bt
#0  0x80ef6e5 in irc_cmd_RPL_NAMREPLY (conn=0x8189bb0, msg=0x401f591c)
at irc_dispatcher.c:181
#1  0x80efde1 in dispatch_message (conn=0x8189bb0, msg=0x401f591c)
at irc_dispatcher.c:459
#2  0x80f01e3 in irc_dispatcher (dummy=0x8189bb0) at irc_dispatcher.c:587
#3  0x400bdd36 in _st_thread_main () at sched.c:500

The following, perhaps, helps:

(gdb) print *conn
$4 = {username = "ada\000\bÙ\[EMAIL PROTECTED][0].pta", 
  username_len = 3 '\003', c = 0x8186668, hooks = {0x80678b8 , 
0x8067720 , 0x8067924 , 0x8067a3c , 
0x806785c , 0x8067358 , 0x8066750 , 
0x8067658 , 0, 0x8067420 , 
0x806797c , 0x8067478 , 
0x80674d4 , 0x8067530 , 
0x80675e0 , 0x8067588 , 
0x8067a98 , 0x80679d4 }, server = {
sockaddr_storage_data = "\002\000\032\013ÔòEt, j;\n//\tvar count_user = 0;\n\tfor 
(i = 0; i < next_channel_id; i++) {\n\t\tbuf += ''+channels[i][0]+'';\n\t\tbuf2 += ', len = 2155872384, 
  a = 2155905152}, {c = 0x80808080 , 
  len = 2155905152, a = 2155905152}, {
  c = 0x80808000 , len = 2155905152, 
  a = 2155905152}, {c = 0x8090f080 , 
  len = 4042322160, a = 4042322160}, {
  c = 0x8090f0f0 , len = 2155905152, 
  a = 4042321920}, {c = 0xf0f0f0f0 , 
  len = 4042322160, a = 4042322160}, {
---Type  to continue, or q  to quit---
  c = 0xf0f0f0f0 , len = 4042322160, 
  a = 3237015792}, {c = 0xf0c0c0c0 , 
  len = 4042322048, a = 4042322160}}, nr_para = -252645136}




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