[PHP-DEV] PHP 4.0 Bug #9328 Updated: ext/pgsql/php_pgsql.h needs to include postgres_fe.h not postgres.h

[sas]

ID: 9328
Updated by: sas
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: PostgreSQL related
Assigned To: 
Comments:

Fixed in CVS. Thanks for your report.

Previous Comments:
---

[2001-02-18 17:59:52] [EMAIL PROTECTED]
Actually, you don't need EITHER file. 

Here is a new patch against 4.0.4pl1:
$ cvs diff -c -rREL_4_0_4pl1   
cvs diff: Diffing .
Index: php_pgsql.h
===
RCS file: /cvsroot/php/ext/pgsql/php_pgsql.h,v
retrieving revision 1.1.1.2
diff -c -r1.1.1.2 php_pgsql.h
*** php_pgsql.h 2000/12/23 23:05:41 1.1.1.2
--- php_pgsql.h 2001/02/18 22:57:20
***
*** 29,35 
  
  #ifdef PHP_PGSQL_PRIVATE
  #undef SOCKET_SIZE_TYPE
- #include 
  #include 
  
  #ifdef PHP_WIN32
--- 29,34 
$ 


---

[2001-02-18 17:37:21] [EMAIL PROTECTED]


Starting with PostgreSQL 7.1beta5 (or current CVS), PHP's pgsql
extension needs to only include  to compile. 

Here is a patch:

Index: php_pgsql.h
===
RCS file: /cvsroot/php/ext/pgsql/php_pgsql.h,v
retrieving revision 1.1.1.2
diff -c -r1.1.1.2 php_pgsql.h
*** php_pgsql.h 2000/12/23 23:05:41 1.1.1.2
--- php_pgsql.h 2001/02/18 21:15:45
***
*** 29,35 
  
  #ifdef PHP_PGSQL_PRIVATE
  #undef SOCKET_SIZE_TYPE
! #include 
  #include 
  
  #ifdef PHP_WIN32
--- 29,35 
  
  #ifdef PHP_PGSQL_PRIVATE
  #undef SOCKET_SIZE_TYPE
! #include 
  #include 
  
  #ifdef PHP_WIN32
-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749

$ 


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9328&edit=2


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

[PHP-DEV] Time for 4.0.5?

[Sascha Schumann]

Hi,

what do people think about a PHP 4.0.5 release?

We have about 70 change entries in NEWS.  Some of the changes
are fundamentally needed for some extensions to work
correctly or to compile at all.

Let me know your thoughts.

- Sascha


-- 
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] Time for 4.0.5?

[Derick Rethans]

On Mon, 19 Feb 2001, Sascha Schumann wrote:

> what do people think about a PHP 4.0.5 release?
>
> We have about 70 change entries in NEWS.  Some of the changes
> are fundamentally needed for some extensions to work
> correctly or to compile at all.
>
> Let me know your thoughts.

Sounds like a good idea, but I would like to fix the bugs in the mcrypt
extension before this release. What about making March 1, 2001 making the
day for RC 1?

Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [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] PHP 4.0 Bug #9004 Updated: Can not serialize($HTTP_SESSION_VARS);

[vgo]

ID: 9004
User Update by: [EMAIL PROTECTED]
Status: Closed
Bug Type: *Session related
Description: Can not serialize($HTTP_SESSION_VARS);

The "need" is to get all session variables in one string. Used for bug reporting

Previous Comments:
---

[2001-02-17 13:17:19] [EMAIL PROTECTED]
$HTTP_SESSION_VARS provides a means to access the contents of registered session 
variables if you have disabled register_globals.

There is no sense in doing the following 



Neither the code shown above, nor 

  $s = serialize($HTTP_SESSION_VARS);

causes a crash on my system.

---

[2001-01-30 10:52:36] [EMAIL PROTECTED]
The server crashes when executing this code ??? May be this is brohibited?

---


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


-- 
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] Time for 4.0.5?

[Peter \"[DiSAStA]\" Petermann]

> what do people think about a PHP 4.0.5 release?
> We have about 70 change entries in NEWS.  Some of the changes
> are fundamentally needed for some extensions to work
> correctly or to compile at all.
mh..
what about php-gtk? 
is it going to be included in release?
im not sure if this is ok?
Peter Petermann



-- 
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] Time for 4.0.5?

[Thies C. Arntzen]

On Mon, Feb 19, 2001 at 09:31:01AM +0100, Sascha Schumann wrote:
> Hi,
> 
> what do people think about a PHP 4.0.5 release?
> 
> We have about 70 change entries in NEWS.  Some of the changes
> are fundamentally needed for some extensions to work
> correctly or to compile at all.
> 
> Let me know your thoughts.

anytime - 

-- 
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] Time for 4.0.5?

[Cameron]

i'll agree its about due for release, can we do SOMETHING about the download
size tho? i dont really have any ideas on decent ways to shrink it but it
seems to be bloating to me. could do with the mcrypt fix's and zeev's output
buffer fix 1st tho . . .


Cameron Brunner

Sascha Schumann wrote:

> Hi,
>
> what do people think about a PHP 4.0.5 release?
>
> We have about 70 change entries in NEWS.  Some of the changes
> are fundamentally needed for some extensions to work
> correctly or to compile at all.
>
> Let me know your thoughts.
>
> - Sascha
>
> --
> 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 #9303: read() called with 'length' parameterreads until byte with ascii 10 or 13

[chrisv]

It's supposed to be a feature. There is a 4th parameter (has been there
since 4.0.4 or so), which specifies the type of read to perform. If you
want to simply read ignoring any delimiters, specify PHP_BINARY_READ for
the parameter. Or you can use recv() which performs the same function
(mostly).

Chris

> From: [EMAIL PROTECTED]
> Operating system: RedHat Linux
> PHP version:  4.0.4pl1
> PHP Bug Type: Sockets related
> Bug description:  read() called with 'length' parameter reads until byte with ascii 
>10 or 13
> 
> read($sockfd, $in, $length); If I read an arbitrary byte stream from the socket and 
>it happens to be ascii code (decimal) 10 or 13, the length parameter does not have 
>any affect on the number of bytes read from the socket. It stops at the first 
>occurence of the "magic" byte. To continue reading you have to call read again. It 
>does not look like so in the manual for the read() function. However, bytes following 
>ascii \0 and \t are succesfully read.
> Is this is the feature or a bug?
> PHP compiled --with-apxs --enable-sockets


-- 
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] Time for 4.0.5?

[Emiliano]

Cameron wrote:
> 
> i'll agree its about due for release, can we do SOMETHING about the download
> size tho? i dont really have any ideas on decent ways to shrink it but it
> seems to be bloating to me. could do with the mcrypt fix's and zeev's output
> buffer fix 1st tho . . .

Hum, having just contributed to said download size... we've done our
best to
minimize the KLOC, removing some cruft and moving a couple of functions
into
a (separate) library, but we'd be down to stripping comments to go
further...
the only other thing I could suggest is using bzip2 instead of gzip:

-rw-r--r--1 emileemile 1952068 Feb 19 10:53
php-4.0.4pl1.tar.bz
-rw-r--r--1 emileemile 2439189 Feb 19 10:52
php-4.0.4pl1.tar.gz

which is a 20% size reduction without changing anything else.

Emile

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

[PHP-DEV] PHP 4.0 Bug #9332: Crash in phpinfo with Netscape LDAP

[christophe . green]

From: [EMAIL PROTECTED]
Operating system: Solaris 2.6
PHP version:  4.0.4pl1
PHP Bug Type: Reproduceable crash
Bug description:  Crash in phpinfo with Netscape LDAP

PHP4 crashes in phpinfo() on Solaris 2.6, when configured with Netscape LDAP 


configure --with-ldap=/www/ldap
Netscape ldap lib : libldapssl30.so

Toto file containing just 
"php4 toto" crashes with message "Abort(coredump)"

The core file indicates a crash in sigprocmask function.



-- 
Edit Bug report at: http://bugs.php.net/?id=9332&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] PHP 4.0 Bug #9332 Updated: Crash in phpinfo with Netscape LDAP

[sniper]

ID: 9332
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Reproduceable crash
Assigned To: 
Comments:

Please include the configure line used to configure PHP 4 and if possible
a gdb backtrace of the crash.

--Jani


Previous Comments:
---

[2001-02-19 05:19:41] [EMAIL PROTECTED]
PHP4 crashes in phpinfo() on Solaris 2.6, when configured with Netscape LDAP 


configure --with-ldap=/www/ldap
Netscape ldap lib : libldapssl30.so

Toto file containing just 
"php4 toto" crashes with message "Abort(coredump)"

The core file indicates a crash in sigprocmask function.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9332&edit=2


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

[PHP-DEV] PHP 4.0 Bug #9333: imap_fetchstructure()

[yongjoo]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.1
PHP version:  4.0.4pl1
PHP Bug Type: IMAP related
Bug description:  imap_fetchstructure()

Hi.

I find bug IMAP related.

That is imap_fetchstructure.

In returned Objects for imap_fetchstructure() function, If type is application , 
return value must be 3.

But return value was 0.

Please Check this function in application type.


-- 
Edit Bug report at: http://bugs.php.net/?id=9333&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] PHP 4.0 Bug #6146 Updated: xml_parse() passes character entities incorrectly

[sniper]

ID: 6146
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: XML related
Assigned To: 
Comments:

Try the code. It shows what happens. The output should be same for
both test cases (the one with entitities breaks, ie. every entity is considered
a string itself)

I'm not sure if this is a bug in PHP but more likely in expat library itself.

--Jani


Previous Comments:
---

[2001-02-15 08:51:17] [EMAIL PROTECTED]
what is wrong with the output?


---

[2000-08-14 07:45:20] [EMAIL PROTECTED]
Here are an example xml-file and php-script which demonstrates
this behaviour:
-



åäöÅÄÖ
åäöÅÄÖ


-

";
}

$xml_parser = xml_parser_create();
xml_set_character_data_handler($xml_parser, "characterData");

if (!($fp = fopen($file, "r"))) {
die("could not open XML input");
}

while ($data = fread($fp, 4096)) {

if (!xml_parse($xml_parser, $data, feof($fp))) {
die(sprintf("XML error: %s at line %d",
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
}

?>

-

php configure line:

./configure 
--prefix=/data --with-config-file-path=/data/conf  
--with-mysql=/data/kolumbustori
--without-gd --disable-pear
--disable-debug

And the output with those files:
 
* *
* *
*åäöÅÄÖ*
* *
* *
*å*
*ä*
*ö*
*Å*
*Ä*
*Ö*
* *

--Jani

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6146&edit=2


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

[PHP-DEV] PHP 4.0 Bug #6146 Updated: xml_parse() passes character entities incorrectly

[thies]

ID: 6146
Updated by: thies
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: XML related
Assigned To: 
Comments:

that's the way expat works - you are never guaranteed that 
cdata is deliverd to the callback in one piece.




Previous Comments:
---

[2001-02-19 06:03:27] [EMAIL PROTECTED]
Try the code. It shows what happens. The output should be same for
both test cases (the one with entitities breaks, ie. every entity is considered
a string itself)

I'm not sure if this is a bug in PHP but more likely in expat library itself.

--Jani


---

[2001-02-15 08:51:17] [EMAIL PROTECTED]
what is wrong with the output?


---

[2000-08-14 07:45:20] [EMAIL PROTECTED]
Here are an example xml-file and php-script which demonstrates
this behaviour:
-



åäöÅÄÖ
åäöÅÄÖ


-

";
}

$xml_parser = xml_parser_create();
xml_set_character_data_handler($xml_parser, "characterData");

if (!($fp = fopen($file, "r"))) {
die("could not open XML input");
}

while ($data = fread($fp, 4096)) {

if (!xml_parse($xml_parser, $data, feof($fp))) {
die(sprintf("XML error: %s at line %d",
xml_error_string(xml_get_error_code($xml_parser)),
xml_get_current_line_number($xml_parser)));
}
}

?>

-

php configure line:

./configure 
--prefix=/data --with-config-file-path=/data/conf  
--with-mysql=/data/kolumbustori
--without-gd --disable-pear
--disable-debug

And the output with those files:
 
* *
* *
*åäöÅÄÖ*
* *
* *
*å*
*ä*
*ö*
*Å*
*Ä*
*Ö*
* *

--Jani

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6146&edit=2


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

[PHP-DEV] PHP 4.0 Bug #9334: Oracle8 connect by ODBC

[lewandowski-d]

From: [EMAIL PROTECTED]
Operating system: Win 98/NT
PHP version:  4.0.4
PHP Bug Type: ODBC related
Bug description:  Oracle8 connect by ODBC

I try connect to Oracle 8 by ODBC using odbc_connect.
Result is message:

Warning: SQL error: [Microsoft][ODBC DLL] Driver does not support this function, SQL 
state IM001 in SQLConnect in .. 

Connecting by ODBC using other methods (not by php) is without problems
Help me please


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

[CVS Account Request]

Full name: Dmitry Tkatchenko
Email: [EMAIL PROTECTED]
ID: dim
Purpose: mnogosearch documentation

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

[PHP-DEV] PHP 4.0 Bug #9335: configure fails to add -lc-client

[thies]

From: [EMAIL PROTECTED]
Operating system: Mandrake-cooker
PHP version:  4.0.4pl1
PHP Bug Type: IMAP related
Bug description:  configure fails to add -lc-client

subject says it.
also when i use phpize in ext imap to build a shared module for an already installed 
php i get:
cd php4/ext/imap
phpize
./configure
make
...
/bin/sh /home/thies/devel/imap/libtool --mode=link gcc  -I. -I/home/thies/devel/imap/ 
-I/home/thies/devel/imap/main -I/home/thies/devel/imap -I/usr/local/include/php 
-I/usr/local/include/php/main -I/usr/local/include/php/Zend 
-I/usr/local/include/php/TSRM -I/usr/include/imap   -g -O2   -o imap.la -avoid-version 
-module -rpath /home/thies/devel/imap/modules  php_imap.lo  -lcrypto -lssl 
-lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -Ryes/lib -Lyes/lib -limap
libtool: link: only absolute run-paths are allowed
...
config_vars.mk has a line saying:
IMAP_SHARED_LIBADD = -lcrypto -lssl -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err 
-Ryes/lib -Lyes/lib -limap

which is obviously incorrect.



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

[Cameron]

since sending this email i have been thinking a lot about it. bzip2 is fine for
many sys admins but we have the problem of the redhat users (dont take this the
wrong way please) that have used no other distributions and have only ever
installed an rpm before, for these users bzip2 would get confusing. im more
inclined to have multiple distribution's, a standard user one which would be
base+mysql+mcrypt+zlib and not much more, an oracle one etc. the only problem is
working out what modules people are mostly using. *grin*

any other suggestions?

Emiliano wrote:

> Cameron wrote:
> >
> > i'll agree its about due for release, can we do SOMETHING about the download
> > size tho? i dont really have any ideas on decent ways to shrink it but it
> > seems to be bloating to me. could do with the mcrypt fix's and zeev's output
> > buffer fix 1st tho . . .
>
> Hum, having just contributed to said download size... we've done our
> best to
> minimize the KLOC, removing some cruft and moving a couple of functions
> into
> a (separate) library, but we'd be down to stripping comments to go
> further...
> the only other thing I could suggest is using bzip2 instead of gzip:
>
> -rw-r--r--1 emileemile 1952068 Feb 19 10:53
> php-4.0.4pl1.tar.bz
> -rw-r--r--1 emileemile 2439189 Feb 19 10:52
> php-4.0.4pl1.tar.gz
>
> which is a 20% size reduction without changing anything else.
>
> Emile
>
> --
> 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] Time for 4.0.5?

[Emiliano]

Cameron wrote:
> 
> since sending this email i have been thinking a lot about it. bzip2 is fine for
> many sys admins but we have the problem of the redhat users (dont take this the
> wrong way please) that have used no other distributions and have only ever
> installed an rpm before, for these users bzip2 would get confusing. im more
> inclined to have multiple distribution's, a standard user one which would be
> base+mysql+mcrypt+zlib and not much more, an oracle one etc. the only problem is
> working out what modules people are mostly using. *grin*

Ah, that should not be too hard. In fact, RedHat does ship PHP in this
way I think.

> any other suggestions?

So, about stripping those somments ...

Seriously, we could offer the .tar.bz alongside the others. Those that
do have bzip2
will benefit.

Emile

-- 
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] Time for 4.0.5?

[Cynic]

I would welcome the win32 distributions packed with bzip2 
as well. This algorithm is superior to anything else I know 
(well, at least in compression ratio), and is available to 
win32 users as well. Not only as a commandline tool, but as 
a plugin for the very popular wincmd32 too. Anything bzipped 
is about half the size of that thing zipped.


At 13:49 19.2. 2001, Emiliano wrote the following:
-- 
>Cameron wrote:
>> 
>> since sending this email i have been thinking a lot about it. bzip2 is fine for
>> many sys admins but we have the problem of the redhat users (dont take this the
>> wrong way please) that have used no other distributions and have only ever
>> installed an rpm before, for these users bzip2 would get confusing. im more
>> inclined to have multiple distribution's, a standard user one which would be
>> base+mysql+mcrypt+zlib and not much more, an oracle one etc. the only problem is
>> working out what modules people are mostly using. *grin*
>
>Ah, that should not be too hard. In fact, RedHat does ship PHP in this
>way I think.
>
>> any other suggestions?
>
>So, about stripping those somments ...
>
>Seriously, we could offer the .tar.bz alongside the others. Those that
>do have bzip2
>will benefit.
>
>Emile
>
>-- 
>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]
--end of quote-- 




Cynic:

A member of a group of ancient Greek philosophers who taught
that virtue constitutes happiness and that self control is
the essential part of virtue.

[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] time to upgrade our bundled expat?

[Thies C. Arntzen]

v 1.95.1 is out (http://expat.sourceforge.net)

has anybody played with it?

tc

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

Re: [PHP-DEV] Time for 4.0.5?

[Derick Rethans]

Cameron wrote:
>
> since sending this email i have been thinking a lot about it. bzip2 is fine for
> many sys admins but we have the problem of the redhat users (dont take this the
> wrong way please) that have used no other distributions and have only ever
> installed an rpm before, for these users bzip2 would get confusing. im more

Then new RPM system uses bzip2 afaik, and it isn't that different from
tar.gz of course. I really don't see the problem here.

Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands
-


-- 
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] time to upgrade bundled PCRE?

[Thies C. Arntzen]

current version is 3.4 we use 3.2

andrei?

re,
tc

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

Re: [PHP-DEV] Time for 4.0.5?

[Phil Driscoll]

>any other suggestions?
There has been talk on here, or maybe on the QA list about a web page where
you tick the items you want, and just download the necessary components.
Maybe this was just in the context of PEAR - I can't remember. Anyway, is
anyone working on this? It seems to be a good solution to me (but then I
don't understand how the config and .m4 stuff works!).

Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org


-- 
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] time to upgrade our bundled expat?

[Emiliano]

"Thies C. Arntzen" wrote:
> 
> v 1.95.1 is out (http://expat.sourceforge.net)
> 
> has anybody played with it?

We use it a lot. Works well, supports multiple charsets, and is now in
as sane library format so internalizatin isn't strictly necesary
anymore (although there can be reasons to do so all the same, of
course).

Is there anything specific you want to know about it?

Emile

-- 
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] Time for 4.0.5?

[Derick Rethans]

On Mon, 19 Feb 2001, Cynic wrote:

> I would welcome the win32 distributions packed with bzip2
> as well. This algorithm is superior to anything else I know
> (well, at least in compression ratio), and is available to
> win32 users as well. Not only as a commandline tool, but as
> a plugin for the very popular wincmd32 too. Anything bzipped
> is about half the size of that thing zipped.

It's only that the most users se WinZip, which does not support it.

Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [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] Time for 4.0.5?

[Cameron]

Phil Driscoll wrote:

> >any other suggestions?
> There has been talk on here, or maybe on the QA list about a web page where
> you tick the items you want, and just download the necessary components.
> Maybe this was just in the context of PEAR - I can't remember. Anyway, is
> anyone working on this? It seems to be a good solution to me (but then I
> don't understand how the config and .m4 stuff works!).

that is pretty simple, make the client who is compiling the source do a
./buildconf first. if noone is working on this i am willing to offer to help
but for something like this i would prefer 2 or 3 coders doing it . . .


-- 
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] time to upgrade our bundled expat?

[Thies C. Arntzen]

On Mon, Feb 19, 2001 at 02:05:28PM +0100, Emiliano wrote:
> "Thies C. Arntzen" wrote:
> > 
> > v 1.95.1 is out (http://expat.sourceforge.net)
> > 
> > has anybody played with it?
> 
> We use it a lot. Works well, supports multiple charsets, and is now in
> as sane library format so internalizatin isn't strictly necesary
> anymore (although there can be reasons to do so all the same, of
> course).
> 
> Is there anything specific you want to know about it?

-was the upgrade from the original jclark-dist painfull at
 all? 
-are there any known incompatiblities? 
-do you think that if we upgrade the PHP 4 bundled expat
 we'll hit any wall?

tc

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

[PHP-DEV] PHP 4.0 Bug #9332 Updated: Crash in phpinfo with Netscape LDAP

[christophe . green]

ID: 9332
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Reproduceable crash
Description: Crash in phpinfo with Netscape LDAP

The configured line is the one I indicated, just configure --with-ldap=/www/ldap
Originally, I used other parameters, which I suppressed to isolate the problem.
The crash is always the same, php displays 
ldap
Then crashes with core dump

I don't have gdb. adb indicates:
SIGABRT: Abort

The backtrace is :

__sigprocmask() + 8
_resetsig(0xef4678a4,0x1365c8,0xef466bf0,0x0,0x0,0x136634) + 378
_sigon(?) + cc
_lmutex_unlock(0xef46b688,0xef46b668,0x13662c,0xefffe50c,0x6,0x1)



Previous Comments:
---

[2001-02-19 05:56:45] [EMAIL PROTECTED]
Please include the configure line used to configure PHP 4 and if possible
a gdb backtrace of the crash.

--Jani


---

[2001-02-19 05:19:41] [EMAIL PROTECTED]
PHP4 crashes in phpinfo() on Solaris 2.6, when configured with Netscape LDAP 


configure --with-ldap=/www/ldap
Netscape ldap lib : libldapssl30.so

Toto file containing just 
"php4 toto" crashes with message "Abort(coredump)"

The core file indicates a crash in sigprocmask function.


---


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


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

[PHP-DEV] PHP 4.0 Bug #9336: Upload image gets mime type written to top of image file

[dhamdan]

From: [EMAIL PROTECTED]
Operating system: RedHat Linux 7.0 2.2.16-22
PHP version:  4.0.4pl1
PHP Bug Type: HTTP related
Bug description:  Upload image gets mime type written to top of image file

I'm using this code to upload file:


Send this file: 



When I go to upload on image file (or an other file for that matter), the mime type 
gets written to the biginning of the file, thus making the image unviewable.

I installed php using the RedHat provided rpms.



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

[Hartmut Holzgraefe]

Cameron wrote:
> Phil Driscoll wrote:
> > There has been talk on here, or maybe on the QA list about a web page where
> > you tick the items you want, and just download the necessary components.
> that is pretty simple, make the client who is compiling the source do a
> ./buildconf first. if noone is working on this i am willing to offer to help
> but for something like this i would prefer 2 or 3 coders doing it . . .

we had a related idea to not include extensions considered experimental
like ext/zziplib that marked by an EXPERIMENTAL file in their ext dir

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77 

Besuchen Sie uns auf der CeBIT 2001 - in Halle 6 Stand F62/4

-- 
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] Time for 4.0.5?

[Derick Rethans]

On Mon, 19 Feb 2001, Hartmut Holzgraefe wrote:
>
> we had a related idea to not include extensions considered experimental
> like ext/zziplib that marked by an EXPERIMENTAL file in their ext dir

I'm not a supporter of this, the Sablotron is marked EXPERIMENTAL, but it
should definitely be in the distro. Maybe we should decide on PHP-DEV /
PHP-QA what will be included in the distro?

Derick Rethans

-
  PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED]
-
JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED]
 H.v. Tussenbroekstraat 1 - 6952 BL Dieren - The Netherlands
-


-- 
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] Time for 4.0.5?

[Sergey Kartashoff]

On Mon, 19 Feb 2001, Derick Rethans wrote:

> On Mon, 19 Feb 2001, Sascha Schumann wrote:
>
> > what do people think about a PHP 4.0.5 release?
> >
> > Let me know your thoughts.
>
> Sounds like a good idea, but I would like to fix the bugs in the mcrypt
> extension before this release. What about making March 1, 2001 making the
> day for RC 1?

I need some time too (one or two weeks) to finish mnoGoSearch extension
to support all of features of mnoGoSearch - 3.1.10.

It seems to me that March 1 is the resonable date for RC1 8)

-- 
Regards. Sergey aka gluke.


-- 
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] time to upgrade our bundled expat?

[Emiliano]

"Thies C. Arntzen" wrote:

> > We use it a lot. Works well, supports multiple charsets, and is now in
> > as sane library format so internalizatin isn't strictly necesary
> > anymore (although there can be reasons to do so all the same, of
> > course).
> >
> > Is there anything specific you want to know about it?
> 
> -was the upgrade from the original jclark-dist painfull at
>  all?

We haven't seen any API changes ourselves, and I think we use a fairly
sizeable part of the API. We had our own version of expat-lib, built
from jclark-dist, and include file name changes aside, it was painless.

> -are there any known incompatiblities?

Not that I know of, altough ISTR that apache had renamed some function
names for their internalized version. Our resident expat 'expert' will
be online in a few hours and I'm sure he can give you more details.

> -do you think that if we upgrade the PHP 4 bundled expat
>  we'll hit any wall?

In what sense?

Just to satisfy my curiosity, why is expat being internalized when
it's available as a library? To minimize external dependancies?

Emile

-- 
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] Time for 4.0.5?

[Cynic]

At 15:05 19.2. 2001, Derick Rethans wrote the following:
-- 
>On Mon, 19 Feb 2001, Cynic wrote:
>
>> I would welcome the win32 distributions packed with bzip2
>> as well. This algorithm is superior to anything else I know
>> (well, at least in compression ratio), and is available to
>> win32 users as well. Not only as a commandline tool, but as
>> a plugin for the very popular wincmd32 too. Anything bzipped
>> is about half the size of that thing zipped.
>
>It's only that the most users se WinZip, which does not support it.
>
>Derick Rethans

"If you want to save some bandwidth, here's the distro in a 
bzipped archive. bzip2 plugin for Windows Commander is 
available for free at www.ghisler.com."

I believe that a bzip verion of the large win32 distro would 
be somewhere about 2.3MB. That's quite nice, compared to 
3.6MB of the zip file.



Cynic:

A member of a group of ancient Greek philosophers who taught
that virtue constitutes happiness and that self control is
the essential part of virtue.

[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] Access to CVS

[Dmitry Tkatchenko]

Dear All!
I have again requested access to CVS to work on mnogosaearch 
documentation. 
Could anyone confirm registration please?
 
Thanx
Dmitry

RE: [PHP-DEV] Time for 4.0.5?

[James Moore]

> Hum, having just contributed to said download size... we've done our
> best to
> minimize the KLOC, removing some cruft and moving a couple of functions
> into
> a (separate) library, but we'd be down to stripping comments to go
> further...
> the only other thing I could suggest is using bzip2 instead of gzip:

At the moment I would personally advocate adding a EXPERIMENTAL file to
midgard firstly because the midgard team themselves state that its still
Beta and also if it is moved from main CVS at some point to PEAR etc then it
would probably be best not to distribute it with PHP at any point. I also
feel due to the amount of changes that have been made to midgard CVS in past
few days/weeks it doesnt to me seem stable enough or tested enough (at least
this beta version) to distribute with a release. Lets give it a bit of time
in CVS before we distribute it with PHP Releases.

James


-- 
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 #9197: crash in _efree

[David Benson]

> could you plz try:
> 
>  $Conn = OCINLogon ('vignette', 'vignette', 'wom_dev');
> $Clob = OCINewDescriptor($Conn, OCI_D_LOB);
> $ExtraXML = $Clob->load();
> ?>
> 
> if that still causes the crash then the bug is fixed in CVS!

Not sure what that was supposed to do ;-), but it caused the same crash.

David


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

[Thies C. Arntzen]

sascha,

phpize 
configure

does not work if try to external-compile any bundled modules
as the generated php_config.h is never included (the one from
/usr/local/include is found first) and thereby
the 

#define COMPILE_module_DL 1

is not seen by cpp so that

#ifdef COMPILE_DL_SABLOT
ZEND_GET_MODULE(sablot)
#endif

does not define the get_module() function.

suggestions?
tc




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

Re: [PHP-DEV] PHP 4.0 Bug #9197: crash in _efree

[Thies C. Arntzen]

On Mon, Feb 19, 2001 at 08:23:42AM -0700, David Benson wrote:
> > could you plz try:
> > 
> >  > $Conn = OCINLogon ('vignette', 'vignette', 'wom_dev');
> > $Clob = OCINewDescriptor($Conn, OCI_D_LOB);
> > $ExtraXML = $Clob->load();
> > ?>
> > 
> > if that still causes the crash then the bug is fixed in CVS!
> 
> Not sure what that was supposed to do ;-), but it caused the same crash.

nothing;-) - but your crash should be fixed in CVS. just examine
your code-snippet again and you'll see that the sequence that
caused your crash can be reduced to the 3 liner i sent.

tc

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

RE: [PHP-DEV] Time for 4.0.5?

[Hellekin O. Wolf]

Can we propose extensions outside of the main distribution ?

I like the idea of downloading what you want.

Through a form, you would chose the extensions you need, then submit and 
receive a custom GZIP or BZ2 file.
It sounds doable. Any constraint, dependency to work out ? Yes, the m4 
stuff... Can we open a thread on that specific topic of a PHP-downloader ?

*

Regarding midgard, although it is considered beta, I'm for including it 
into the main distrib for RC1, so that people can test it and eventually 
the midgard team can release a final version before 4.0.5 ships.

hellekin


-- 
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] time to upgrade bundled PCRE?

[Andrei Zmievski]

On Mon, 19 Feb 2001, Thies C. Arntzen wrote:
> 
> current version is 3.4 we use 3.2
> 
> andrei?

I will, probably in the next couple of days.

-Andrei
* On the keyboard of life, always keep one finger on the escape key. *

-- 
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] time to upgrade our bundled expat?

[Thies C. Arntzen]

On Mon, Feb 19, 2001 at 02:35:13PM +0100, Emiliano wrote:
> "Thies C. Arntzen" wrote:
> 
> > > We use it a lot. Works well, supports multiple charsets, and is now in
> > > as sane library format so internalizatin isn't strictly necesary
> > > anymore (although there can be reasons to do so all the same, of
> > > course).
> > >
> > > Is there anything specific you want to know about it?
> > 
> > -was the upgrade from the original jclark-dist painfull at
> >  all?
> 
> We haven't seen any API changes ourselves, and I think we use a fairly
> sizeable part of the API. We had our own version of expat-lib, built
> from jclark-dist, and include file name changes aside, it was painless.

cool - i'll try to bump up the bundled expat then.

> 
> > -are there any known incompatiblities?
> 
> Not that I know of, altough ISTR that apache had renamed some function
> names for their internalized version. Our resident expat 'expert' will
> be online in a few hours and I'm sure he can give you more details.

i think we have some namespace protection for "ours" as well.

> 
> > -do you think that if we upgrade the PHP 4 bundled expat
> >  we'll hit any wall?
> 
> In what sense?
> 
> Just to satisfy my curiosity, why is expat being internalized when
> it's available as a library? To minimize external dependancies?

yep, more and more ppl are using xml so bundleing reduces the
"noise" on the ML:-) we did the same with the mysql
client-lib for the very same reason.

tc

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

Re: [PHP-DEV] time to upgrade our bundled expat?

[Thies C. Arntzen]

On Mon, Feb 19, 2001 at 02:35:13PM +0100, Emiliano wrote:
> "Thies C. Arntzen" wrote:
> 
> > > We use it a lot. Works well, supports multiple charsets, and is now in
> > > as sane library format so internalizatin isn't strictly necesary
> > > anymore (although there can be reasons to do so all the same, of
> > > course).
> > >
> > > Is there anything specific you want to know about it?
> > 
> > -was the upgrade from the original jclark-dist painfull at
> >  all?
> 
> We haven't seen any API changes ourselves, and I think we use a fairly
> sizeable part of the API. We had our own version of expat-lib, built
> from jclark-dist, and include file name changes aside, it was painless.
> 
> > -are there any known incompatiblities?
> 
> Not that I know of, altough ISTR that apache had renamed some function
> names for their internalized version. Our resident expat 'expert' will
> be online in a few hours and I'm sure he can give you more details.

maybe they could enlighten me what advantages we'll see if we
upgrade?

tc

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

Re: [PHP-DEV] Time for 4.0.5?

[Andrei Zmievski]

On Mon, 19 Feb 2001, Sascha Schumann wrote:
> Hi,
> 
> what do people think about a PHP 4.0.5 release?
> 
> We have about 70 change entries in NEWS.  Some of the changes
> are fundamentally needed for some extensions to work
> correctly or to compile at all.
> 
> Let me know your thoughts.

I suggested 4.0.5 release a week ago, but haven't heard a peep from
anyone..

-Andrei
* Only 19,999 lines of C++ to my next ski trip... *

-- 
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] Time for 4.0.5?

[Andrei Zmievski]

On Mon, 19 Feb 2001, Peter [DiSAStA] Petermann wrote:
> > what do people think about a PHP 4.0.5 release?
> > We have about 70 change entries in NEWS.  Some of the changes
> > are fundamentally needed for some extensions to work
> > correctly or to compile at all.
> mh..
> what about php-gtk? 
> is it going to be included in release?
> im not sure if this is ok?

I'd rather keep php-gtk extension separate so it can have its own
release schedule instead of tying into PHP's one. And for some other
reasons.

-Andrei
* Gun manufacturers don't make bad products, bad parents do. *

-- 
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] Time for 4.0.5?

[Emiliano]

"Hellekin O. Wolf" wrote:
> 
> Can we propose extensions outside of the main distribution ?
> 
> I like the idea of downloading what you want.
> 
> Through a form, you would chose the extensions you need, then submit and
> receive a custom GZIP or BZ2 file.
> It sounds doable. Any constraint, dependency to work out ? Yes, the m4
> stuff... Can we open a thread on that specific topic of a PHP-downloader ?
> 
> *
> 
> Regarding midgard, although it is considered beta, I'm for including it
> into the main distrib for RC1, so that people can test it and eventually
> the midgard team can release a final version before 4.0.5 ships.

Yes. We're gearing up for final beta (or RC, would be another term for
it)
end of this week.

Emile

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

[PHP-DEV] PHP 4.0 Bug #9333 Updated: imap_fetchstructure()

[chagenbu]

ID: 9333
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: IMAP related
Assigned To: 
Comments:

Can you please use more words to describe this problem, and perhaps provide some 
example code and an example message?

Previous Comments:
---

[2001-02-19 06:01:08] [EMAIL PROTECTED]
Hi.

I find bug IMAP related.

That is imap_fetchstructure.

In returned Objects for imap_fetchstructure() function, If type is application , 
return value must be 3.

But return value was 0.

Please Check this function in application type.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9333&edit=2


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

[PHP-DEV] PHP 4.0 Bug #9337: make in_array return key, if searched value was found

[sbergmann]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  make in_array return key, if searched value was found

in_array() currently returns only true/false on whether or not a searched-for value is 
in a given array.

I would like it to return the key of the array's element when value was found, and 
false otherwise. This should not break existing code using in_array().



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



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

Re: [PHP-DEV] PHP 4.0 Bug #9337: make in_array return key, if searched value was found

[Andrei Zmievski]

On Mon, 19 Feb 2001, [EMAIL PROTECTED] wrote:
> From: [EMAIL PROTECTED]
> Operating system: 
> PHP version:  4.0.4pl1
> PHP Bug Type: Feature/Change Request
> Bug description:  make in_array return key, if searched value was found
> 
> in_array() currently returns only true/false on whether or not a searched-for value 
>is in a given array.
> 
> I would like it to return the key of the array's element when value was found, and 
>false otherwise. This should not break existing code using in_array().

Really? What if the key is 0?

-Andrei

Commitment, n.:
Commitment can be illustrated by a breakfast of ham and eggs. The chicken
was involved, the pig was committed.

-- 
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 #9337: make in_array return key, if searchedvalue was found

[Sebastian Bergmann]

Andrei Zmievski wrote:
> Really? What if the key is 0?

  Then we're fucked, damn it :-(

-- 
 sebastian bergmann e-mail :  [EMAIL PROTECTED]
  homepage :  http://www.sebastian-bergmann.de
   make a gift : http://wishlist.sebastian-bergmann.de
 measure the usability of your web application -> http://phpOpenTracker.de

-- 
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] Window's sources are out of date?

[Yury Faktorovich]

Hi ! Please forgive me if this question has been asked already, I
couldn't find it in archives. I downloaded php 4.0.4pl1 source and all
required patches to build it on windows. Build wasn't easy b'ze I didn't
know what to do with --S option passed to bison - bison barked at it, so
I just deleted this -S thing and got the build working. Now it seems to
me that Windows sources are actually out of date  - crypt support is
missing in my build. I actually went as far as building encrypt.c with
my build and finally got crypt to work with my version of PHP - but then
I downloaded the standard windows binaries and I see that crypt works
there already!!! Is it my imagination or binaries are built from some
different source?
Sorry for this distraction, it's just that I depend on sources being
upto date.
Thanks. Yury.


begin:vcard 
n:Faktorovich;Yury 
x-mozilla-html:FALSE
adr:;;
version:2.1
email;internet:[EMAIL PROTECTED]
fn:Yury Faktorovich
end:vcard



-- 
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] time to upgrade our bundled expat?

[Emiliano]

"Thies C. Arntzen" wrote:

> > Not that I know of, altough ISTR that apache had renamed some function
> > names for their internalized version. Our resident expat 'expert' will
> > be online in a few hours and I'm sure he can give you more details.
> 
> maybe they could enlighten me what advantages we'll see if we
> upgrade?

I'll leave this one to Alexander.

Emile

-- 
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] time to upgrade our bundled expat?

[Alexander Bokovoy]

On Mon, Feb 19, 2001 at 05:29:37PM +0100, Emiliano wrote:
> "Thies C. Arntzen" wrote:
> 
> > > Not that I know of, altough ISTR that apache had renamed some function
> > > names for their internalized version. Our resident expat 'expert' will
> > > be online in a few hours and I'm sure he can give you more details.
> > 
> > maybe they could enlighten me what advantages we'll see if we
> > upgrade?
> 
> I'll leave this one to Alexander.
I've already answered, unfortunately, privately to Thies :-)

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |Aurora R&D team 
Minsk Linux Users Group |www.minsk-lug.net|  www.aurora-linux.com  
   IPLabs Linux Team| linux.iplabs.ru | Architecte Open Source
-- Nothing ever becomes real until it is experienced.
- John Keats

-- 
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] time to upgrade our bundled expat?

[Alexander Bokovoy]

On Mon, Feb 19, 2001 at 02:09:36PM +0100, Thies C. Arntzen wrote:
> On Mon, Feb 19, 2001 at 02:05:28PM +0100, Emiliano wrote:
> > "Thies C. Arntzen" wrote:
> > > 
> > > v 1.95.1 is out (http://expat.sourceforge.net)
> > > 
> > > has anybody played with it?
> > 
> > We use it a lot. Works well, supports multiple charsets, and is now in
> > as sane library format so internalizatin isn't strictly necesary
> > anymore (although there can be reasons to do so all the same, of
> > course).
> > 
> > Is there anything specific you want to know about it?
> 
> -was the upgrade from the original jclark-dist painfull at
>  all? 
It was painless in sense that there was nothing to change in client code
except for #include  instead of those two headers.

> -are there any known incompatiblities? 
None.

> -do you think that if we upgrade the PHP 4 bundled expat
>  we'll hit any wall?
Be sure to make good configure detection for existing system library.
You can just borrow it from Midgard library, it works fine for us for 
many systems with different packaged versions of Expat (OpenBSD,
FreeBSD, Debian, RH, Mandrake/MandrakeCooker, Conectiva, etc).

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |Aurora R&D team 
Minsk Linux Users Group |www.minsk-lug.net|  www.aurora-linux.com  
   IPLabs Linux Team| linux.iplabs.ru | Architecte Open Source
-- Nothing ever becomes real until it is experienced.
- John Keats

-- 
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] time to upgrade our bundled expat?

[Alexander Bokovoy]

On Mon, Feb 19, 2001 at 04:35:50PM +0100, Thies C. Arntzen wrote:
> On Mon, Feb 19, 2001 at 02:35:13PM +0100, Emiliano wrote:
> > "Thies C. Arntzen" wrote:
> > 
> > > > We use it a lot. Works well, supports multiple charsets, and is now in
> > > > as sane library format so internalizatin isn't strictly necesary
> > > > anymore (although there can be reasons to do so all the same, of
> > > > course).
> > > >
> > > > Is there anything specific you want to know about it?
> > > 
> > > -was the upgrade from the original jclark-dist painfull at
> > >  all?
> > 
> > We haven't seen any API changes ourselves, and I think we use a fairly
> > sizeable part of the API. We had our own version of expat-lib, built
> > from jclark-dist, and include file name changes aside, it was painless.
> > 
> > > -are there any known incompatiblities?
> > 
> > Not that I know of, altough ISTR that apache had renamed some function
> > names for their internalized version. Our resident expat 'expert' will
> > be online in a few hours and I'm sure he can give you more details.
> 
> maybe they could enlighten me what advantages we'll see if we
> upgrade?
Well, first advantage is that Clark Cooper's team now is official Expat team,
JC has delegated expat development to them, so this Expat 1.95.1 is latest
official stable version.

Second, several bugs were fixed, look their project site for details.

Third, autoconf/automake now used to configure it which is much more painless.

Fourth, name space support was extended, support for own memory management was added,
set of functionality from Cooper's perl-expat was integrated.

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project   | www.midgard-project.org |Aurora R&D team 
Minsk Linux Users Group |www.minsk-lug.net|  www.aurora-linux.com  
   IPLabs Linux Team| linux.iplabs.ru | Architecte Open Source
-- Nothing ever becomes real until it is experienced.
- John Keats

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

[PHP-DEV] PHP 4.0 Bug #9161 Updated: Undefined symbols in static apache build using PHP 4.0.4pl1

[tcyrus]

ID: 9161
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache related
Description: Undefined symbols in static apache build using PHP 4.0.4pl1

No help.  I even started totally from scratch (removing all apache and php files and 
re-untaring them) and I get the same error.  Unfortunatley when I build Apache to run 
PHP dynamically, when I run: ./apachectl configtest
the error I get is:

Syntax error on line 207 of /usr/local/apache17/conf/httpd.conf:
Cannot load /usr/local/apache17/libexec/libphp4.so into server: ld.so.1: 
/usr/local/apache17/bin/httpd: fatal: relocation error: file 
/usr/local/apache17/libexec/libphp4.so: symbol pcre_free: referenced symbol not found

So on Solaris 2.6 (gcc 2.95.2) I'm stuck either way (static or dynamic) since both 
give me undefines.

Any other suggestions?

Previous Comments:
---

[2001-02-15 13:23:02] [EMAIL PROTECTED]
No help.  I even started totally from scratch (removing all apache and php files and 
re-untaring them) and I get the same error.  Unfortunatley when I build Apache to run 
PHP dynamically, when I run: ./apachectl configtest
the error I get is:

Syntax error on line 207 of /usr/local/apache17/conf/httpd.conf:
Cannot load /usr/local/apache17/libexec/libphp4.so into server: ld.so.1: 
/usr/local/apache17/bin/httpd: fatal: relocation error: file 
/usr/local/apache17/libexec/libphp4.so: symbol pcre_free: referenced symbol not found

So on Solaris 2.6 (gcc 2.95.2) I'm stuck either way (static or dynamic) since both 
give me undefines.

Any other suggestions?

---

[2001-02-14 14:11:33] [EMAIL PROTECTED]
Try doing 'make clean ; make install' for PHP 4 and then try making Apache 
again.

--Jani


---

[2001-02-07 13:18:52] [EMAIL PROTECTED]
apache_1.3.17 & php-4.0.4pl1 (Solaris 2.6 GCC 2.95.2) 

Atempting to static link php into apache.  Getting undefined symbols in apache 
(shown below).  config'd apache 1st, then config'd php using:
   ./configure --with-mysql --with-apache=../apache_1.3.17 --enable-track-vars
did a make and make install and all worked.  Then configured apache with:
./configure --prefix=/opt/apache --activate-module=src/modules/php4/libphp4.a
and make fails with the following.

Suggestions?

gcc  -DSOLARIS2=260 -I/opt/local/src/php-4.0.4pl1 -I/opt/local/src/php-4.0.4pl1/
main -I/opt/local/src/php-4.0.4pl1/main -I/opt/local/src/php-4.0.4pl1/Zend -I/op
t/local/src/php-4.0.4pl1/Zend -I/opt/local/src/php-4.0.4pl1/TSRM -I/opt/local/sr
c/php-4.0.4pl1/TSRM -I/opt/local/src/php-4.0.4pl1 -DUSE_EXPAT -I./lib/expat-lite
 -DNO_DL_NEEDED `./apaci`
  -o httpd buildmark.o modules.o modules/php4/libphp4.a modules/standard/lib
standard.a main/libmain.a ./os/unix/libos.a ap/libap.a  lib/expat-lite/libexpat.
a  -R/usr/ucblib -R/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2  -L/usr/uc
blib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2 -Lmodules/php4 -L../mo
dules/php4 -L../../modules/php4 -lmodphp4  -lpam  -ldl -lresolv -lresolv -lm -ld
l -lcrypt -lnsl -lsocket  -lsocket -lgcc   -lsocket -lnsl
Undefined   first referenced
 symbol in file
php_register_variable   modules/php4/libphp4.a(mod_php4.o)
core_globalsmodules/php4/libphp4.a(mod_php4.o)
sapi_startupmodules/php4/libphp4.a(mod_php4.o)
sapi_shutdown   modules/php4/libphp4.a(mod_php4.o)
zend_ini_rshutdown  modules/php4/libphp4.a(mod_php4.o)
php_module_shutdown_for_execmodules/php4/libphp4.a(mod_php4.o)
apache_php_module_main  modules/php4/libphp4.a(mod_php4.o)
php_request_shutdown_for_exec   modules/php4/libphp4.a(mod_php4.o)
zend_hash_apply modules/php4/libphp4.a(mod_php4.o)
executor_globalsmodules/php4/libphp4.a(mod_php4.o)
zend_hash_destroy   modules/php4/libphp4.a(mod_php4.o)
_estrdupmodules/php4/libphp4.a(mod_php4.o)
zend_error  modules/php4/libphp4.a(mod_php4.o)
sapi_get_default_content_type   modules/php4/libphp4.a(mod_php4.o)
php_module_shutdown_wrapper modules/php4/libphp4.a(mod_php4.o)
sapi_globalsmodules/php4/libphp4.a(mod_php4.o)
zend_startup_module modules/php4/libphp4.a(mod_php4.o)
php_request_shutdownmodules/php4/libphp4.a(mod_php4.o)
php_handle_aborted_connection   modules/php4/libphp4.a(mod_php4.o)
zend_hash_add_or_update modules/php4/libphp4.a(mod_php4.o)
zend_alter_ini_entrymodules/php4/libphp4.a(mod_php4.o)
apache_module_entry modules/php4/libphp4.a(mod_php4.o)
zend_hash_merge_ex 

[PHP-DEV] license question for a module...

[Marc Boeren]

Hi!

I've finished a first version of the dbx module (database abstraction (in
C)) and I want to open-source this module (as a self-contained extension).

What license should I use? I want it to be very open, but maintain a
copyright notice (much like the PHP license).

Or better, can I donate this to the PHP group and get it distributed as part
of PHP (I've seen mentions of selective packaging/downloading, so people
wouldn't  be forced to download it).


Cheerio, Marc.

BTW could I steal and modify the PHP license if necessary??? ;-)

 
  The DBX License, version 0.01
Copyright (c) 2001 Guidance bv. All rights reserved.
 

Redistribution and use in source and binary forms, with or without
modification, is permitted provided that the following conditions
are met:

  1. Redistributions of source code must retain the above copyright
 notice, this list of conditions and the following disclaimer. 
 
  2. Redistributions in binary form must reproduce the above 
 copyright notice, this list of conditions and the following 
 disclaimer in the documentation and/or other materials provided
 with the distribution.
 
  3. The name "DBX" must not be used to endorse or promote products 
 derived from this software without prior permission from 
 Guidance bv.  This does not apply to add-on libraries or tools
 that work in conjunction with DBX.  In such a case the DBX
 name may be used to indicate that the product supports DBX.
 
  4. Guidance bv may publish revised and/or new versions of the
 license from time to time. Each version will be given a
 distinguishing version number.
 Once covered code has been published under a particular version
 of the license, you may always continue to use it under the
 terms of that version. You may also choose to use such covered
 code under the terms of any subsequent version of the license
 published by Guidance bv. No one other than Guidance bv has
 the right to modify the terms applicable to covered code created
 under this License.

  5. Redistributions of any form whatsoever must retain the following
 acknowledgment:
 "This product includes DBX, freely available from
 http://www.guidance.nl/dbx".

  6. The software is an add-on to PHP, which is freely available from 
 http://www.php.net. Be sure to read their license as well.


THIS SOFTWARE IS PROVIDED BY GUIDANCE BV ``AS IS'' AND 
ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A 
PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL GUIDANCE BV
 OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, 
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES 
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR 
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
OF THE POSSIBILITY OF SUCH DAMAGE.

 

Guidance bv can be contacted via Email at [EMAIL PROTECTED]

For more information on Guidance bv and the DBX project, 
please see .

The software is an add-on to the PHP project, whihc consists of 
voluntary contributions made by many individuals on behalf of the 
PHP Group.

The PHP Group can be contacted via Email at [EMAIL PROTECTED]

For more information on the PHP Group and the PHP project, 
please see .


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

[PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found

[andre]

ID: 9337
Updated by: andre
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Feature/Change Request
Assigned To: 
Comments:

maybe a fourth parameter switch to avoid 0->false problems?

Previous Comments:
---

[2001-02-19 11:18:18] [EMAIL PROTECTED]
in_array() currently returns only true/false on whether or not a searched-for value is 
in a given array.

I would like it to return the key of the array's element when value was found, and 
false otherwise. This should not break existing code using in_array().


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9337&edit=2


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

Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found

[Andrei Zmievski]

How about using array_keys($array, $value) to find the key?

On Mon, 19 Feb 2001, [EMAIL PROTECTED] wrote:
> ID: 9337
> Updated by: andre
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Feedback
> Bug Type: Feature/Change Request
> Assigned To: 
> Comments:
> 
> maybe a fourth parameter switch to avoid 0->false problems?
> 
> Previous Comments:
> ---
> 
> [2001-02-19 11:18:18] [EMAIL PROTECTED]
> in_array() currently returns only true/false on whether or not a searched-for value 
>is in a given array.
> 
> I would like it to return the key of the array's element when value was found, and 
>false otherwise. This should not break existing code using in_array().
> 
> 
> ---
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=9337&edit=2
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 



-Andrei

Complexity in the mind is not caused by learning;
learning is caused by complexity in the mind.
 -- Steven Pinker

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

[PHP-DEV] PHP 4.0 Bug #9338: in_array 'strict' parameter is not documented (properly)

[andre]

From: [EMAIL PROTECTED]
Operating system: *
PHP version:  4.0 Latest CVS (19/02/2001)
PHP Bug Type: Documentation problem
Bug description:  in_array 'strict' parameter is not documented (properly)

look at
http://www.php.net/in_array

that documentation should not help anyone understanding what
'strict' does


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



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

Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found

[André Langhorst]

> How about using array_keys($array, $value) to find the key?

obviously it is cheaper to let in_array return it and it is more php 4 
stylish, we have booleans, why not use them?

if ($key=in_array()) do_someting_with_key($key);

is less expensive than

if (in_array()) {
$key=array_keys($array,$value);
do_something_with_key($key); }

-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


-- 
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 #9337 Updated: make in_array return key, if searched value was found

[Andrei Zmievski]

On Mon, 19 Feb 2001, André Langhorst wrote:
> > How about using array_keys($array, $value) to find the key?
> 
> obviously it is cheaper to let in_array return it and it is more php 4 
> stylish, we have booleans, why not use them?
> 
> if ($key=in_array()) do_someting_with_key($key);

So, you suggest putting in 4th parameter? Then someone on php-general
suggested a few months ago to put in another parameter that controls
whether in_array() moves internal pointer or not.. Too many parameters.

-Andrei
* Power corrupts. Atomic power corrupts atomically. *

--
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] Time for 4.0.5?

[André Langhorst]

> I would welcome the win32 distributions packed with bzip2 
> as well. This algorithm is superior to anything else I know 
> (well, at least in compression ratio), and is available to 
> win32 users as well. Not only as a commandline tool, but as 
> a plugin for the very popular wincmd32 too. Anything bzipped 
> is about half the size of that thing zipped.

do not forget that manual downloads, bzip2'ing could help there too

andré

-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


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

[PHP-DEV] PHP 4.0 Bug #9339: infinite loop in wordwrap

[chr]

From: [EMAIL PROTECTED]
Operating system: Linux
PHP version:  4.0.4pl1
PHP Bug Type: Strings related
Bug description:  infinite loop in wordwrap

The following line seems to loop forever:

echo wordwrap("abcdefghijklmnopqr", 10, "\r\n");



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



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

Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found

[Jason Greene]

Some of my thoughts:
1. if you change the return value of in_array to return the key, you can get a false 
error
in your if statement, imagine if in_array found the element in key 0? : )
2. I would say that returning a key is a bit more useful then an option that does not 
reset the  internal pointer or not, though I
can see a use of it

I do agree that having too many parameters is a bad thing, but if this is a concern 
what about making another function?

There seems to be a large desire to see the key of  in_array (see the haystack comment 
in docs)

-Jason


- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "André Langhorst" <[EMAIL PROTECTED]>
Cc: "PHP Development" <[EMAIL PROTECTED]>
Sent: Monday, February 19, 2001 11:36 AM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if 
searched value was found


On Mon, 19 Feb 2001, André Langhorst wrote:
> > How about using array_keys($array, $value) to find the key?
>
> obviously it is cheaper to let in_array return it and it is more php 4
> stylish, we have booleans, why not use them?
>
> if ($key=in_array()) do_someting_with_key($key);

So, you suggest putting in 4th parameter? Then someone on php-general
suggested a few months ago to put in another parameter that controls
whether in_array() moves internal pointer or not.. Too many parameters.

-Andrei
* Power corrupts. Atomic power corrupts atomically. *

--
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 #9337 Updated: make in_array return key, if searched value was found

[Andrei Zmievski]

On Mon, 19 Feb 2001, Jason Greene wrote:
> Some of my thoughts:
> 1. if you change the return value of in_array to return the key, you can get a false 
>error
> in your if statement, imagine if in_array found the element in key 0? : )
> 2. I would say that returning a key is a bit more useful then an option that does 
>not reset the  internal pointer or not, though I
> can see a use of it
> 
> I do agree that having too many parameters is a bad thing, but if this is a concern 
>what about making another function?
> 
> There seems to be a large desire to see the key of  in_array (see the haystack 
>comment in docs)

We can change in_array() to return the the key if it's found, and false
if it's not, but imagine all the scripts it would break..

-Andrei
* The future is not what it used to be. *

-- 
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 #9337 Updated: make in_array return key, if searched value was found

[Jason Greene]

> We can change in_array() to return the the key if it's found, and false
> if it's not, but imagine all the scripts it would break..
about 1/4th of mine : )

Well I think the basic problem is that people are using in_array against its intention.
It is a Boolean function, and that really shouldn't be changed. We could create another
function that is more designed for searching? perhaps array_find? I wouldn't mind 
spending time on this if agreed upon.

-Jason

- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: "André Langhorst" <[EMAIL PROTECTED]>; "PHP Development" <[EMAIL PROTECTED]>
Sent: Monday, February 19, 2001 11:50 AM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if 
searched value was found


> On Mon, 19 Feb 2001, Jason Greene wrote:
> > Some of my thoughts:
> > 1. if you change the return value of in_array to return the key, you can get a 
>false error
> > in your if statement, imagine if in_array found the element in key 0? : )
> > 2. I would say that returning a key is a bit more useful then an option that does 
>not reset the  internal pointer or not, though
I
> > can see a use of it
> >
> > I do agree that having too many parameters is a bad thing, but if this is a 
>concern what about making another function?
> >
> > There seems to be a large desire to see the key of  in_array (see the haystack 
>comment in docs)
>
>
> -Andrei
> * The future is not what it used to be. *
>


-- 
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 #9337 Updated: make in_array return key, if searched value was found

[Andrei Zmievski]

On Mon, 19 Feb 2001, Jason Greene wrote:
> > We can change in_array() to return the the key if it's found, and false
> > if it's not, but imagine all the scripts it would break..
> about 1/4th of mine : )
> 
> Well I think the basic problem is that people are using in_array against its 
>intention.
> It is a Boolean function, and that really shouldn't be changed. We could create 
>another
> function that is more designed for searching? perhaps array_find? I wouldn't mind 
>spending time on this if agreed upon.

Could be done. The way I'd do it is have one php_in_array() C function
that gets parameters passed through from in_array() and array_find() as
well as a flag indicating whether to just return true/false or the
actual key.

-Andrei

"The human brain is a wonderful thing. It starts working the moment you
are born, and never stops until you stand up to speak in public. " -- Sir
George Jessel

-- 
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 #9337 Updated: make in_array return key, if searched value was found

[Jason Greene]

I agree,
That way we don't duplicate code, and we don't have different behavior..
Ill work on this sometime today

-Jason
- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: "André Langhorst" <[EMAIL PROTECTED]>; "PHP Development" <[EMAIL PROTECTED]>
Sent: Monday, February 19, 2001 12:02 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if 
searched value was found


> On Mon, 19 Feb 2001, Jason Greene wrote:
> > > We can change in_array() to return the the key if it's found, and false
> > > if it's not, but imagine all the scripts it would break..
> > about 1/4th of mine : )
> >
> > Well I think the basic problem is that people are using in_array against its 
>intention.
> > It is a Boolean function, and that really shouldn't be changed. We could create 
>another
> > function that is more designed for searching? perhaps array_find? I wouldn't mind 
>spending time on this if agreed upon.
>
> Could be done. The way I'd do it is have one php_in_array() C function
> that gets parameters passed through from in_array() and array_find() as
> well as a flag indicating whether to just return true/false or the
> actual key.
>
> -Andrei
>
> "The human brain is a wonderful thing. It starts working the moment you
> are born, and never stops until you stand up to speak in public. " -- Sir
> George Jessel
>
> --
> 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] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found

[jason]

ID: 9337
Updated by: jason
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Assigned
Bug Type: Feature/Change Request
Assigned To: [EMAIL PROTECTED]
Comments:

Andrei and I descussed the possibility of creating a new function. I will explore 
this.

-Jason

Previous Comments:
---

[2001-02-19 12:18:06] [EMAIL PROTECTED]
maybe a fourth parameter switch to avoid 0->false problems?

---

[2001-02-19 11:18:18] [EMAIL PROTECTED]
in_array() currently returns only true/false on whether or not a searched-for value is 
in a given array.

I would like it to return the key of the array's element when value was found, and 
false otherwise. This should not break existing code using in_array().


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9337&edit=2


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

[PHP-DEV] PHP 4.0 Bug #9340: usleep function doesn't work properly under winNT 4.0

[dror]

From: [EMAIL PROTECTED]
Operating system: winNT 4.0
PHP version:  4.0.4pl1
PHP Bug Type: Unknown/Other Function
Bug description:  usleep function doesn't work properly under winNT 4.0

here is the wrong code (current) + my correction:

 > Wrong (current) <

PHP_FUNCTION(usleep)
{
#if HAVE_USLEEP
pval **num;

if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &num) == FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_long_ex(num);
usleep((*num)->value.lval);
#endif
}

 > Correction <

PHP_FUNCTION(usleep)
{
pval **num;

if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, &num) == FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_long_ex(num);
#if HAVE_USLEEP
usleep((*num)->value.lval);
#elif PHP_WIN32
   Sleep( ((*num)->value.lval+999)/1000);
#endif
}

Dror.


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



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

Re: [PHP-DEV] PHP 4.0 Bug #9337 Updated: make in_array return key, if searched value was found

[André Langhorst]

> Could be done. The way I'd do it is have one php_in_array() C function
> that gets parameters passed through from in_array() and array_find() as
> well as a flag indicating whether to just return true/false or the
> actual key.

what about not touching the internal pointer? there in_array would 
finally get a fourth parameter, not?

andré



-- 
· André Langhorstt: +49 331 5811560 ·
· [EMAIL PROTECTED]  m: +49 173 9558736 ·
* PHP Quality Assurance  http://qa.php.net  *


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

[PHP-DEV] Re: PHP bug #4439: Content-Type prepended to uploaded file data.

[Bret Mogilefsky]

Yes indeedy, I rebuilt with the latest rfc1867.c and all problems with
uploads vanished.  Thanks for your time!

Bret

On Sun, Feb 18, 2001 at 04:15:04PM -0800, Bret Mogilefsky wrote:
> On Mon, Feb 19, 2001 at 12:51:57AM +0100, Ragnar Kjørstad wrote:
> > On Sun, Feb 18, 2001 at 02:53:16PM -0800, Bret Mogilefsky wrote:
> > > Hi... I'm having the same problem you describe in this message:
> > > 
> > > http://www.geocrawler.com/mail/msg.php3?msg_id=4148034&list=5
> > > 
> > > However, the bug appears to be closed in the PHP database and I'm using PHP
> > > 4.04pl1, which is the latest version AFAIK... Do you know if your patch was
> > > incorporated before this version?  Do you have any other information on
> > > this problem?  Your post is the only bit of information I've been able to
> > > find about it at all, and I'm extremely stuck in what I'm doing until I can
> > > figure out how to resolve it...  I'd appreciate any information you have.
> > 
> > The patch was integrated into 4.0.3 (I think), and "solved" our problem. 
> > 
> > In 4.0.4 part of the file-upload code appear to be rewritten, and a
> > simular (but not the same) problem has arisen. Basicly the mime-header
> > parser is crude and ugly code that only handles a subset of the legal
> > header-set. 
> 
> Looking at the CVS tree now, it appears that the last change to rfc1867.c
> in rev 1.59 (changing strrchr to strchr looking for a boundary) might be
> the one that will fix this problem... I'll try applying a patch and see
> what happens.

-- 
Bret Mogilefsky * Mgr. SCEA Developer Support * [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] Licensing Question

[clayton collie]

just for the record, which licenses are compatible with the PHP license ?
There is an extension i'm working on that would be sufficiently useful to
include in the main distribution, it currently uses code derived from an
MPL'ed project. i'd rather not have to rewrite those portions of the code.

  i think there should be something definitive posted about license
compatibilities, especially as the number of extensions increase.

--
_
"Fried Ice-Cream is a reality !" - George Clinton



-- 
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] Pointer to a method

[Llorenç Herrera]

I need to get a pointer to a method, something like:

class SomeClass
{
function foo()
{
echo "HiYa!";
}
}

MyClass = new SomeClass;

Now, the only way to access the function foo is $MyClass->foo(); but I want
to get a pointer to that method wich I could store in an array, something
like:

$Pointer = "MyClass->foo";
And later, execute the method by doing:
$$Pointer();

But this doesn't works ... Why? How can I do this?

___
Llorenç Herrera
www.Hexoplastia.com


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

[PHP-DEV] PHP 4.0 Bug #9277 Updated: Bogus warning with rand(a,b) where a == b

[derick]

ID: 9277
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Math related
Assigned To: 
Comments:

After an e-mail comversation, Jukka made it clear it is useful, so I commit a "fix" to 
the CVS

Previous Comments:
---

[2001-02-15 13:04:38] [EMAIL PROTECTED]
It's not a bug, it's clear that this was supposed not to work. And if you try rand 
(1,1) it wont work either.
Another thing; I don't see why this would be usefull.

---

[2001-02-15 07:43:35] [EMAIL PROTECTED]
$value=rand(0,0);

Gives "Warning: rand(): Invalid range: 0..0 in ..." while there is nothing wrong with 
it. Value shouldn't be invalid.

I'm expecting a value of 0 with probability of 100% without any warnings or is this a 
feature?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9277&edit=2


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

[PHP-DEV] globals.h and notes_globals.h

[Brad Atkins]

Hello,

This is probably a simple questions, but...

In the notes api provided, there's a file called globals.h When another
globals.h exists, how to I make sure it's the notes api file I want? I
don't think specifying a path is the right idea?

Should I rename the file to notes_globals.h in the api? But then
everyone will have to do that.

Suggestions appreciated.

Thanks,
Brad Atkins
Manager, Technical Development

http://www.youreshop.com
1-877-YRE-4YOU (Toll free US & Canada)
1-705-692-3442 (International)



-- 
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] Time for 4.0.5?

[Andi Gutmans]

At 09:31 AM 2/19/2001 +0100, Sascha Schumann wrote:
> Hi,
>
> what do people think about a PHP 4.0.5 release?
>
> We have about 70 change entries in NEWS.  Some of the changes
> are fundamentally needed for some extensions to work
> correctly or to compile at all.
>
> Let me know your thoughts.

Our Launchpad (QA) guys have a few fixes to go into the CVS. I think it 
will be done by the end of the week.
So I think March 1st sounds OK for branching off RC1.

Andi


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

[PHP-DEV] buffered io - sparc solaris

[Alexander Feldman]

Hi,

>From the fopen(3) manual page on Solaris 2.6 (it is the same on Solaris 7 
and Solaris 8):

 When a file is opened with update mode (+ as the  second  or
 third character in the mode argument), both input and output
 may be performed on the associated stream.  However,  output
 must  not be directly followed by input without an interven-
 ing call to fflush(3S) or to  a  file  positioning  function
 (fseek(3S),  fsetpos(3S)  or rewind(3S)), and input must not
 be directly followed by output without an  intervening  call
 to  a  file positioning function, unless the input operation
 encounters end-of-file.

The nasty behaviour remains even if we disable the buffering with call to
setbuf. This imposes a significant compatibility problem with the PHP file
io functions. The decision is to call explicitly fflush() when changing
the direction of the data flow.

I prepared a fix for this (it can be optimized and improved heavily), but
before I commit it I want to hear your opinion. Please see the attachment.

Thank you:
--
Alexander Feldman
Zend Technologies Ltd.
phone: +972 3 6139665 ext. 113, fax: +972 3 6139671
http://www.zend.com


diff -u ext/standard/config.m4 ../php-4.0.4pl1.fix/ext/standard/config.m4
--- ext/standard/config.m4  Wed Jul 19 19:19:40 2000
+++ ../php-4.0.4pl1.fix/ext/standard/config.m4  Mon Feb 19 20:48:43 2001
@@ -3,6 +3,57 @@
 divert(3)dnl
 
 dnl
+dnl Check if flush should be called explicitly after buffered io
+dnl
+AC_DEFUN(AC_FLUSH_IO,[
+  AC_CACHE_CHECK([whether flush should be called explicitly after a bufferered io], 
+ac_cv_flush_io,[
+  AC_TRY_RUN( [
+#include 
+#include 
+
+int main(int argc, char **argv)
+{
+   char *filename = tmpnam(NULL);
+   char buffer[64];
+   int result = 0;
+   
+   FILE *fp = fopen(filename, "wb");
+   if (NULL == fp)
+   return 0;
+   fputs("line 1\n", fp);
+   fputs("line 2\n", fp);
+   fclose(fp);
+   
+   fp = fopen(filename, "rb+");
+   if (NULL == fp)
+   return 0;
+   fgets(buffer, sizeof(buffer), fp);
+   fputs("line 3\n", fp);
+   rewind(fp);
+   fgets(buffer, sizeof(buffer), fp);
+   if (0 != strcmp(buffer, "line 1\n"))
+   result = 1;
+   fgets(buffer, sizeof(buffer), fp);
+   if (0 != strcmp(buffer, "line 3\n"))
+   result = 1;
+   fclose(fp);
+   unlink(filename);
+
+   exit(result);
+}
+],[
+  ac_cv_flush_io="no"
+],[
+  ac_cv_flush_io="yes"
+],[
+  ac_cv_flush_io="no"
+])])
+  if test "$ac_cv_flush_io" = "yes"; then
+AC_DEFINE(HAVE_FLUSHIO, 1, [Define if flush should be called explicitly after a 
+buffered io.])
+  fi
+])
+
+dnl
 dnl Check for crypt() capabilities
 dnl
 AC_DEFUN(AC_CRYPT_CAP,[
@@ -143,6 +194,7 @@
 AC_CHECK_FUNCS(getcwd getwd)
 
 AC_CRYPT_CAP
+AC_FLUSH_IO
 
 divert(5)dnl
 
diff -u ext/standard/file.c ../php-4.0.4pl1.fix/ext/standard/file.c
--- ext/standard/file.c Thu Dec 14 16:34:51 2000
+++ ../php-4.0.4pl1.fix/ext/standard/file.c Mon Feb 19 20:55:59 2001
@@ -882,6 +882,10 @@
efree(buf);
RETVAL_FALSE;
} else {
+#ifdef HAVE_FLUSHIO
+   if (!issock)
+   fflush((FILE*)what);
+#endif
if (PG(magic_quotes_runtime)) {
return_value->value.str.val = 
php_addslashes(buf,0,&return_value->value.str.len,1);
} else {
@@ -926,6 +930,10 @@
efree(buf);
RETVAL_FALSE;
} else {
+#ifdef HAVE_FLUSHIO
+   if (!issock)
+   fflush((FILE*)what);
+#endif
buf[0]=result;
buf[1]='\0';
return_value->value.str.val = buf; 
@@ -1119,6 +1127,9 @@
if (issock){
ret = SOCK_WRITEL((*arg2)->value.str.val,num_bytes,socketd);
} else {
+#ifdef HAVE_FLUSHIO
+   fflush((FILE*)what);
+#endif
ret = fwrite((*arg2)->value.str.val,1,num_bytes,(FILE*)what);
}
RETURN_LONG(ret);
@@ -1731,6 +1742,9 @@
if (!issock) {
return_value->value.str.len = fread(return_value->value.str.val, 1, 
len, (FILE*)what);
return_value->value.str.val[return_value->value.str.len] = 0;
+#ifdef HAVE_FLUSHIO
+   fflush((FILE*)what);
+#endif
} else {
return_value->value.str.len = SOCK_FREAD(return_value->value.str.val, 
len, socketd);
}
--- main/php_config.h.inThu Jan 11 20:39:35 2001
+++ ../php-4.0.4pl1.fix/main/php_config.h.inMon Feb 19 20:56:35 2001
@@ -1547,6 +1547,9 @@
 /* Whether the system supports BlowFish salt */
 #undef PHP_BLOWFISH_CRYPT
 
+/* Define if flush should be called explicitly after a buffered io. */
+#undef HAVE_FLUSHIO
+
 /* Whether to build standard as dynamic

[PHP-DEV] PHP 4.0 Bug #9341: "php -l file.php" seg faults, dumps core

[colin]

From: [EMAIL PROTECTED]
Operating system: RH7.0
PHP version:  4.0 Latest CVS (19/02/2001)
PHP Bug Type: Reproduceable crash
Bug description:  "php -l file.php" seg faults, dumps core

Running the CGI version, if you do a "php -l file.php" (i.e. the "lint" option) on a 
file that has syntax errors, PHP doesn't report anything but segfaults and dumps core.

Backtrace reveals:

#0  destroy_op_array (op_array=0x0) at zend_opcode.c:144
#1  0x8066072 in php_lint_script (file=0xba60) at main.c:1236
#2  0x8064748 in main (argc=3, argv=0xbb04) at cgi_main.c:739
#3  0x4026ab5c in __libc_start_main (main=0x8063fc4 , argc=3, ubp_av=0xbb04, 
init=0x8061b74 <_init>, 
fini=0x810cc3c <_fini>, rtld_fini=0x4000d634 <_dl_fini>, stack_end=0xbafc)
at ../sysdeps/generic/libc-start.c:129

My config line:

./configure \
--with-mysql=/usr/local \
--disable-pear \
--enable-track-vars \
--disable-debug \
--disable-magic-quotes \
--enable-ftp \
--with-gettext \
--with-xml \
--with-dom \
--enable-wddx \
--with-curl \
--with-pgsql \
--with-zlib \
--enable-versioning \
--enable-sockets \
--with-openssl \
--with-snmp \
--with-mcrypt

- Colin



-- 
Edit Bug report at: http://bugs.php.net/?id=9341&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] PHP 4.0 Bug #9265 Updated: passing preg_split a limit parameter of 0 supresses all matches

[andrei]

ID: 9265
Updated by: andrei
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: PCRE related
Assigned To: 
Comments:

As far as I remember, 0 has never meant "no limit" - the value for that is -1. But the 
documentation does need to be updated.

Previous Comments:
---

[2001-02-14 16:33:50] [EMAIL PROTECTED]
Somewhere in the last few weeks, preg_split changed so that specifiying a limit 
parameter of 0 returns the string to be split unchanged. Before that, 0 was seemingly 
treated as no limit, meaning that you could safely specify 0 as the limit argument in 
order to specify a flag as the fourth argument.



will return everything in the same array, whereas if the limit argument is left off 
(or increased), the string gets split up. The behavior allowing 0 to be no limit 
should be returned, or another safe argument for limit that means no limit documented.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9265&edit=2


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

[PHP-DEV] PHP 4.0 Bug #9342: 508 Bad Gateway Error

[bill]

From: [EMAIL PROTECTED]
Operating system: Zeus
PHP version:  4.0.4pl1
PHP Bug Type: Other web server
Bug description:  508 Bad Gateway Error

Hi,

We are running PHP on a Zeus web server with a  Sybase Database. We seem to be 
receiving a lot of 508 Bad Gateway Errors.  It seems like php is dropping connections 
to the database when connecting with Sybase.  I was wondering if their is a solution 
to this problem that I am overseeing.  We have about 75 raw clicks a day and we 
receive about 7000 bad gateway errors a day. I would appreciate any information you 
can give me.  Could the problem be a connection problem with Sybase or is it a problem 
with Zeus?  

The problem has gotten so bad that one of our programmers was forced to write a script 
to refresh the page when a 508 bad gateway error occured.

Thanks in advance 

Bill Cuevas 
CEN
954-563-9008 ext. #243   


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



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

[PHP-DEV] Re: PHP 4.0 Bug #9337 Updated: make in_array return key, if searchedvalue was found

[Sebastian Bergmann]

Bug Database wrote:
> Andrei and I descussed the possibility of creating a new function. 
> I will explore this.

  A new function would be the optimal solution, I think.

-- 
 sebastian bergmann e-mail :  [EMAIL PROTECTED]
  homepage :  http://www.sebastian-bergmann.de
   make a gift : http://wishlist.sebastian-bergmann.de
 measure the usability of your web application -> http://phpOpenTracker.de

-- 
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] imap config.m4 confusion

[Dan Kalowsky]

Hi,

Trying to add a bit of functionality to the imap code, mainly an
imap_set_quota function for PHP to call.

This functionality is already in existence in the c-client library under
the imap4rc1.{c|h} file (function is imap_setquota).  My understanding
though, is to  include the c-client.h file (on FreeBSD in
/usr/local/include/c-client) which in turn includes the mail.h and the
imap4r1.h files.  

So, I changed the php_imap.h file to show: 
From:
#include "mail.h"
#include "rfc822.h"
#include "modules.h"
To:
#include "c-client.h"
#include "rfc822.h"
#include "modules.h"


Altered the ext/imap/config.m4 to select the proper location first with
the following change:

From:
   if test "$PHP_IMAP" != "no"; then  
for i in /usr/local /usr $PHP_IMAP; do
  IMAP_INC_CHK()
  el[]IMAP_INC_CHK(/include)
  el[]IMAP_INC_CHK(/include/imap)
  el[]IMAP_INC_CHK(/include/c-client)
  el[]IMAP_INC_CHK(/imap)
  el[]IMAP_INC_CHK(/c-client)
  fi
done

To:
   if test "$PHP_IMAP" != "no"; then  
for i in /usr/local /usr $PHP_IMAP; do
  IMAP_INC_CHK()
  el[]IMAP_INC_CHK(/include/c-client)
  el[]IMAP_INC_CHK(/include)
  el[]IMAP_INC_CHK(/include/imap)
  el[]IMAP_INC_CHK(/imap)
  el[]IMAP_INC_CHK(/c-client)
  fi
done

rebuilt my configure script, and went to recompile.  Ran into this
error..

gcc -I. -I/home/kalowsky/php/php4/main -I/home/kalowsky/php/php4/main
-I/home/kalowsky/php/php4 -I/usr/local/include/apache
-I/home/kalowsky/php/php4/Zend -I/usr/local/include
-I/usr/local/include/c-client
-I/home/kalowsky/php/php4/ext/xml/expat/xmltok
-I/home/kalowsky/php/php4/ext/xml/expat/xmlparse
-I/home/kalowsky/php/php4/TSRM -DHARD_SERVER_LIMIT=512
-DDOCUMENT_LOCATION=/usr/local/www/data/
-DDEFAULT_PATH=/bin:/usr/bin:/usr/local/bin -DUSE_EXPAT
-DXML_BYTE_ORDER=12 -g -Wall -c internal_functions.c  -fPIC -DPIC -o
internal_functions.lo
In file included from /home/kalowsky/php/php4/ext/imap/php_imap.h:10,
 from internal_functions.c:33:
/usr/local/include/rfc822.h:87: redefinition of `soutr_t'
/usr/local/include/c-client/rfc822.h:72: `soutr_t' previously declared
here
/usr/local/include/rfc822.h:89: redefinition of `rfc822out_t'
/usr/local/include/c-client/rfc822.h:74: `rfc822out_t' previously
declared here
*** Error code 1

Stop in /home/kalowsky/php/php4/main.
*** Error code 1

Stop in /home/kalowsky/php/php4/main.
*** Error code 1


Any suggestions to correct this?  Or a better way to handle this?  

--
Dan Kalowsky  "Tonight I think I'll walk alone, 
Worldgate Communications   I'll find my soul as I go home."
Software Engineer - TICS Group  - Temptation

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

[PHP-DEV] PHP 4.0 Bug #9343: Causes server to core

[brian]

From: [EMAIL PROTECTED]
Operating system: linux/solaris (been tested with both)
PHP version:  4.0.4pl1
PHP Bug Type: Apache related
Bug description:  Causes server to core

Here is the problem. When PHP is installed with mod_perl, certain calls in mod_perl 
will cause the server to core (and this only happens with PHP, jserv, mod_roaming... 
the rest all work). You can simulate the behavior with Apache::Storage. For some 
reason, when mod_perl goes to access the module's config list inside of Apache, Apache 
cores. This was fixed a while ago and the fix was mentioned on slashdot. The problem 
seems to have returned though.


-- 
Edit Bug report at: http://bugs.php.net/?id=9343&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] PHP 4.0 Bug #9344: Causes server to core

[brian]

From: [EMAIL PROTECTED]
Operating system: linux/solaris (been tested with both)
PHP version:  4.0.4pl1
PHP Bug Type: Apache related
Bug description:  Causes server to core

Here is the problem. When PHP is installed with mod_perl, certain calls in mod_perl 
will cause the server to core (and this only happens with PHP, jserv, mod_roaming... 
the rest all work). You can simulate the behavior with Apache::Storage. For some 
reason, when mod_perl goes to access the module's config list inside of Apache, Apache 
cores. This was fixed a while ago and the fix was mentioned on slashdot. The problem 
seems to have returned though.


-- 
Edit Bug report at: http://bugs.php.net/?id=9344&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] PHP 4.0 Bug #9344 Updated: Causes server to core

[derick]

ID: 9344
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Apache related
Assigned To: 
Comments:

submitted twice

Previous Comments:
---

[2001-02-19 16:12:44] [EMAIL PROTECTED]
Here is the problem. When PHP is installed with mod_perl, certain calls in mod_perl 
will cause the server to core (and this only happens with PHP, jserv, mod_roaming... 
the rest all work). You can simulate the behavior with Apache::Storage. For some 
reason, when mod_perl goes to access the module's config list inside of Apache, Apache 
cores. This was fixed a while ago and the fix was mentioned on slashdot. The problem 
seems to have returned though.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9344&edit=2


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

[PHP-DEV] PHP 4.0 Bug #9345: PHP as subrequests in Apache

[brian]

From: [EMAIL PROTECTED]
Operating system: doens\'t matter
PHP version:  4.0.4pl1
PHP Bug Type: Apache related
Bug description:  PHP as subrequests in Apache

Here is the problem, if you make a call to ap_run_sub_req() with a PHP script with a 
GET method and content length set to zero, PHP will still gobble up whatever is 
sitting in the socket. This problematic when you don't want PHP to be the script to 
answer the POST request. I have tried dinking with a number of things (like remaining, 
length) and such that make up the request_rec, but PHP seems to be ignoring all of 
them.




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

[am]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.4pl1
PHP Bug Type: Feature/Change Request
Bug description:  

allah  belanýzý versin.


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

[derick]

ID: 9346
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Feature/Change Request
Assigned To: 
Comments:



Previous Comments:
---

[2001-02-19 17:09:32] [EMAIL PROTECTED]
allah  belanýzý versin.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9346&edit=2


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

[PHP-DEV] PHP 4.0 Bug #9347: php_read does not handle O_NONBLOCK correctly

[tem]

From: [EMAIL PROTECTED]
Operating system: linux (mandrake 7.2)
PHP version:  4.0 Latest CVS (19/02/2001)
PHP Bug Type: Sockets related
Bug description:  php_read does not handle O_NONBLOCK correctly

The php_read function does not seem to handle non-blocking sockets correctly.  The 
read function will return a negative value when EAGAIN (no data available when in 
nonblocking mode) error occurs. (from the man page:
On error, -1 is returned, and errno is set  appropriately.)  Here is my quick n' dirty 
patch:

--- ext/sockets/mysocket.c  Mon Feb 19 16:53:20 2001
+++ ext/sockets/sockets.c   Mon Feb 19 16:52:42 2001
@@ -635,7 +635,7 @@
   if (m > 0) {
t++;
n++;
-  } else if (m <= 0) {
+  } else if (m == 0) {
no_read++;
   if (nonblock && no_read >= 2) {
return n; /* The first pass, m always is 0, so no_read becomes 
1


enjoy.

-tem



-- 
Edit Bug report at: http://bugs.php.net/?id=9347&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] PHP 4.0 Bug #8958 Updated: File uploads append Content-Type string

[lyric]

ID: 8958
Updated by: lyric
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Duplicate
Bug Type: Unknown/Other Function
Assigned To: 
Comments:

Duplicate of http://bugs.php.net/bugs.php?id=9298 which is fixed in CVS.

Previous Comments:
---

[2001-02-04 12:40:04] [EMAIL PROTECTED]
I can not reproduce this with latest CVS. 
Please try latest CVS snapshot from http://snaps.php.net/

--Jani


---

[2001-01-28 15:29:53] [EMAIL PROTECTED]

Being that it happens to every file uploaded, I don't know how helpful this will be 
but..

$file = $HTTP_POST_FILES['file']['tmp_name'];
$file_name = $HTTP_POST_FILES['file']['name'];
@mkdir("../Images/new/$owner",0775);
copy($file,"../Images/new/$owner/$file_name");

Now, the file created has the Content-type: xxx/x  plus an additional blank line 
at the top of the file.

---

[2001-01-27 20:50:26] [EMAIL PROTECTED]
Please provide a short snippet of code that
reproduces this effect. 

---

[2001-01-27 18:20:35] [EMAIL PROTECTED]

Doing file uploads with php 4.0.4pl1 on RH7 (RedHat RPMs) appends the Content-Type: 
/x  line to the top of the files.

-- Medvitz



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8958&edit=2


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

[PHP-DEV] PHP 4.0 Bug #8940 Updated: File uploads stopped withing in 4.0.4pl1

[lyric]

ID: 8940
Updated by: lyric
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Duplicate
Old-Bug Type: Filesystem function related
Bug Type: Unknown/Other Function
Assigned To: 
Comments:

Duplicate of http://bugs.php.net/bugs.php?id=9298 which is fixed in CVS.

Previous Comments:
---

[2001-02-04 12:41:07] [EMAIL PROTECTED]
I can not reproduce this with latest CVS. 
Please try the latest CVS snapshot from http://snaps.php.net/

--Jani



---

[2001-01-26 16:07:33] [EMAIL PROTECTED]
If you view the uploaded file (using "od" in my case), you'll see that 
the first few bytes of it are:

"Content-Type: image/jpeg" followed by the binary data that makes 
up the JPEG file. Since the uploaded file is exactly the same size as 
the original, I presume that the last few bytes are dropped out.

---

[2001-01-26 12:50:56] [EMAIL PROTECTED]
Further testing reveals that the upload is working properly, but the 
file 'type' variable is not set, and PHP is not treating it as an image 
file. Image processing utilities state that the file is corrupt after 
uploading, even though it remains the exact same size as the 
original. I suspect that PHP is doing something to the file.

---

[2001-01-26 12:01:45] [EMAIL PROTECTED]
Ok, I've done some further testing. With a simple script that does 
nothing except upload the file and move it, it works: the file is 
there. However, the "type" variable has no value! No matter what 
type of file I upload, the $HTTP_POST_FILES['userfile']['type'] value 
is an empty string.

---

[2001-01-26 11:21:21] [EMAIL PROTECTED]
I've been using 4.0.3 for a couple of weeks now. Last night I ran the 
Redhat Update agent and installed 4.0.4pl1. Everything works fine 
except for file uploads. The upload is recorded as successful, 
everything SEEMS to work fine, but there is no file in /tmp, and the 
variable $HTTP_POST_FILES['userfile']['type'] is undefined. Apache 
1.3.14 reports no problems, and returns a 200 return code. I've 
tried working with php.ini; I can turn file uploads off, and that 
works, then when I turn it back on again, it has the same problem. 
I'm pretty sure it's something in 4.0.4pl1 because nothing else on 
my system has changed since the upgrade last night. Here's some of 
my code:

$file_type = $HTTP_POST_FILES['userfile']['type'];
if (substr($file_type,-4,4) != 'jpeg') {
die( "Files of type '" . $file_type .
 "' are not recognized." .
 "Only JPEG images are currently supported." 
);
}

$path_for_file = 'gallery/' . $user_id . '/' . $photo_id . 
'.jpg';
if 
(!is_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name']))
die( "File is not uploaded." ); 
move_uploaded_file($HTTP_POST_FILES['userfile']['tmp_name'], 
$path_for_file);

...but I really don't think the problem is in the code. Here's some 
output from my Apache log file:

192.168.1.2 - - [26/Jan/2001:08:13:04 -0800] "POST /upload.php 
HTTP/1.1" 200 51
"http:///upload.php" "Mozilla/4.0 (compatible; MSIE 5.0; 
Mac_PowerPC)
"

No errors are reported any where.



---

The remainder of the comments for this report are too long.  To view the rest of the 
comments, please view the bug report online.


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8940&edit=2


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

[PHP-DEV] PHP 4.0 Bug #9347 Updated: php_read does not handle O_NONBLOCK correctly

[tem]

ID: 9347
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Sockets related
Description: php_read does not handle O_NONBLOCK correctly

err did the patch backwards.

--- ext/sockets/sockets.c   Mon Feb 19 16:52:42 2001
+++ ext/sockets/mysocket.c  Mon Feb 19 16:53:20 2001
@@ -635,7 +635,7 @@
   if (m > 0) {
t++;
n++;
-  } else if (m == 0) {
+  } else if (m <= 0) {
no_read++;
   if (nonblock && no_read >= 2) {
return n; /* The first pass, m always is 0, so no_read becomes 
1 

Previous Comments:
---

[2001-02-19 17:11:44] [EMAIL PROTECTED]
The php_read function does not seem to handle non-blocking sockets correctly.  The 
read function will return a negative value when EAGAIN (no data available when in 
nonblocking mode) error occurs. (from the man page:
On error, -1 is returned, and errno is set  appropriately.)  Here is my quick n' dirty 
patch:

--- ext/sockets/mysocket.c  Mon Feb 19 16:53:20 2001
+++ ext/sockets/sockets.c   Mon Feb 19 16:52:42 2001
@@ -635,7 +635,7 @@
   if (m > 0) {
t++;
n++;
-  } else if (m <= 0) {
+  } else if (m == 0) {
no_read++;
   if (nonblock && no_read >= 2) {
return n; /* The first pass, m always is 0, so no_read becomes 
1


enjoy.

-tem


---


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


-- 
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] crash cause ... ?

[phobo]

Hi,

I have test environment with PHP 403sp1 (CGI) running on Apache 1.3.14 on a
low end (133mhz, 32mb RAM) Pentium with Windows 98. For some reason the
whole set up seems very unstable, and PHP causes general protection faults
consistantly with my scripts which work well on a Windows 2000 machine with
the same Apache/PHP setup.

On the failing Win98 machine, nothing is logged by Apache, and all I get on
the browser window is Internal Server Error. Simple scripts work fine - it
seems to me that the machine is getting clogged and can't handle more than
1-2 hits simutanouesly, although it would be nice to know if this is truely
the case.

How can I see what the problem is? Is there some method of turning a higher
level of logging on, in Apache or PHP etc?

Siggy


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

[PHP-DEV] PHP 4.0 Bug #9348: symbol zendtext: referenced symbol not found

[tcyrus]

From: [EMAIL PROTECTED]
Operating system: Solaris 2.6
PHP version:  4.0 Latest CVS (19/02/2001)
PHP Bug Type: Apache related
Bug description:  symbol zendtext: referenced symbol not found

Like other bugs filed on this same subject, when running Apache (1.3.17) on a
Solaris 2.6 sparc (gcc 2.95.2) using the latest src (Feb 19, 2001 1545) from 
http://snaps.php.net I continue to get the error:

/usr/local/apache/bin/apachectl configtest
Syntax error on line 238 of /usr/local/apache/conf/httpd.conf:
Cannot load /usr/local/apache/libexec/libphp4.so into server: ld.so.1: 
/usr/local/apache/bin/httpd: fatal: relocation error: file 
/usr/local/apache/libexec/libphp4.so: symbol zendtext: referenced symbol not found

Configured like:
./configure --with-mysql --with-apxs=/usr/local/apache/bin/apxs --enable-track-vars

Like other bug reports, I see several 'extern char *zendtext' but no place do I see
where zendtext is defined (in any of the php4-latest src).

Help!


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

[CVS Account Request]

Full name: Lucas Rocha
Email: [EMAIL PROTECTED]
ID: lucasr
Purpose: Contribute with the english-to- portuguese translation of the PHP Manual

-- 
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 #9177 Updated: crypt problems with openssl

[Boian Bonev]

> > Well, I think it's just the link order of libraries. ie. the
> > openssl lib should be before libc..but is that even possible?
> > Or just add another entry for libc after ssl?
> Might be possible to do some kludge with the link order, I would prefer
> that OpenSSL changed a bit though, I'll probably have to go nag them
> again. OpenLDAP needs this to be fixed as well, and I'm sure there are
> other programs with the same problem.

it will not be possible for libc. i have solved similar problem with two
conflicting libs thus:

gcc -o something -l lib-i-want-to-discard-conflicting-foo
...path/lib-with-preffered-conflicting-foo.so[mething] 

gnu ld looks in objects tagged for linkage and then in libraries. afaik libc
is the last place ld will process and there is no chance to fool it.

the best solution is to fix openssl.

b.


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

[PHP-DEV] PHP 4.0 Bug #7557 Updated: Array stored in session loose content

[andre]

ID: 7557
Updated by: andre
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Session related
Assigned To: 
Comments:

this is rather a confusion how references work than a bug
if you had var_dump()ed your $session you would have seen
that session handling cannot be involved here

what you are doing is
a) creating a reference $item to an $item in cart1
b) and then storing the whole cart2 therein 

chaning (b) to $item = &$this->cart2; works for me


Function test() {
  for($i=0; $icart1); $i++) {
$item = &$this->cart1[$i]; // (a)
$item->pid .= "a";
  }

  $item = $this->cart2; // (b)
  for($i=0; $ipid .= "a";
  }
}


Previous Comments:
---

[2000-12-02 13:23:23] [EMAIL PROTECTED]
Stage 1:
===

Ok, this version works with 4.0.4dev-200012020345.  But it was an excerpt from my 
code.

Stage 2:
===

Now i have extended the example and got the same error again :-(
Please have a look at the code below:

pid = "".time();
  array_push($this->cart1, $item);
  array_push($this->cart2, $item);
}

Function test() {
  for($i=0; $icart1); $i++) {
$item = &$this->cart1[$i];
$item->pid .= "a";
  }

  $item = $this->cart2;
  for($i=0; $ipid .= "a";
  }
}

Function show() {
  echo("ITEMS:");
  $i = 0;
  while ($i < MAX(count($this->cart1),count($this->cart2))) {

$item = &$this->cart1[$i];
$item->id += 1;
echo("".$item->pid." :".$item->id."");

$item = &$this->cart2;
$item[$i]->id += 1;
echo("".$item[$i]->pid." :".$item[$i]->id."");

$i++;
  }
  echo("");
}
  }
  session_start();

  if (!$session) {
$session = new C_SESSION();
session_register("session");
  } else {
$session->test();
$session->update();
  }

  echo "SESSION-ID: ".session_id()."";

  $session->show();
?>

Have a look at the new test function. The line '$item = $this->cart2;' was first a 
mistake (it works on a copy and therefore doe not append the 'a' to the pid of other 
version). If this line is in there the same old problem is back again.

The output looks like this:

   SESSION-ID: f0cf1206f566d170bf6fde86a5f76035
   ITEMS:

   :975780490 :7
   :975780490 :6
   :975780491 :5
   :975780491 :4
   :975780491 :3
   :975780491 :2
   975780492 :1 975780492 :1


BUT:
If you rename $item with $cart all is ok.
If you replace '$item = $this->cart2;' with '$item = &$this->cart2;' all is ok.


Stage 3:
===
I tried a third version with a inc and dec function in the C_CART_ITEM class wich 
increased and decreases $id and i called the dec and the inc function in 
C_SESSION->test and i got this error:

Fatal error: Call to a member function on a non-object in ... 

Ouch!


---

[2000-11-27 08:52:26] [EMAIL PROTECTED]
Should be fixed in CVS. Please try latest snapshot from
http://snaps.php.net/ and reopen this bug report if
this doesn't work with it.

--Jani

---

[2000-11-03 19:32:58] [EMAIL PROTECTED]
works for me (4.0.4dev), please try 4.0.4 as far as it is
out and report results

---

[2000-11-02 03:09:55] [EMAIL PROTECTED]
Every call to the update function in the session class appends a new C_CART_ITEM with 
the actual time to the cart1 and cart2 arrays.

If you reload the page several times, you get the following:


   SESSION-ID: 970efca9d3effdadf14e679d0e88b349
   ITEMS:

   973150040 : 1 973150036 : 8
   : 1   973150038 : 7
   : 1   973150039 : 6
   : 1   973150039 : 5
   : 1   973150039 : 4
   : 1   973150040 : 3
   : 1   973150040 : 2
   : 1   973150040 : 1


The left two rows show the content of cart1 and the right 2 rows the content of cart2. 
Both arrays should have the same content.

cart1 is referenced by item in the show function. And when this is done, this entry is 
not available in the next page (after reload etc.).

cart2 is referenced as the whole array - this works.

This bug occurs with PHP versions > 4.0.3 (4.0.2 not tested).
It works fine with version 4.0.1pl1 .


---

[2000-10-31 18:00:18] [EMAIL PROTECTED]
pid = "".time();
  array_push($this->cart1, $item);
  array_push($this->cart2, $item);
}

Function show() {
  echo("ITEMS:");
  $i = 0;
  while ($i < MAX(count($this->cart1),count($this->cart2))) {

$item = &$this->ca