Re: [PHP-DEV] mailparse extension

[Wez Furlong]

On 2001-05-04 06:07:14, "Chuck Hagenbuch" <[EMAIL PROTECTED]> wrote:
> Quoting Wez Furlong <[EMAIL PROTECTED]>:
> 
> > I would like to put my mailparse ("As seen on zend.com weekly
summary")
> > extension into CVS; shall I just check it into php4/ext?
> 
> I'd certainly be interested in it. Are there any external library
> dependancies?

No, which is part of the reason there is "so much" code compared to most
other extensions.

--Wez.


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

[PHP-DEV] Bug #10657: settype() with larger than 32bit values

[tf]

From: [EMAIL PROTECTED]
Operating system: linux
PHP version:  4.0.4
PHP Bug Type: Feature/Change Request
Bug description:  settype() with larger than 32bit values

if i use settype($foo, "integer") with an value for $foo
alike '112' 
settype() returns successfull type setting and changes the 
value to something like that '2147483647'

could it be possible that settype produces a warning, if 
an value larger that the supported bitvalue of the current 
system is and/or changes the value to 0 alike settype() on 
a striong like this 'fjsfjsdh'...



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

[Chuck Hagenbuch]

Quoting Wez Furlong <[EMAIL PROTECTED]>:

> I would like to put my mailparse ("As seen on zend.com weekly summary")
> extension into CVS; shall I just check it into php4/ext?

I'd certainly be interested in it. Are there any external library
dependancies?

-chuck

--
Hockey means never having to say you're sorry.

-- 
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] Installing PHP in PWS 4.0

[Piepin]

Halo...

I have problem:
My PHP is not working in my PWS 4.0
Can somebody tell me how to configure it?

Regards,
Piepin

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

[PHP-DEV] Bug #10656: shmop_open permissions incorrect for writing

[phpdev]

From: [EMAIL PROTECTED]
IP Address:   203.48.38.170
Operating system: FreeBSD 4.3 (i386)
PHP version:  4.0.5
PHP Bug Type: Unknown/Other Function
Bug description:  shmop_open permissions incorrect for writing

Basically, the shmop_open function does not allow for writing to shared memory if 
pre-allocated memory is opened using the ACCESS (rather than CREATE) mode. This was 
found when using the shmop functions for fast interprocess communication between a 
number of php cgi scripts. The solution to this bug was to create another mode, WRITE 
(w) that uses IPC_R & IPC_W shm flags.

To reproduce the problem:-

# ** BEFORE fix modifications are made **
# ** change to php cgi directory and run server command (C) in one telnet session then 
run client command (A) in another. Client cannot write!
echo '' | ./php -q &
echo '' | ./php -q

# ** shmop_open in ACCESS mode does not allow writing to shared memory!
# ** So, I created a WRITE ("w") mode to allow writing and left ACCESS ("a") mode as 
read_only.

# ** AFTER fix modifications are made **
# ** change to php cgi directory and run server command (C) in one telnet session then 
run new client command (W) in another. Client can now write.
echo '' | ./php -q &
echo '' | ./php -q

# ** Modifications required for bug fix, include changing ext/shmop.c

Existing /ext/shmop.c [shmop_open()]:

/* {{{ proto int shmop_open (int key, int flags, int mode, int size)
   gets and attaches a shared memory segment */
PHP_FUNCTION(shmop_open)
{
...
if (memchr((*flags)->value.str.val, 'a', (*flags)->value.str.len)) {
shmflg = SHM_RDONLY;
shmop->shmflg |= IPC_EXCL;
}
else if (memchr((*flags)->value.str.val, 'c', 
(*flags)->value.str.len)) {
shmop->shmflg |= IPC_CREAT;
shmop->size = (*size)->value.lval;
}
else {
php_error(E_WARNING, "shmopen: access mode invalid");
efree(shmop);
RETURN_FALSE;
}

shmop->shmid = shmget(shmop->key, shmop->size, shmop->shmflg);
if (shmop->shmid == -1) {
php_error(E_WARNING, "shmopen: can't get the block");
efree(shmop);
RETURN_FALSE;
}
...
}
/* }}} */

Corrected /ext/shmop.c [shmop_open()]:

/* {{{ proto int shmop_open (int key, int flags, int mode, int size)
   gets and attaches a shared memory segment */
PHP_FUNCTION(shmop_open)
{
...
if (memchr((*flags)->value.str.val, 'a', (*flags)->value.str.len)) {
shmflg = SHM_RDONLY;
shmop->shmflg |= IPC_EXCL;
}
else if (memchr((*flags)->value.str.val, 'c', 
(*flags)->value.str.len)) {
shmop->shmflg |= IPC_CREAT;
shmop->size = (*size)->value.lval;
}
else if (memchr((*flags)->value.str.val, 'w', 
(*flags)->value.str.len)) {
shmop->shmflg |= IPC_R;
shmop->shmflg |= IPC_EXCL;
shmop->shmflg |= IPC_W;
}
else {
php_error(E_WARNING, "shmopen: access mode invalid");
efree(shmop);
RETURN_FALSE;
}
...
}
/* }}} */

# * Configuration lines for php_4.0.5.tar.gz compiling
./configure "--enable-memory-limit=yes" "--enable-sockets" "--with-openssl" 
"--enable-shmop" "--enable-debug=no" "--enable-xml" "--enable-ftp" 
"--with-config-file-path=/etc" "--with-mysql=/usr/local/" 
"--with-sybase=/usr/local/freetds/" "--enable-dba=yes" "--with-gdbm=/usr/local/" 
"--with-mhash=/usr/local/" "--with-curl=/usr/local/" "--with-zlib=/usr/local/" 
"--with-gd=/usr/local/"
# Search/replace required for freetds implementation
perl -pi -e 's/dbopen/tdsdbopen/g; s/(DBSETLCHARSET)/\/\/$1/g;' 
ext/sybase/php_sybase_db.c

# * PHP.ini not considered relevant to this bug report.



-- 
Edit Bug report at: http://bugs.php.net/?id=10656&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: Bug #8625 Updated: can not use imap_open to authenticate witha pop3 server

[CheongMeng]

it only doesn't work with BSDI4.1
4.2 has no prob , :)

On 3 May 2001, Bug Database wrote:

> Date: 3 May 2001 19:25:44 -
> From: Bug Database <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Bug #8625 Updated: can not use imap_open to authenticate with a
> pop3 server
> 
> ID: 8625
> Updated by: chagenbu
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Feedback
> Bug Type: IMAP related
> PHP Version: 4.0.3pl1
> Assigned To: 
> Comments:
> 
> Does it work if you specify a port number explicitly?
> 
> Previous Comments:
> ---
> 
> [2001-01-10 03:09:01] [EMAIL PROTECTED]
> Below is how I call the imap_open function. It works in linux but not BSDI 4.1. 
>Please help.
> 
> $this->mbox = imap_open("{" . $this->hostname . "/" . $this->protocol . "}
> ", $this->username, $this->password);
> 
> 
> list of module:
> './configure' '--with-apache=../apache_1.3.12' '--with-mysql' '--with-imap' 
>'--enable-track-vars'
> 
> 
> 
> ---
> 
> 
> 
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at http://bugs.php.net/?id=8625&edit=2
> 

Cheers, 
CM


-- 
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 #10655 Updated: make fails with apache "Undefined simbol isinf"

[grisha]

ID: 10655
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Compile Problem
Description: make fails with apache "Undefined simbol isinf"



Previous Comments:
---

[2001-05-03 20:46:08] [EMAIL PROTECTED]
php configured:
./configure --with-apache=/export/home/grisha/apache/apache_1.3.19 --enable-sockets 
--with-domxml=/usr/local/lib --with-sablot=/usr/local/lib --with-xml 
--enable-sablot-errors-descriptive
make and make install succesfull
apache configured:
./configure --activate-module=src/modules/php4/libphp4.a

then make in apache_1.3.19 fails with the message:

am  -ldl -lexpat -lsablot -lresolv -lresolv -lm -ldl -lcrypt -lnsl -lsocket  -lsocket 
-lgcc   -lsocket -lnsl

Undefined   first referenced
 symbol in file
isinf   modules/php4/libphp4.a(formatted_print.o)
ld: fatal: Symbol referencing errors. No output written to httpd
collect2: ld returned 1 exit status
make[2]: *** [target_static] Error 1
make[2]: Leaving directory `/export/home/grisha/apache/apache_1.3.19/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/export/home/grisha/apache/apache_1.3.19'
make: *** [build] Error 2


---


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


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

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[John Donagher]

We use a Java-style methodology of naming classes as well as filenames,
something we've adopted largely because of our use of PHPDoc. So, if you have a
class FooBar, that class is defined in FooBar.cls, not foobar.cls. If
get_class() returned the as-declared name, we'd have a really easy way to know
where that class was defined.

When you start getting into complex inheritance and class dependency trees,
this issue finally rears its head. Other than this case, I have never cared.
So, I've had to create a code generator to build a structure containing a
mapping of class declaration names pointing back to filenames, which otherwise
could not be accurately programatically determined. But if you use lowercased
class naming, you can programatically determine the filename. That seems wrong
to me.

We (at my current company) have a clean architecture, something we're working
on incorporating into a currently existing open-source application framework
project to allow other people to use. So yes, three users may be affected by it
now (maybe less :). I really don't want to propogate the kludge I've had to
write out to hundreds of people, though.

Don't change the code because of me, or because of the project I'm working on,
or because of the way PHPDoc works. We've already worked around it.  But I
still maintain that tossing away the declared names is not the only (or the
best) way to achieve case-insensitivity in the language. Believe me, I wouldn't
have wasted cycles thinking/writing about this if I wasn't convinced it will
benefit PHP and its users in the long run, even if the value add is relatively
minor.


On Thu, 3 May 2001, Andrei Zmievski wrote:

> At 02:50 AM 5/4/01 +0300, Andi Gutmans wrote:
> >I still don't think this is something lots of PHP users will benefit from. 
> >On the contrary, I think semantically it is more correct to define what 
> >the case insensitivity means (names are converted to lower case).
> >How many examples can you think of where this would actually help a PHP 
> >developer?
> 
> Purely cosmetically, it would be nice. For example, in PHP-GTK I have a lot 
> of error messages that output class names, and it'd be nice to display the 
> names as they were registered by the user/system rather than all lowercased.
> 
> -Andrei
> 
> 

-- 

John Donagher
Application Engineer
Intacct Corp. - Powerful Accounting on the Web
408-395-0989
720 University Ave.
Los Gatos CA 95032
www.intacct.com

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD


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

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV]Release process

[David Croft]

In my humble opinion 'null'  is a 'pseudovalue' that has been made
available for some time. If it was never intended for a script to be able
to use it, it should never have been exposed. But it has been and many
people, myself included, are using it.

It is particularly useful to mark a value that has not yet been filled.
The same way NULL is used in SQL. If you take out this behaviour there is
no 'pseudo-value' to indicate the absence of value and we will go back to
using 0 or constants, a hack at best.

Also, I see a distinction semantically between isset and key_exists. Isset
asks whether it is set to a tangible value. Key_exists asks whether the
array contains an entry, any entry, for that key.

My 2 cents,
David

-- 
|> /+\ \| | |>

David Croft
Infotrek
On Thu, 3 May 2001, Zeev Suraski wrote:

> At 17:20 3/5/2001, Cynic wrote:
> >I very much agree with Andrei on this. Please, keep the
> >existing functionality.
> >
> >Although, I'm not familiar with any issues possibly connected
> >with this. Does it hurt anything?
>
> Yes, it requires adding of functions that duplicate isset()'s behavior in a
> way that may change in the future (implementation dependent).
>
> Zeev
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

[PHP-DEV] Bug #10655: make fails with apache "Undefined simbol isinf"

[grisha]

From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version:  4.0.5
PHP Bug Type: Compile Problem
Bug description:  make fails with apache "Undefined simbol isinf"

php configured:
./configure --with-apache=/export/home/grisha/apache/apache_1.3.19 --enable-sockets 
--with-domxml=/usr/local/lib --with-sablot=/usr/local/lib --with-xml 
--enable-sablot-errors-descriptive
make and make install succesfull
apache configured:
./configure --activate-module=src/modules/php4/libphp4.a

then make in apache_1.3.19 fails with the message:

am  -ldl -lexpat -lsablot -lresolv -lresolv -lm -ldl -lcrypt -lnsl -lsocket  -lsocket 
-lgcc   -lsocket -lnsl

Undefined   first referenced
 symbol in file
isinf   modules/php4/libphp4.a(formatted_print.o)
ld: fatal: Symbol referencing errors. No output written to httpd
collect2: ld returned 1 exit status
make[2]: *** [target_static] Error 1
make[2]: Leaving directory `/export/home/grisha/apache/apache_1.3.19/src'
make[1]: *** [build-std] Error 2
make[1]: Leaving directory `/export/home/grisha/apache/apache_1.3.19'
make: *** [build] Error 2



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



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

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV]Release process

[David Croft]

On Thu, 3 May 2001, Andi Gutmans wrote:

> At 08:53 AM 5/3/2001 -0500, Andrei Zmievski wrote:
> >Um, but some db extensions return NULL values as part of the array, so
> >if column 'foo' is NULL in the db, you'd want the result array to have
> >NULL under key 'foo' - it just won't do to have that column be missing.
>
> Yeah but you can use === NULL for those.
> You might be right but I remember we decided it's problematic.

With all due respect Andi, you can't. There is a difference between a
field being null and that field not existing at all that neither isset,
empty nor === will detect.

david@papaya:~$ php


Out of the four, only key_exists makes the distinction.

I know you had mentioned a problem with Zend not being able to unset
certain fields and instead setting them to null. May I suggest instead
that be attended to - if nothing else, by adding a new 'does not exist'
marker to the bucket that the zend_hash_ functions will recognize.

In the meantime a very large note can be added to the documentation if you
are able to determine exactly what circumstances cause this behaviour.

Cheers,

David

-- 
|> /+\ \| | |>

David Croft
Infotrek



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

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

[Andi Gutmans]

At 07:16 PM 5/3/2001 -0500, Andrei Zmievski wrote:
>At 03:14 AM 5/4/01 +0300, Andi Gutmans wrote:
>>Not exactly. No matter if it is set to NULL or unset then isset() will 
>>give the same result.
>>And most people use isset() AFAIK.
>
>Whatever the current situation, there needs to be a way to check whether a 
>certain array entry is NULL or not.

If so then we need to make sure that modules like the MySQL module still 
continue to behave exactly like they used to with isset() and other ways 
programmers were working.
I'm not saying you're wrong. It's probably a good idea but we need to think 
about the consequences and other changes we might need to make at the same 
time before breaking stuff.
We should probably save all of the NULL stuff for 4.1.x. If we do it the 
right way we might end up breaking certain scripts.

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]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

[Andrei Zmievski]

At 03:14 AM 5/4/01 +0300, Andi Gutmans wrote:
>Not exactly. No matter if it is set to NULL or unset then isset() will 
>give the same result.
>And most people use isset() AFAIK.

Whatever the current situation, there needs to be a way to check whether a 
certain array entry is NULL or not.

-Andrei


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

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[Andrei Zmievski]

At 03:12 AM 5/4/01 +0300, Andi Gutmans wrote:
>In the constructor of your class you can save the class name to a variable 
>if it's that important to you :)




-Andrei


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

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

[Andi Gutmans]

At 07:02 PM 5/3/2001 -0500, Andrei Zmievski wrote:
>At 06:31 PM 5/3/01 -0500, Richard Lynch wrote:
>>Um, lots of people use isset($row['foo]) to detect NULL in the database...
>>
>>Are you going to change that behaviour?
>>
>>Don't.
>>
>>If the column is missing, they screwed up their SQL, which is not within the
>>pervue of PHP to fix in the first place...
>
>You are arguing my point, Richard.

Andrei,

Not exactly. No matter if it is set to NULL or unset then isset() will give 
the same result.
And most people use isset() AFAIK.
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]

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[Andi Gutmans]

At 06:54 PM 5/3/2001 -0500, Andrei Zmievski wrote:
>At 02:50 AM 5/4/01 +0300, Andi Gutmans wrote:
>>I still don't think this is something lots of PHP users will benefit 
>>from. On the contrary, I think semantically it is more correct to define 
>>what the case insensitivity means (names are converted to lower case).
>>How many examples can you think of where this would actually help a PHP 
>>developer?
>
>Purely cosmetically, it would be nice. For example, in PHP-GTK I have a 
>lot of error messages that output class names, and it'd be nice to display 
>the names as they were registered by the user/system rather than all 
>lowercased.

In the constructor of your class you can save the class name to a variable 
if it's that important to you :)

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]

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

[Andrei Zmievski]

At 06:31 PM 5/3/01 -0500, Richard Lynch wrote:
>Um, lots of people use isset($row['foo]) to detect NULL in the database...
>
>Are you going to change that behaviour?
>
>Don't.
>
>If the column is missing, they screwed up their SQL, which is not within the
>pervue of PHP to fix in the first place...

You are arguing my point, Richard.

-Andrei


-- 
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-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] Release process

[Richard Lynch]

> On Thu, 03 May 2001, Andi Gutmans wrote:
> > Yeah but I'm afraid it'll make scripts be written on behavior which
> > shouldn't be counted on.
> > Maybe in future versions of Zend $array['foo'] won't be defined. There
are
> > certain situations where I think it was impossible to not define it so
it
> > was defined with NULL meaning it's not defined.
>
> Um, but some db extensions return NULL values as part of the array, so
> if column 'foo' is NULL in the db, you'd want the result array to have
> NULL under key 'foo' - it just won't do to have that column be missing.

Um, lots of people use isset($row['foo]) to detect NULL in the database...

Are you going to change that behaviour?

Don't.

If the column is missing, they screwed up their SQL, which is not within the
pervue of PHP to fix in the first place...

--
WARNING [EMAIL PROTECTED] address is not working -- Use [EMAIL PROTECTED]
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm



-- 
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-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6

[Richard Lynch]

How exactly would you define success/failure of the RC?...

I mean, if it crashes, you can probably catch that, but what if the output
is just incorrect?

You're back to the problem of only a pre-determined (and very limited)
validation suite can really use this, I think...

Or am I just being obtuse and difficult?

What might be more realistic would be to "fork" the request to an invisible
(to the end user) testing machine and real machine.

Then, the outputs of the two can be compared, and an error report of some
kind generated for any differences.

Ideally, the production output would be sent on its way without any "delay"
waiting for the testing machine to
respond/fail/explode-in-a-burst-of-flames.

There is some overhead, of course, but I *think* this is a more feasible
design, possibly even "doable"...

--
WARNING [EMAIL PROTECTED] address is not working -- Use [EMAIL PROTECTED]
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm
- Original Message -
From: Zak Greant <[EMAIL PROTECTED]>
To: James Moore <[EMAIL PROTECTED]>; Andi Gutmans <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, May 02, 2001 2:16 PM
Subject: [PHP-QA] Re: [PHP-DEV] RE: [PHP-QA] 4.0.6


> Andi wrote:
> [snip]
> > That was really a big disappointment as people did such a good job on
the
> > release cycle IMO.
> > No doubt it shouldn't have slipped in.
> > And if it doesn't get fixed soon we should revert to the old version of
> the
> > COM module.
>
> How much testing is the QA team actually doing?  I would suspect that
> the
> majority of the QA team follows the same slack process that I follow.
>
> 1.) build the latest release
> 2.) make test
> 3.) look at phpinfo()
> 4.) see what happens to a few scripts
>
> Am I right? :)
>
> We should be testing the RC's against large bodies of working
> code that real users are using. This is tough to do - no one wants to
> break a working site.
>
> How difficult (and useful) would it be for us to have a system like
> the one describe below.
>
> The standard PHP SAPIs and CGI executable are replaced by shell that
> maintains environment data and passes it to an RC.  The RC attempts
> to handle the request.  If it fails, the shell passes the same request
> is passed to a stable version of PHP, and the failure is logged,
> along with the environment data, etc...
>
> The user request may be slowed, but is still served.  The shell
> could include threshold settings so that we stop passing requests
> known to break the RC after a certain number of requests...
>
> By co-operating with various site owners, we could get the RCs into
> environments where they server millions of hits in a day in a broad
> range of situations.
>
> Anyone think that this blueskying is useful or possible?
>
> --zak
>
>
> --
> PHP Quality Assurance 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] 4.1 & Declaration Case Persistance

[Andrei Zmievski]

At 02:50 AM 5/4/01 +0300, Andi Gutmans wrote:
>I still don't think this is something lots of PHP users will benefit from. 
>On the contrary, I think semantically it is more correct to define what 
>the case insensitivity means (names are converted to lower case).
>How many examples can you think of where this would actually help a PHP 
>developer?

Purely cosmetically, it would be nice. For example, in PHP-GTK I have a lot 
of error messages that output class names, and it'd be nice to display the 
names as they were registered by the user/system rather than all lowercased.

-Andrei


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

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[Andi Gutmans]

At 06:46 PM 5/3/2001 -0500, Andrei Zmievski wrote:
>At 02:38 AM 5/4/01 +0300, Andi Gutmans wrote:
>I don't think it is trivial to implement this without:
>>a) Creating a second version of our hash tables (I don't like duplicate 
>>code).
>>b) Adding more complexity to the already complex hash tables.
>
>I may be missing something here, but why not simply add another field to 
>zend_class_entry that keeps track of the user declared name? I think 
>that's all the original poster was asking for..

I still don't think this is something lots of PHP users will benefit from. 
On the contrary, I think semantically it is more correct to define what the 
case insensitivity means (names are converted to lower case).
How many examples can you think of where this would actually help a PHP 
developer?

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]

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[Andrei Zmievski]

At 02:38 AM 5/4/01 +0300, Andi Gutmans wrote:
I don't think it is trivial to implement this without:
>a) Creating a second version of our hash tables (I don't like duplicate code).
>b) Adding more complexity to the already complex hash tables.

I may be missing something here, but why not simply add another field to 
zend_class_entry that keeps track of the user declared name? I think that's 
all the original poster was asking for..

-Andrei


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

[PHP-DEV] Bug #10654: Slight change to dead session detection?

[graeme]

From: [EMAIL PROTECTED]
Operating system: Linux i386
PHP version:  4.0.5
PHP Bug Type: OCI8 related
Bug description:  Slight change to dead session detection?

This could have been a php-dev list posting...
I'm not sure if this applies to the dead session detection change made in version 
1.106 of ext/oci8/oci8.c.

When our Oracle 8.1.6 server dies and is restarted we get an error back from PHP:
OCISessionBegin: ORA-24237: need explicit attach before authenticating a user.

To resolve this error, we have to restart our Apache server where PHP runs as a module.

Would adding oracle error 24237 to oci_handle_error() in oci.c resolve the problem?


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

[Sterling Hughes]

On Thu, 3 May 2001, John Donagher wrote:

>
> Hi Sterling-
>
> There are implementation-specific reasons of why this can be useful, but I was
> hoping to avoid the "I can't see why you'd want this" (very common on this
> list, and something I'm also guilty of, but limiting to the evolution of the
> language IMHO) argument in favor of "semantically that's probably the right way
> to do it, but it's not real important", which is why I'm willing to make the
> change if the concensus is that the change would be the right thing.
>

I'm asking "why do you want this?"  Because that's really what dictates
changes more than anything.  Its simple, if you can explain to enough
people on this mailing list why you want the feature, and you can
therefore convince enough of them they want the feature to be added,
that's what will get the feature put in PHP.  Currently, I see no real
reason for it, perhaps you can give me one?

As for semantics, I don't agree with your proposal. If you declare classes
in PHP, they are case in-sensitive.  Therefore, if you ask for the name of
the class, its case really shouldn't matter either, having the classes
always returned in lower case makes it easier because you always know the
case the class will be returned in.

> I definetly believe it's not real important and will have no visible benefit to
> "most people". What I want to be sure of is that it won't hurt "most people"
> either. I'm not sure if the speed decrease would be noticeable. I don't get
> your argument about it being a kludge; I think what we have now is the kludge.
> I do agree a get_declared_class() would probably have a high WTF factor, which
> is why I favor changing the original to (like Andrei said) accept a parameter
> which determines its behavior.
>

We're describing two different things.

I'm describing the implementation of the feature as a kludge (I can see
no clean way), not the feature itself.

-Sterling


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

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[Andi Gutmans]

At 03:16 PM 5/3/2001 -0400, John Donagher wrote:

>Hi Sterling-
>
>There are implementation-specific reasons of why this can be useful, but I was
>hoping to avoid the "I can't see why you'd want this" (very common on this
>list, and something I'm also guilty of, but limiting to the evolution of the
>language IMHO) argument in favor of "semantically that's probably the 
>right way
>to do it, but it's not real important", which is why I'm willing to make the
>change if the concensus is that the change would be the right thing.
>
>I definetly believe it's not real important and will have no visible 
>benefit to
>"most people". What I want to be sure of is that it won't hurt "most people"
>either. I'm not sure if the speed decrease would be noticeable. I don't get
>your argument about it being a kludge; I think what we have now is the kludge.
>I do agree a get_declared_class() would probably have a high WTF factor, which
>is why I favor changing the original to (like Andrei said) accept a parameter
>which determines its behavior.


I don't think it is trivial to implement this without:
a) Creating a second version of our hash tables (I don't like duplicate code).
b) Adding more complexity to the already complex hash tables.

I don't think any of these two options warrants a feature which maybe three 
PHP users will be dependent on.
Talking about semantics, as the class name is defined as case insensitive 
it actually does make some kind of sense of declaring a consistent way the 
"symbols" will look after compilation, i.e., lower case letters. This is 
similar to how other case insensitive compilers work.

If lots of people completely disagree with me then we can take a look at 
your patches and see if they make sense both on a complexity level and a 
performance level.

I know this isn't the answer you want to hear but this code is fragile, the 
hash tables are used by just about any part in PHP and on a whole I just 
don't think it's worth it. It's not like a great feature everyone has been 
missing and semantically it's not obviously more right than the way it is 
today.

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]

Re: [PHP-DEV] mailparse extension

[Andi Gutmans]

I think this would be of interest to the PHP community but I personally 
haven't messed with imap & email so it doesn't mean much :)

Andi

At 11:36 PM 5/3/2001 +0100, Wez Furlong wrote:
>Hi All,
>
>I would like to put my mailparse ("As seen on zend.com weekly summary")
>extension into CVS; shall I just check it into php4/ext?
>
> > wc *.c *.h README *.m4 *.in
> 8052374   21660 mailparse.c
>11913096   25926 rfc2045.c
>  78 2171578 rfc2045_base64encode.c
> 129 2892885 rfc2045acchk.c
> 108 2552096 rfc2045acprep.c
> 118 2672215 rfc2045appendurl.c
> 301 8286343 rfc2045cdecode.c
>  42 113 912 rfc2045decode.c
>  50 125 996 rfc2045find.c
>  61 1211119 rfc2045mkboundary.c
> 46011419385 rfc2045rewrite.c
> 117 2772528 rfc2045tryboundary.c
> 5421487   10700 rfc2047.c
> 110 2101899 rfc2047u.c
> 7221635   13411 rfc822.c
> 102 2221853 rfc822_getaddr.c
>  95 2081640 rfc822_getaddrs.c
>  84 2102748 php_mailparse.h
> 208 7395652 rfc2045.h
>  81 2651926 rfc2047.h
> 167 7055039 rfc822.h
>  79 3902917 README
>  26 132 958 config.m4
>  16  46 537 Makefile.in
>5692   15352  126923 total
>
>Any comments for/against this?
>
>It's based on maildrop, and I am cleaning out some cruft that does not
>apply to PHP, so I expect the code size to reduce.
>
>It allows you to parse MIME mail (something that a lot of people are doing
>with PHP) in a resource efficient manner - streaming through files rather
>loading the whole thing into memory (something you don't want to do with
>100 users opening messages with 2MB attachments).
>
>I plan to add support for creating MIME mail (a bit like the
>imap_mail_compose() function, but with no dependencies on c-client), and
>provide an integrated "mail_compose" function that can also handle S/MIME
>signatures (via openssl extension).
>
>I know Jani was interested in seeing this get into CVS, and I have had 84
>downloads since the weekly summary was published (week31).
>
>--Wez.
>
>
>--
>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 #9609 Updated: imap_getsubscribed core dumps if there are no subscribed folders

[brad]

ID: 9609
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: IMAP related
Description: imap_getsubscribed core dumps if there are no subscribed folders

Appears to be fixed in the latest CSV.  Thanks.

Previous Comments:
---

[2001-05-03 15:55:46] [EMAIL PROTECTED]
I can't reproduce this with 4.0.6-cvs, and I don't remember running into it earlier, 
either. Can you still reproduce it, and if so, can you give a backtrace?

---

[2001-03-07 21:22:57] [EMAIL PROTECTED]
The imap_getsubscribed on my setup will core dump if there are no subscribed folders.  
It's sister function imap_getmailboxes however works fine.

I have tried this with 4.0.3pl1, 4.0.4, and 4.0.4pl1 using uw imap 2000a, and 
2001-beta.

configured with:
'./configure' '--with-mysql=/usr/local/mysql' '--with-config-file-path=/etc' 
'--with-system-regex' '--disable-debug' '--with-exec-dir=/' '--enable-sysvshm=yes' 
'--enable-sysvsem=yes' '--enable-ftp' '--enable-trans-sid' 
'--enable-inline-optimization' 
'--with-cybercash=/usr/local/work/mck-3.2.0.6-i586-pc-linux-gnulibc2.1' 
'--with-imap=/usr/local/work/imap-2001.beta' '--with-oci8'

---


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


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

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[John Donagher]

Hi Sterling-

There are implementation-specific reasons of why this can be useful, but I was
hoping to avoid the "I can't see why you'd want this" (very common on this
list, and something I'm also guilty of, but limiting to the evolution of the
language IMHO) argument in favor of "semantically that's probably the right way
to do it, but it's not real important", which is why I'm willing to make the
change if the concensus is that the change would be the right thing.

I definetly believe it's not real important and will have no visible benefit to
"most people". What I want to be sure of is that it won't hurt "most people"
either. I'm not sure if the speed decrease would be noticeable. I don't get
your argument about it being a kludge; I think what we have now is the kludge.
I do agree a get_declared_class() would probably have a high WTF factor, which
is why I favor changing the original to (like Andrei said) accept a parameter
which determines its behavior.

Thanks
John

On Thu, 3 May 2001, Sterling Hughes wrote:

> On Thu, 3 May 2001, Wez Furlong wrote:
> 
> > On 2001-05-03 22:51:41, "Wez Furlong" <[EMAIL PROTECTED]> wrote:
> > > | "John Donagher" <[EMAIL PROTECTED]>
> > > > Right now, when a class (or method, or function) is declared, its
> > name
> > > > is zend_str_tolower()'d.
> > > > it would be nice if the original casing on the class name was
> > persisted
> > > > so that functions like get_class would return the actual
> > *as-declared*
> > > > class name.
> > > +1
> > > It will work, right (zend guys?).
> > > I'd love to see it.
> 
> I really don't see why you would want this (correct case of class names
> being returned).  But besides that, its not (imho) worth the speed
> decrease (and kludge factor) to implement.
> 
> -Sterling
> 
> 
> 

-- 

John Donagher
Application Engineer
Intacct Corp. - Powerful Accounting on the Web
408-395-0989
720 University Ave.
Los Gatos CA 95032
www.intacct.com

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD


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

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[Wez Furlong]

On 2001-05-03 22:53:49, "Andrei Zmievski" <[EMAIL PROTECTED]> wrote:
> On Thu, 03 May 2001, Wez Furlong wrote:
> > OK, so +1 to get_declared_class() which returns the class name with
> Umm, that sounds kind of arbitrary. There could be an optional
> parameter to get_class(), get_parent_class(), and others that specifies
> which class name to return.

You're right.
 
> * How would this sentence be different if Pi was equal to three? *

* How would this sentence be different if Pi was not equal to three? *

--Wez.



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

[Wez Furlong]

Hi All,

I would like to put my mailparse ("As seen on zend.com weekly summary")
extension into CVS; shall I just check it into php4/ext?

> wc *.c *.h README *.m4 *.in
8052374   21660 mailparse.c
   11913096   25926 rfc2045.c
 78 2171578 rfc2045_base64encode.c
129 2892885 rfc2045acchk.c
108 2552096 rfc2045acprep.c
118 2672215 rfc2045appendurl.c
301 8286343 rfc2045cdecode.c
 42 113 912 rfc2045decode.c
 50 125 996 rfc2045find.c
 61 1211119 rfc2045mkboundary.c
46011419385 rfc2045rewrite.c
117 2772528 rfc2045tryboundary.c
5421487   10700 rfc2047.c
110 2101899 rfc2047u.c
7221635   13411 rfc822.c
102 2221853 rfc822_getaddr.c
 95 2081640 rfc822_getaddrs.c
 84 2102748 php_mailparse.h
208 7395652 rfc2045.h
 81 2651926 rfc2047.h
167 7055039 rfc822.h
 79 3902917 README
 26 132 958 config.m4
 16  46 537 Makefile.in
   5692   15352  126923 total

Any comments for/against this?

It's based on maildrop, and I am cleaning out some cruft that does not
apply to PHP, so I expect the code size to reduce.

It allows you to parse MIME mail (something that a lot of people are doing
with PHP) in a resource efficient manner - streaming through files rather
loading the whole thing into memory (something you don't want to do with
100 users opening messages with 2MB attachments).

I plan to add support for creating MIME mail (a bit like the
imap_mail_compose() function, but with no dependencies on c-client), and
provide an integrated "mail_compose" function that can also handle S/MIME
signatures (via openssl extension).

I know Jani was interested in seeing this get into CVS, and I have had 84
downloads since the weekly summary was published (week31).

--Wez.


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

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[Sterling Hughes]

On Thu, 3 May 2001, Wez Furlong wrote:

> On 2001-05-03 22:51:41, "Wez Furlong" <[EMAIL PROTECTED]> wrote:
> > | "John Donagher" <[EMAIL PROTECTED]>
> > > Right now, when a class (or method, or function) is declared, its
> name
> > > is zend_str_tolower()'d.
> > > it would be nice if the original casing on the class name was
> persisted
> > > so that functions like get_class would return the actual
> *as-declared*
> > > class name.
> > +1
> > It will work, right (zend guys?).
> > I'd love to see it.

I really don't see why you would want this (correct case of class names
being returned).  But besides that, its not (imho) worth the speed
decrease (and kludge factor) to implement.

-Sterling


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

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[Andrei Zmievski]

On Thu, 03 May 2001, Wez Furlong wrote:
> I just read Colins comments (but deleted the message already!).
> 
> OK, so +1 to get_declared_class() which returns the class name with
> original case preserved.

Umm, that sounds kind of arbitrary. There could be an optional
parameter to get_class(), get_parent_class(), and others that specifies
which class name to return.

-Andrei
* How would this sentence be different if Pi was equal to three? *

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

Re: [PHP-DEV] 4.1 & Declaration Case Persistance

[Wez Furlong]

On 2001-05-03 22:51:41, "Wez Furlong" <[EMAIL PROTECTED]> wrote:
> | "John Donagher" <[EMAIL PROTECTED]>
> > Right now, when a class (or method, or function) is declared, its
name
> > is zend_str_tolower()'d.
> > it would be nice if the original casing on the class name was
persisted
> > so that functions like get_class would return the actual
*as-declared*
> > class name.
> +1
> It will work, right (zend guys?).
> I'd love to see it.

I just read Colins comments (but deleted the message already!).

OK, so +1 to get_declared_class() which returns the class name with
original case preserved.

--Wez.


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

[PHP-DEV] Bug #10653: loop limiters

[tboothby]

From: [EMAIL PROTECTED]
Operating system: N/A
PHP version:  4.0.5
PHP Bug Type: Feature/Change Request
Bug description:  loop limiters

Looping structures should (IMO) all have a limiting variant.

For example,
while100($rec=mysql_fetch_row($res)) {...}

Would only loop 100 times

for1000($i=0;$ihttp://bugs.php.net/?id=10653&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] 4.1 & Declaration Case Persistance

[Wez Furlong]

| "John Donagher" <[EMAIL PROTECTED]>
> Right now, when a class (or method, or function) is declared, its name
> is zend_str_tolower()'d.
> it would be nice if the original casing on the class name was persisted
> so that functions like get_class would return the actual *as-declared*
> class name.

+1

It will work, right (zend guys?).

I'd love to see it.

--Wez.


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

[PHP-DEV] Bug #10652: payflow pro support core dumps ftp

[brad]

From: [EMAIL PROTECTED]
Operating system: Linux 6.2 EE
PHP version:  4.0 Latest CVS (03/05/2001)
PHP Bug Type: Reproduceable crash
Bug description:  payflow pro support core dumps ftp

Latest CVS and the latest SDK for Payflow Pro will produce a core dump when using the 
FTP command set.  This has also happened on prior 4.0.x versions and previous versions 
of the pfpro SDK.

This is compiled as a CGI for use with Zeus webserver however the crash will occur 
regardless of if

Simple Script:


Configure:

'./configure' '--with-mysql=/usr/local/mysql' '--with-config-file-path=/etc' 
'--with-system-regex' '--disable-debug' '--with-exec-dir=/' '--enable-sysvshm=yes' 
'--enable-sysvsem=yes' '--enable-ftp' '--enable-trans-sid' 
'--enable-inline-optimization' 
'--with-cybercash=/usr/work/mck-3.2.0.6-i586-pc-linux-gnulibc2.1' 
'--with-imap=/usr/work/imap-2000a' '--with-oci8' 
'--with-pfpro=/usr/local/verisign/payflowpro/linux'

gdb backtrace:

GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `./php'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libpam.so.0...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /usr/local/verisign/payflowpro/linux/lib/libpfpro.so...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /usr/lib/libz.so.1...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/local/mysql/lib/mysql/libmysqlclient.so.10...done.
Reading symbols from /lib/libresolv.so.2...done.
Reading symbols from /ora/app/lib/libclntsh.so.8.0...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /ora/app/lib/libwtc8.so...done.
Reading symbols from /lib/libnss_files.so.2...done.
Reading symbols from /lib/libnss_nisplus.so.2...done.
Reading symbols from /lib/libnss_nis.so.2...done.
#0  0x400cb364 in pfproVersion () from 
/usr/local/verisign/payflowpro/linux/lib/libpfpro.so
(gdb) bt
#0  0x400cb364 in pfproVersion () from 
/usr/local/verisign/payflowpro/linux/lib/libpfpro.so
#1  0x4071da75 in __new_tmpfile () at tmpfile.c:41
#2  0x806fdac in ftp_genlist (ftp=0x82391c0, cmd=0x8160926 "LIST", path=0x81f3944 ".") 
at ftp.c:1137
#3  0x806ed8b in ftp_list (ftp=0x82391c0, path=0x81f3944 ".") at ftp.c:420
#4  0x806dc5c in php_if_ftp_rawlist (ht=2, return_value=0x82390dc, this_ptr=0x0, 
return_value_used=1) at php_ftp.c:446
#5  0x8109950 in execute (op_array=0x823906c) at ./zend_execute.c:1504
#6  0x80e36f8 in zend_execute_scripts (type=8, file_count=3) at zend.c:743
#7  0x80692e8 in php_execute_script (primary_file=0xbaa4) at main.c:1206
#8  0x8067b11 in main (argc=1, argv=0xbb04) at cgi_main.c:717
(gdb) quit


-- 
Edit Bug report at: http://bugs.php.net/?id=10652&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 #10642 Updated: error connecting to database

[miller]

ID: 10642
User Update by: [EMAIL PROTECTED]
Old-Status: Duplicate
Status: Open
Bug Type: *Install and Config
Description: error connecting to database

Duplicate of #10612, but the fix described in 10612 didn't take care of the problem 
for me.

Please look into this.

Thanks.

Previous Comments:
---

[2001-05-03 14:04:37] [EMAIL PROTECTED]
duplicate of #10612

---

[2001-05-03 13:57:05] [EMAIL PROTECTED]
Identical problem as Bug#10612.

I installed the CVS php4-200105030445 and still have the same problem.

Your help would be appreciated.

---


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


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

[PHP-DEV] Bug #10650 Updated: Your responder is fucked!

[vlad]

ID: 10650
Updated by: vlad
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Unknown/Other Function
PHP Version: 4.0.5
Assigned To: 
Comments:



Previous Comments:
---

[2001-05-03 17:14:09] [EMAIL PROTECTED]
Please fix, Jani!

-- snipp --

Bug id #10648
Status: Bogus User Modify   Dev Modify 
From: [EMAIL PROTECTED] 
Date: 2001-05-03 16:21:36 
Type: *Web Server problem 
OS: ? 
PHP Version: 4.0.5 
Assigned To:  
Short Desc.: Parse error 


[2001-05-03 16:21:36] [EMAIL PROTECTED]

Your own home page is failing with a parse error.

Tell me again why I would buy your product?  CAnt even make it run for yourselves?
[2001-05-03 16:26:25] [EMAIL PROTECTED]

I dunno why you would buy it - it's free... :)
[2001-05-03 16:27:49] [EMAIL PROTECTED]

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani

[2001-05-03 16:27:54] [EMAIL PROTECTED]

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani

[2001-05-03 16:27:57] [EMAIL PROTECTED]

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani

[2001-05-03 16:28:02] [EMAIL PROTECTED]

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10650&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] Bug #10651 Updated: I have a lovely bunch of coconuts

[derick]

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

Well fuck off now, you are really anooying now.

Previous Comments:
---

[2001-05-03 17:18:15] [EMAIL PROTECTED]
ALL YOUR COCONUTS ARE BELONG TO US!!!

WHAT YOU SAY!!

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10651&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] Bug #10651: I have a lovely bunch of coconuts

[biatch]

From: [EMAIL PROTECTED]
Operating system: Spudworks 9.n
PHP version:  4.0.5
PHP Bug Type: Feature/Change Request
Bug description:  I have a lovely bunch of coconuts

ALL YOUR COCONUTS ARE BELONG TO US!!!

WHAT YOU SAY!!


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



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

[PHP-DEV] Bug #7486 Updated: imap_uid does not return the uid

[chagenbu]

ID: 7486
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Bogus
Bug Type: IMAP related
PHP Version: 4.0.2
Assigned To: 
Comments:

That's the Message-ID header. The uid which imap_uid() is intended to return is a 
unique identifier of that that message in that mailbox that won't change over time. It 
has nothing to do with the Message-ID header.

Previous Comments:
---

[2001-05-03 17:14:14] [EMAIL PROTECTED]
From: "Rick Gigger" <[EMAIL PROTECTED]>

All email messages have a unique identifier.  It is a long string that ususally 
contains a domiain name or ip address.  It is unique to all email addresses in the 
world.  It would be much, much more useful if imap_uid
would return that instead.

---

[2001-05-03 15:36:24] [EMAIL PROTECTED]
You might have the wrong idea of what uid is - what do you expect it to be? On pop 
servers the message uid will very likely just _be_ the message number...

---

[2000-10-27 03:30:55] [EMAIL PROTECTED]
When I call connect to a qmail pop server and call imap_uid all it does is return the 
message number back to me.  It DOES NOT return the uid.  I have to call imap_header 
for that and it is very slow.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7486&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] Re: [PHP-QA] Re: [PHP-DEV] Re: [PHP-QA] 4.0.6 (fwd)

[Richard Lynch]

> The question is, if you think people will actually download the RC in
order
> to test it (as opposed to using it) - why won't they join the QA team?

Because they have enough time to make sure their software still works with
the RC, but not enough time to wade through all the QA emails. :-)

Most likely, though, the cost/benefit ratio of mass distribution of the RCs
is borderline -- And throwing a few more resources at the QA team (eg Win
binaries) will be far more effective.

There will *always* be some bugs that only get found by mass testing.  The
COM bug should have been caught by a QA team member, and you've identified
why not.

:-) :-) :-) Suggested Compromise Ultimatum:  Windows binaries and Zend test
machine before 4.0.6RC1, or post RC announcement to the masses.  This should
goad us (okay, you) into having the process in place or suffering the
consequences :-) :-) :-)

--
WARNING [EMAIL PROTECTED] address is not working -- Use [EMAIL PROTECTED]
Wanna help me out?  Like Music?  Buy a CD: http://l-i-e.com/artists.htm
Volunteer a little time: http://chatmusic.com/volunteer.htm



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

[PHP-DEV] Bug #10648 Updated: Parse error

[cmv]

ID: 10648
Updated by: cmv
Reported By: [EMAIL PROTECTED]
Old-Status: Bogus
Status: Closed
Bug Type: *Web Server problem
PHP Version: 4.0.5
Assigned To: cmv
Comments:

a) Nice email address.

b) The parse error has been fixed in CVS, and just takes a while to propogate to the 
mirror sites.  My fault for not checking before I committed.

c) You don't buy PHP.

d) PHP isn't a company.

e) People make mistakes.  So relax.

f) And learn to read where it says where to report bugs about the website.


Previous Comments:
---

[2001-05-03 17:11:23] [EMAIL PROTECTED]
NICE RESPONSE.

This is the language DB.  PUHLEESE do you not give a shit about your own company's web 
page?

---

[2001-05-03 16:28:02] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:27:57] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:27:54] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:27:49] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

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


ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10648&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] Bug #7486 Updated: imap_uid does not return the uid

[chagenbu]

ID: 7486
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: IMAP related
PHP Version: 4.0.2
Assigned To: 
Comments:

From: "Rick Gigger" <[EMAIL PROTECTED]>

All email messages have a unique identifier.  It is a long string that ususally 
contains a domiain name or ip address.  It is unique to all email addresses in the 
world.  It would be much, much more useful if imap_uid
would return that instead.

Previous Comments:
---

[2001-05-03 15:36:24] [EMAIL PROTECTED]
You might have the wrong idea of what uid is - what do you expect it to be? On pop 
servers the message uid will very likely just _be_ the message number...

---

[2000-10-27 03:30:55] [EMAIL PROTECTED]
When I call connect to a qmail pop server and call imap_uid all it does is return the 
message number back to me.  It DOES NOT return the uid.  I have to call imap_header 
for that and it is very slow.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7486&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] Bug #10650: Your responder is fucked!

[noone]

From: [EMAIL PROTECTED]
Operating system: Your site
PHP version:  4.0.5
PHP Bug Type: Unknown/Other Function
Bug description:  Your responder is fucked!

Please fix, Jani!

-- snipp --

Bug id #10648
Status: Bogus User Modify   Dev Modify 
From: [EMAIL PROTECTED] 
Date: 2001-05-03 16:21:36 
Type: *Web Server problem 
OS: ? 
PHP Version: 4.0.5 
Assigned To:  
Short Desc.: Parse error 


[2001-05-03 16:21:36] [EMAIL PROTECTED]

Your own home page is failing with a parse error.

Tell me again why I would buy your product?  CAnt even make it run for yourselves?
[2001-05-03 16:26:25] [EMAIL PROTECTED]

I dunno why you would buy it - it's free... :)
[2001-05-03 16:27:49] [EMAIL PROTECTED]

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani

[2001-05-03 16:27:54] [EMAIL PROTECTED]

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani

[2001-05-03 16:27:57] [EMAIL PROTECTED]

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani

[2001-05-03 16:28:02] [EMAIL PROTECTED]

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani




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

[Colin Viebrock]

> Any opinions? Have I overlooked something that makes this more difficult
than
> it seems? I'm willing to work on this if I can gather some positive
concensus.

For one thing, I would have to change all my code from:

if (get_class($var)=='foo_class')) { ... }

... to:

if (get_class($var)=='Foo_Class')) { ... }

... (assuming I know how it was declared), or to:

if (strtolower(get_class($var))=='foo_class')) { ... }

... which I personally think is kludgy.  Ditto for function_exists(), I
assume.  Or are you suggesting something like:

getOriginalDeclaredName('foo_class');// returns 'Foo_Class';

... which I don't have a problem with, I suppose.  Then again, I don't write
the Zend code. :)

I don't follow how having the full case of the original declaration would
help you.

- Colin


-- 
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 #10648 Updated: Parse error

[wesuck]

ID: 10648
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Web Server problem
Description: Parse error

NICE RESPONSE.

This is the language DB.  PUHLEESE do you not give a shit about your own company's web 
page?

Previous Comments:
---

[2001-05-03 16:28:02] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:27:57] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:27:54] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:27:49] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:26:25] [EMAIL PROTECTED]
I dunno why you would buy it - it's free... :)

---

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

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


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

[PHP-DEV] RE: Bug #7486 Updated: imap_uid does not return the uid

[Rick Gigger]

All email messages have a unique identifier.  It is a long string that
ususally contains a domiain name or ip address.  It is unique to all email
addresses in the world.  It would be much, much more useful if imap_uid
would return that instead.

Rick Gigger

-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 03, 2001 12:36 PM
To: [EMAIL PROTECTED]
Subject: Bug #7486 Updated: imap_uid does not return the uid


ID: 7486
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: IMAP related
PHP Version: 4.0.2
Assigned To:
Comments:

You might have the wrong idea of what uid is - what do you expect it to be?
On pop servers the message uid will very likely just _be_ the message
number...

Previous Comments:
---

[2000-10-27 03:30:55] [EMAIL PROTECTED]
When I call connect to a qmail pop server and call imap_uid all it does is
return the message number back to me.  It DOES NOT return the uid.  I have
to call imap_header for that and it is very slow.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7486&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] connection_timeout() and PHP 3

[Zak Greant]

Does anyone know if connection_timeout will be disappearing from PHP 3?

Zak Greant
Freelance Designer / Programmer / Writer

PHP QA Team Member
http://qa.php.net/

Am I working on a project for or with you?
Check http://calendar.yahoo.ca/jagreant


-- 
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] 4.1 & Declaration Case Persistance

[John Donagher]

Hi folks-

I brought this up a few months ago, and due to either tacid approval or utter
disinterest I was unable to spark a discussion or gather a concensus :)

Right now, when a class (or method, or function) is declared, its name is
zend_str_tolower()'d. This provides the case-insensitivity that PHP has, but it
would be nice if the original casing on the class name was persisted so that
functions like get_class would return the actual *as-declared* class name. This
has a rather narrow end-user meaning for most people, but not for teams like
ours who structure their code with cased filenames. The current implementation
can be worked-around, I'm just not sure I see any advantage of lowercasing the
declarative as opposed to just maintaining a hash of lowercase => as_declared.
That would still allow for case-insensitivity while allowing the reverse-lookup
functions to be more correct.

Any opinions? Have I overlooked something that makes this more difficult than
it seems? I'm willing to work on this if I can gather some positive concensus.

-- 

John Donagher
Application Engineer
Intacct Corp. - Powerful Accounting on the Web
408-395-0989
720 University Ave.
Los Gatos CA 95032
www.intacct.com

Public key available off http://www.keyserver.net
Key fingerprint = 4024 DF50 56EE 19A3 258A  D628 22DE AD56 EEBE 8DDD


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

[PHP-DEV] Bug #10649 Updated: error line 141 change , to ;

[sniper]

ID: 10649
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Performance problem
PHP Version: 4.0.5
Assigned To: 
Comments:



Previous Comments:
---

[2001-05-03 16:21:53] [EMAIL PROTECTED]


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10649&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] Bug #10648 Updated: Parse error

[sniper]

ID: 10648
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Web Server problem
PHP Version: 4.0.5
Assigned To: 
Comments:

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


Previous Comments:
---

[2001-05-03 16:27:57] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:27:54] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:27:49] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:26:25] [EMAIL PROTECTED]
I dunno why you would buy it - it's free... :)

---

[2001-05-03 16:21:36] [EMAIL PROTECTED]
Your own home page is failing with a parse error.

Tell me again why I would buy your product?  CAnt even make it run for yourselves?

---

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=10648&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] Bug #10648 Updated: Parse error

[sniper]

ID: 10648
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Web Server problem
PHP Version: 4.0.5
Assigned To: 
Comments:

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


Previous Comments:
---

[2001-05-03 16:27:54] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:27:49] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:26:25] [EMAIL PROTECTED]
I dunno why you would buy it - it's free... :)

---

[2001-05-03 16:21:36] [EMAIL PROTECTED]
Your own home page is failing with a parse error.

Tell me again why I would buy your product?  CAnt even make it run for yourselves?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10648&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] Bug #10648 Updated: Parse error

[sniper]

ID: 10648
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: *Web Server problem
PHP Version: 4.0.5
Assigned To: 
Comments:

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


Previous Comments:
---

[2001-05-03 16:27:49] [EMAIL PROTECTED]
And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


---

[2001-05-03 16:26:25] [EMAIL PROTECTED]
I dunno why you would buy it - it's free... :)

---

[2001-05-03 16:21:36] [EMAIL PROTECTED]
Your own home page is failing with a parse error.

Tell me again why I would buy your product?  CAnt even make it run for yourselves?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10648&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] Bug #10648 Updated: Parse error

[sniper]

ID: 10648
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Bogus
Bug Type: *Web Server problem
PHP Version: 4.0.5
Assigned To: 
Comments:

And this is PHP the language bug database. 
Send website related bug reports to [EMAIL PROTECTED]

--Jani


Previous Comments:
---

[2001-05-03 16:26:25] [EMAIL PROTECTED]
I dunno why you would buy it - it's free... :)

---

[2001-05-03 16:21:36] [EMAIL PROTECTED]
Your own home page is failing with a parse error.

Tell me again why I would buy your product?  CAnt even make it run for yourselves?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10648&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] Bug #10647 Updated: parse error on web site index(www.php.net

[sniper]

ID: 10647
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *General Issues
PHP Version: 4.0.5
Assigned To: 
Comments:

this is PHP the LANGUAGE bug db. Please report 'bugs' on
the website to [EMAIL PROTECTED]

And this should be fixed btw..

--Jani

Previous Comments:
---

[2001-05-03 16:21:32] [EMAIL PROTECTED]
Parse error: parse error, expecting `','' or `';'' in 
/local/Web/sites/phpweb/index.php on line 141

:) he he he what a bug do not youthink like me_?


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10647&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] Bug #10648 Updated: Parse error

[vlad]

ID: 10648
Updated by: vlad
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: *Web Server problem
PHP Version: 4.0.5
Assigned To: 
Comments:

I dunno why you would buy it - it's free... :)

Previous Comments:
---

[2001-05-03 16:21:36] [EMAIL PROTECTED]
Your own home page is failing with a parse error.

Tell me again why I would buy your product?  CAnt even make it run for yourselves?

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10648&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] Imap SSL support (Bug #10330)

[Alexander Bokovoy]

On Thu, May 03, 2001 at 12:07:47PM +0200, Jani Taskinen wrote:
> On Thu, 3 May 2001, Alexander Bokovoy wrote:
> 
> >On Thu, May 03, 2001 at 11:21:28AM +0200, Jani Taskinen wrote:
> >> On Thu, 3 May 2001, Alexander Bokovoy wrote:
> >>
> >> >> Hrhm. If you know what is wrong then fix it and send a patch.
> >> >> Or at least point us WHERE the problem is. Everything works
> >> >> for me just fine as it is -> no broken functionality.
> >> >So, it means that you never test PHP extensions in SCE mode.
> >>
> >> So? I have no use for SCEs.
> >Then you can't talk about 'no broken functionality' or trust those who
> >checks this mode and reports about problems.
> 
> True and that's why I said that someone else should look at those
> patches you send. I'll shut up now about this. For most of the
> PHP users the IMAP extension (among all the other) work just fine
> and they don't need to compile them as SCEs. And that's enough for me.
> 
> I just wonder why you had to start arguing about this as the
> original bug report doesn't say ANYTHING about compiling any extensions
> as SCEs..
My fault here to adding existing problem with IMAP extension to different
one with this extension too. IMAP extension is one of those with 
'broken' config.m4 which work with usual configure process and fail with
phpize. 
-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

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

Re: [PHP-DEV] Imap SSL support (Bug #10330)

[Alexander Bokovoy]

On Thu, May 03, 2001 at 11:57:14AM +0200, Jani Taskinen wrote:
> On Thu, 3 May 2001, Emiliano wrote:
> 
> >Jani Taskinen wrote:
> >> Why would anyone want to use phpize on imap extension?
> >> (forgive me but I never have needed phpize..)
> >
> >You do when you want to develop self-contained extensions. SCEs are
> >useful for large PHP extensions that have to live outside the main PHP
> >tree, or for package builders that want to develop a main php4 package
> >and separate packages for the extensions (much like debian does).
> 
> Well, this is off topic. I was talking about the IMAP extension
> that lives in inside the main PHP tree and it doesn't have any
> use for phpize.
Any extension can be built using phpize, there is no serious difference in
building process with or without it except for discussed one. It is needed
for distribution vendors. No matter where extension lives, it needs to be
packaged and build separately of building PHP binary itself (or different
SAPI module). This is just for better management of building process. Of
course, this is up to distribution vendors how to make this process, but
why to complicate work? Many people use vendor-provided binaries for
PHP and it's modules.

In addition, environment to build extensions as SCE was one of the most
valuable achievements of PHP4, isn't it? :-)

Enough on this topic, let's back to work :-)

-- 
Sincerely yours, Alexander Bokovoy 
  The Midgard Project| ALT  Linux  Team | Minsk Linux Users Group
 www.midgard-project.org | www.altlinux.ru  |www.minsk-lug.net 
-- You won't skid if you stay in a rut.
-- Frank Hubbard

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

[PHP-DEV] Bug #10646 Updated: It is fucked! please fix it!

[sniper]

ID: 10646
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: *General Issues
PHP Version: 4.0.5
Assigned To: 
Comments:

this is PHP the LANGUAGE bug db. Please report 'bugs' on
the website to [EMAIL PROTECTED]

--Jani


Previous Comments:
---

[2001-05-03 16:19:20] [EMAIL PROTECTED]
Parse error: parse error, expecting `','' or `';'' in 
/local/Web/sites/phpweb/index.php on line 141


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10646&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] Bug #10649: error line 141 change , to ;

[mike]

From: [EMAIL PROTECTED]
Operating system: 
PHP version:  4.0.5
PHP Bug Type: Performance problem
Bug description:  error line 141 change , to ;




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



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

[PHP-DEV] Bug #10648: Parse error

[wesuck]

From: [EMAIL PROTECTED]
Operating system: ?
PHP version:  4.0.5
PHP Bug Type: *Web Server problem
Bug description:  Parse error

Your own home page is failing with a parse error.

Tell me again why I would buy your product?  CAnt even make it run for yourselves?


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



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

[PHP-DEV] Bug #10647: parse error on web site index(www.php.net

[evren]

From: [EMAIL PROTECTED]
Operating system: I dont know it is your site 
PHP version:  4.0.5
PHP Bug Type: *General Issues
Bug description:  parse error on web site index(www.php.net

Parse error: parse error, expecting `','' or `';'' in 
/local/Web/sites/phpweb/index.php on line 141

:) he he he what a bug do not youthink like me_?



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



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

[PHP-DEV] Bug #10646: It is fucked! please fix it!

[noone]

From: [EMAIL PROTECTED]
Operating system: Your Site
PHP version:  4.0.5
PHP Bug Type: *General Issues
Bug description:  It is fucked! please fix it!

Parse error: parse error, expecting `','' or `';'' in 
/local/Web/sites/phpweb/index.php on line 141



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



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

[PHP-DEV] Bug #10645 Updated: undefined versioned symbol name

[sniper]

ID: 10645
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Compile Failure
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Should be fixed in 4.0.5. If not, reopen.

--Jani


Previous Comments:
---

[2001-05-03 15:42:12] [EMAIL PROTECTED]
my configure line was
./configure --prefix=/usr/local/php 
--with-apxs=/usr/local/apache/apxs 
--with-mysql=/usr/local/mysql 
--with-pgsql=/usr/local/pgsql 
--with-GD

 ... and this is the line when i have compiled the 

module /usr/bin/ld: .libs/libphp4.so: undefined versioned symbol name 
__ns_name_unpack@@GLIBC_2.1
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libphp4.la] Error 1
make[1]: Leaving directory `/root/Src/php-4.0.4pl1'
make: *** [all-recursive] Error 1



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10645&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] fork() ?

[Wez Furlong]

Hi All,

For the project that I am currently working on, I have a number of pages
that need to initiate some lengthy processing that would (ideally) be
carried out in the background while allowing the site user to carry on with
other page views.

A fork() call would be ideal for this purpose.

What are the implications?
I can think of these:

1. The forked child might try and do something strange after PHP has
finished processing the script and returned control to the SAPI.
2. Persistent resources might get screwed.

For (1), PHP could keep a flag so that it knows when it forked and then
call _exit() instead of returning control to the SAPI.

For (2), I'm not sure if/when it would happen.

What else is there to get in the way of this?
If it's been discussed before, just tell me to shut up! ;-)

The other alternative is to run another process that makes an HTTP request
to another php page, but this is a pain because session state and the vars
in the current page are not maintained.

--Wez.


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

[PHP-DEV] Bug #10644 Updated: __FILE__ missing path delimiters

[derick]

ID: 10644
Updated by: derick
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
PHP Version: 4.0.5
Assigned To: 
Comments:

I also encountered this.

Previous Comments:
---

[2001-05-03 15:16:11] [EMAIL PROTECTED]
With 4.0.6 latest cvs (not 4.0.5; is there a reason the latest cvs option in the 
versions menu is dated March?), __FILE__ is returning the filename with no path 
delimiters. For example, if the script is /var/www/foo.php, __FILE__ contains 
'varwwwfoo.php'.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10644&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] Bug #9609 Updated: imap_getsubscribed core dumps if there are no subscribed folders

[chagenbu]

ID: 9609
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: IMAP related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

I can't reproduce this with 4.0.6-cvs, and I don't remember running into it earlier, 
either. Can you still reproduce it, and if so, can you give a backtrace?

Previous Comments:
---

[2001-03-07 21:22:57] [EMAIL PROTECTED]
The imap_getsubscribed on my setup will core dump if there are no subscribed folders.  
It's sister function imap_getmailboxes however works fine.

I have tried this with 4.0.3pl1, 4.0.4, and 4.0.4pl1 using uw imap 2000a, and 
2001-beta.

configured with:
'./configure' '--with-mysql=/usr/local/mysql' '--with-config-file-path=/etc' 
'--with-system-regex' '--disable-debug' '--with-exec-dir=/' '--enable-sysvshm=yes' 
'--enable-sysvsem=yes' '--enable-ftp' '--enable-trans-sid' 
'--enable-inline-optimization' 
'--with-cybercash=/usr/local/work/mck-3.2.0.6-i586-pc-linux-gnulibc2.1' 
'--with-imap=/usr/local/work/imap-2001.beta' '--with-oci8'

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9609&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] Bug #10638: exec(), system(), ... without reply

[Daniel Beulshausen]

At 20:58 03.05.2001 +0300, Andi Gutmans wrote:
>At 07:42 PM 5/3/2001 +0200, Daniel Beulshausen wrote:
>>At 19:24 03.05.2001 +0200, Daniel Beulshausen wrote:
>>>At 20:04 03.05.2001 +0300, Andi Gutmans wrote:
At 12:59 PM 5/3/2001 -0400, Joe Brown wrote:
>echo typically is not a program.
>It is a command in the CMD.exe or COMMAND.com programs.
>
>$output=exec("cmd -c echo hello"); //should produce the desired effect.
>
>Why piping output to a file changes this fact, is beyond me.

The definition of exec() is that it uses popen() which starts a shell 
automatically. Anyway, the problem was very Windows specific and 
doesn't have anything to do with the syntax he used.
>>>
>>>right now we are executing the programm direct, without creating a console.
>>>maybe we should manage a list of internal commands, like echo, dir, 
>>>copy,... and create  a console for them...
>>
>>no it's a bad idea, i'll shut up :)
>>cmd line parsing is a pretty bad idea, and the user is better of doing
>>passthru( getenv("COMSPEC") . " /c echo")
>
>Ouch but then the fix isn't popen() compatible.

we could behave exactly like popen if we would check for COMSPEC, and if 
that isn't present detect the OS and use command.com or cmd.exe, that's 
exactly like MS is behaving.
but it would be a bad idea IMO, as server's could deny access to them 
security wise.

daniel

/*--
daniel beulshausen - [EMAIL PROTECTED]
using php on windows? http://www.php4win.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] Bug #10376 Updated: abnormal program termination on imap_body($box,0)

[chagenbu]

ID: 10376
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: IMAP related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Fixed in 4.0.6-cvs.

Previous Comments:
---

[2001-04-18 08:32:17] [EMAIL PROTECTED]
if(!$box=imap_open('{localhost/pop3:110}INBOX','mybox','mypassword'))
die('Can't Open box!');

// Here is abnormal program termination
// I think returning of NULL is better solution
// imap_header is Ok (warning is generated)
$B=imap_body($box,0);

imap_close($box);

for PHP.INI see the bug #9819


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10376&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] Bug #10645: undefined versioned symbol name

[conillio]

From: [EMAIL PROTECTED]
Operating system: Debian 2.2
PHP version:  4.0.4pl1
PHP Bug Type: Compile Failure
Bug description:  undefined versioned symbol name

my configure line was
./configure --prefix=/usr/local/php \
--with-apxs=/usr/local/apache/apxs \
--with-mysql=/usr/local/mysql \
--with-pgsql=/usr/local/pgsql \
--with-GD

 ... and this is the line when i have compiled the 

module /usr/bin/ld: .libs/libphp4.so: undefined versioned symbol name 
__ns_name_unpack@@GLIBC_2.1
/usr/bin/ld: failed to set dynamic section sizes: Bad value
collect2: ld returned 1 exit status
make[1]: *** [libphp4.la] Error 1
make[1]: Leaving directory `/root/Src/php-4.0.4pl1'
make: *** [all-recursive] Error 1




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



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

[PHP-DEV] Bug #8452 Updated: imap_fetchstructure problem

[chagenbu]

ID: 8452
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: IMAP related
PHP Version: 4.0.4
Assigned To: 
Comments:

Is this still the case, and are you using an updated version of c-client?

Previous Comments:
---

[2000-12-28 09:03:32] [EMAIL PROTECTED]
when reading a mail which have no attachment (single part mail), 

imap_fetchstructure->type is always "text"
imap_fetchstructure->subtype is always "plain"

even if in the header we have

Content-Type: text/html

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8452&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] Bug #9242 Updated: base64_encode, decode and imap_binary

[chagenbu]

ID: 9242
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Mail related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

You may be doing something wrong in your script; there are many PHP webmail programs 
that generate attachments using those functions just fine.

Previous Comments:
---

[2001-02-13 12:44:53] [EMAIL PROTECTED]
when building mime attachments for emails with chunk_split(base64encode(something)) 
oder imap_binary(something) the rusult cant be read by the email clients. decoding of 
the result ends up in the same file then the original was. looks like some general 
error in encoding/decoding. when using an external routing in that srcipt (eg 
uuenview) to encode it and add the result into the mime email everything ´works fine.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9242&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] Bug #9602 Updated: Unable to compile with NSAPI support, implicit declaration of finite function

[avsm]

ID: 9602
Updated by: avsm
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: iPlanet related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

no feedback


Previous Comments:
---

[2001-04-25 13:24:48] [EMAIL PROTECTED]
Try the following obj.conf entry, and see if it fixes your problem.  Apart from this 
change, you should follow the manual entry for the rest of the obj.conf

Init fn="load-modules" shlib="/path/to/server4/bin/libphp4.so" 
funcs="php4_init,php4_close,php4_execute,php4_auth_trans"
Init fn="php4_init" LateInit="yes" 



---

[2001-03-08 07:12:45] [EMAIL PROTECTED]
Opp..

  The snapshot, compile ok, but crashes... ;((

  I have read the instrucctions on install.netscape-enterprise.php. But, when
  the server restart, then crashes with the message (from the admin server,
  because in the errors log file, don't write nothing!?!)

[https-pyxis]: start failed. (2: unknown early startup error)
[https-pyxis]: server terminated (signal 6): watchdog is restarting it 
[https-pyxis]: failure: server initialization failed 

I have a core from the ns-httpd proc.

My config.nice file:
#! /bin/sh
#
# Created by configure

"./configure" 
"--with-nsapi=/usr/netscape/server4/" 
"--enable-libgcc" 
"--without-mysql" 
"$@"

thankx, in advance, and sorry for mi english.

---

[2001-03-07 15:53:55] [EMAIL PROTECTED]
Fixed -> Closed.

--Jani


---

[2001-03-07 11:12:33] [EMAIL PROTECTED]


It's OK... I read the #9599 bug report and download the snapshot.

All OK.

Sorry... and thankx!!!

---

[2001-03-07 11:03:01] [EMAIL PROTECTED]
config.nice:
#! /bin/sh
#
# Created by configure

"./configure" 
"--enable-trans-id" 
"--enable-libgcc" 
"--enable-sigchild" 
"--enable-sysvsem" 
"--enable-sysvshm" 
"--with-nsapi=/usr/netscape/server4/" 
"--with-ldap=/usr/netscape/ldapsdk" 
"--with-informix" 
"--without-mysql" 
"--enable-discard-path" 
"$@"
--
error:
make[1]: Entering directory `/usr/local/distrib/php-4.0.4pl1/Zend'
/bin/sh ../libtool --silent --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../main   
-D_POSIX_PTHREAD_SEMANTICS -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DXML_BYTE_ORDER=21 
-I../TSRM  -g -O2 -pthreads -c zend_language_scanner_cc.cc
In file included from zend_language_scanner_cc.cc:2571:
zend_operators.h: In function `int is_numeric_string(char *, int, long int *, double 
*)':
zend_operators.h:84: implicit declaration of function `int finite(...)'
make[1]: *** [zend_language_scanner_cc.lo] Error 1
make[1]: Leaving directory `/usr/local/distrib/php-4.0.4pl1/Zend'
make: *** [all-recursive] Error 1


---

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=9602&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] Bug #8376 Updated: IPlanet 4.1 fails to load PHP module

[avsm]

ID: 8376
Updated by: avsm
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: iPlanet related
PHP Version: 4.0.4
Assigned To: 
Comments:

no feedback

Previous Comments:
---

[2001-04-25 13:24:03] [EMAIL PROTECTED]
Try the following obj.conf entry, and see if it fixes your problem.  Apart from this 
change, you should follow the manual entry for the rest of the obj.conf

Init fn="load-modules" shlib="/path/to/server4/bin/libphp4.so" 
funcs="php4_init,php4_close,php4_execute,php4_auth_trans"
Init fn="php4_init" LateInit="yes" 



---

[2000-12-22 09:29:37] [EMAIL PROTECTED]
I am having the same problem as described in bug report 5536.  libphp4.so seems to be 
compiling as a Netscape ES 3.x plugin, which loads ns-httpd functions at module 
initialization as opposed to IPlanet 4.x which loads them at runtime.  Tried using 
Netscape provided script to relink libphp4.so to load ns-httpd symbols at runtime to 
no avail (script failed).  Netscape claims changes need to be made to the Makefile to 
get plugins to link properly.  I am not sure how to do this.  Here's IPWS output:

[https-fradkin.btv.ibm.com]: start failed. (2: unknown early startup error)
  [https-fradkin.btv.ibm.com]: conf_init: Error running init function 
load-modules: dlopen of /web/iplanet/es.4.1sp5/bin/libphp4.so failed (
  0509-130 Symbol resolution failed for /web/iplanet/es.4.1sp5/bin/libphp4.so 
because: 
  [https-fradkin.btv.ibm.com]: 0509-136 Symbol __builtin_delete (number 198) is 
not exported from 
  [https-fradkin.btv.ibm.com]: dependent module ns-httpd. 
  [https-fradkin.btv.ibm.com]: 0509-136 Symbol __rtti_si (number 199) is not 
exported from 
  [https-fradkin.btv.ibm.com]: dependent module ns-httpd. 
  [https-fradkin.btv.ibm.com]: 0509-136 Symbol __rtti_user (number 200) is not 
exported from 
  [https-fradkin.btv.ibm.com]: dependent module ns-httpd. 
  [https-fradkin.btv.ibm.com]: 0509-192 Examine .loader section symbols with the 
  [https-fradkin.btv.ibm.com]: 'dump -Tv' command.) 
  [https-fradkin.btv.ibm.com]: server exit: status 1

PHP configured with --with-mysql=/pathtomysql --enable-libgcc 
--with-nsapi=/pathtoiplanet

Thanks!

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8376&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] Bug #9612 Updated: iPlanet 4.0 SP3 install obj.conf

[avsm]

ID: 9612
Updated by: avsm
Reported By: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Closed
Bug Type: iPlanet related
PHP Version: 4.0 Latest CVS (07/03/2001)
Assigned To: 
Comments:



Previous Comments:
---

[2001-04-25 13:22:56] [EMAIL PROTECTED]
Try the following obj.conf entry, and see if it fixes your problem.  Apart from this 
change, you should follow the manual entry for the rest of the obj.conf

Init fn="load-modules" shlib="/path/to/server4/bin/libphp4.so" 
funcs="php4_init,php4_close,php4_execute,php4_auth_trans"
Init fn="php4_init" LateInit="yes" 



---

[2001-03-07 22:16:54] [EMAIL PROTECTED]
Seems no matter what version of 4.0.4 (where I started) and up I can not get the 
Netscape/iPlanet Enterprise server 4.0 SP3 to load properly.  We are currently using 
version 3.x in cgi mode and would like it embeded if possible.  I have seen similar 
problems but with no real solution posted.  I will eventually need to add Oracle, 
Mysql, and LDAP modules included but since I couldn't get it to work, I decided to 
limit what was being included in the nsapi module.  I think I have limited it to as 
little as possible.  The following is what I last tried and it still did not work.  If 
I remove the lines from the obj.conf file that references the php module the server 
starts with out a problem.  I also modified the start script to include the 
LD_LIBRARY_PATH additional directories so they should not be the problem.  The Error 
log reports nothing out of the ordinary.

Try a basic configure...  (using hints I found in the bug database - I am assuming the 
following is correct)  

./configure --with-nsapi=/usr/local/netscape/server4 --without-mysql --enable-libgcc 
--enable-experimental-zts

configure completes no problem.
make... compiles.  Except I notice...
nsapi.c: In function `nsapi_request_dtor':
nsapi.c:440: warning: passing arg 1 of `nsapi_free' discards qualifiers from pointer 
target type
nsapi.c:442: warning: passing arg 1 of `nsapi_free' discards qualifiers from pointer 
target type

I ignore the warnings...

make install... Installs no errors.

Using Administration web port I attempt to start the server but every time it returns 
the following:

Status: 
[https-phphelpdesk]: start failed. (2: unknown early startup error)
[https-phphelpdesk]: server terminated (signal 6): watchdog is restarting it 
[https-phphelpdesk]: failure: server initialization failed 

Error
An error occurred during startup.
The server https-phphelpdesk was not started.

I would like to use the php module.  Please, if anyone knows any working 
configurations of iPlanet Enterprise Server on Solaris working with PHP 4.x let me 
know how you did it.

Thanks,
Brian Gregg
University of Pittsburgh
University Library System
Pittsburgh, PA 15260






---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9612&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] Bug #9612 Updated: iPlanet 4.0 SP3 install obj.conf

[avsm]

ID: 9612
Updated by: avsm
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: iPlanet related
PHP Version: 4.0 Latest CVS (07/03/2001)
Assigned To: 
Comments:

no feedback

Previous Comments:
---

[2001-04-25 13:22:56] [EMAIL PROTECTED]
Try the following obj.conf entry, and see if it fixes your problem.  Apart from this 
change, you should follow the manual entry for the rest of the obj.conf

Init fn="load-modules" shlib="/path/to/server4/bin/libphp4.so" 
funcs="php4_init,php4_close,php4_execute,php4_auth_trans"
Init fn="php4_init" LateInit="yes" 



---

[2001-03-07 22:16:54] [EMAIL PROTECTED]
Seems no matter what version of 4.0.4 (where I started) and up I can not get the 
Netscape/iPlanet Enterprise server 4.0 SP3 to load properly.  We are currently using 
version 3.x in cgi mode and would like it embeded if possible.  I have seen similar 
problems but with no real solution posted.  I will eventually need to add Oracle, 
Mysql, and LDAP modules included but since I couldn't get it to work, I decided to 
limit what was being included in the nsapi module.  I think I have limited it to as 
little as possible.  The following is what I last tried and it still did not work.  If 
I remove the lines from the obj.conf file that references the php module the server 
starts with out a problem.  I also modified the start script to include the 
LD_LIBRARY_PATH additional directories so they should not be the problem.  The Error 
log reports nothing out of the ordinary.

Try a basic configure...  (using hints I found in the bug database - I am assuming the 
following is correct)  

./configure --with-nsapi=/usr/local/netscape/server4 --without-mysql --enable-libgcc 
--enable-experimental-zts

configure completes no problem.
make... compiles.  Except I notice...
nsapi.c: In function `nsapi_request_dtor':
nsapi.c:440: warning: passing arg 1 of `nsapi_free' discards qualifiers from pointer 
target type
nsapi.c:442: warning: passing arg 1 of `nsapi_free' discards qualifiers from pointer 
target type

I ignore the warnings...

make install... Installs no errors.

Using Administration web port I attempt to start the server but every time it returns 
the following:

Status: 
[https-phphelpdesk]: start failed. (2: unknown early startup error)
[https-phphelpdesk]: server terminated (signal 6): watchdog is restarting it 
[https-phphelpdesk]: failure: server initialization failed 

Error
An error occurred during startup.
The server https-phphelpdesk was not started.

I would like to use the php module.  Please, if anyone knows any working 
configurations of iPlanet Enterprise Server on Solaris working with PHP 4.x let me 
know how you did it.

Thanks,
Brian Gregg
University of Pittsburgh
University Library System
Pittsburgh, PA 15260






---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9612&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] Bug #10356 Updated: imap_utf7_encode cann't encode Chinese correctly

[chagenbu]

ID: 10356
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Status: Open
Old-Bug Type: Mail related
Bug Type: IMAP related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

reclassifying

Previous Comments:
---

[2001-04-16 22:46:59] [EMAIL PROTECTED]
I try to use the imap_utf7_encode and imap_utf_decode to
decode and encode the example in RFC2060. But they are
not correct. 
I compile with the c-client of imap2000a.

example¡G
echo imap_utf7_decode('&U,BTFw-');
echo imap_utf7_encode('¥x¥_');



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10356&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] Bug #7486 Updated: imap_uid does not return the uid

[chagenbu]

ID: 7486
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: IMAP related
PHP Version: 4.0.2
Assigned To: 
Comments:

You might have the wrong idea of what uid is - what do you expect it to be? On pop 
servers the message uid will very likely just _be_ the message number...

Previous Comments:
---

[2000-10-27 03:30:55] [EMAIL PROTECTED]
When I call connect to a qmail pop server and call imap_uid all it does is return the 
message number back to me.  It DOES NOT return the uid.  I have to call imap_header 
for that and it is very slow.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=7486&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] Bug #9335 Updated: configure fails to add -lc-client

[chagenbu]

ID: 9335
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Status: Open
Old-Bug Type: IMAP related
Bug Type: Compile Failure
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

reclassifying

Previous Comments:
---

[2001-02-19 07:25:23] [EMAIL PROTECTED]
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.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9335&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] Bug #9461 Updated: imap_open crash when connecting to nntp with username and password

[chagenbu]

ID: 9461
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: IMAP related
PHP Version: 4.0 Latest CVS (26/02/2001)
Assigned To: 
Comments:

Can you try 4.0.6-cvs and see if Andi's strlcopy change had any affect on this?

Previous Comments:
---

[2001-05-02 16:49:11] [EMAIL PROTECTED]
From:  James Treleaven <[EMAIL PROTECTED]> 

Like the author of bug #9461, I also tracked the problem down to mm_login() in 
ext/imap/php_imap.c [that is where my stack was getting stomped].  I replaced the 
later two calls to strncpy() in the function, with calls to strcpy(), and now I can 
use the function to login to news servers with no 
problem! 

The code in mm_login() looks correct to me - but I cannot believe that there is a bug 
in Linux's libc.a:strncpy(). I have a web based gateway up and running with hundreds 
of user's using my modified imap_open() to successfully connect to nntp with their 
usernames and passwords (we always require authentication).  My modification seems to 
be a good workaround - but I don't know why. 

---

[2001-02-26 08:36:22] [EMAIL PROTECTED]
function that causes crash

imap_open('{newsserver/nntp}'.'test.test','username','password') || die("can't 
connect: ".imap_last_error());



backtrace from gdb ( i know it says nothing but i did as described in the backtrace 
faq.)
#0  0x0 in ?? ()

I have a problem with imap_open:
I can do imap_open on nntp server that has no authentication. But when i try on
a nntpserver that requires a password.. php dumps core (signal 11 gdb backtrace
is #0 0x0 in ?? ()) ( i executed the cgi version of php to be sure that apache
has nothing to do with it.)
i tested c-client with the mtest program and it worked perfectly.
I've tried to compile php4 with -enable-debug but i'm not so experienced with
gdb so when i load the core-file i still get no symbols or references to the
instruction that causes the problem.
it should be simple to test:


try to connect to a nntp server without username and password
try to connect to a nntp server that requires username and password


i have looked through the c-client code and the php4 extension and i could
imagine the problem might be in mm_login but i'm not certain.


the server is running:
php4.0.5-dev latest cvs
linux 2.2.12-20smp
imap (imap-2001.BETA.SNAP-0102201858) also tried (imap-4.7c)
All help is appreciated and if anybody wants more information or maybe a test
nntp account i can provide that (just send me a mail [EMAIL PROTECTED]).

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9461&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] MySQL related

[Stig Sæther Bakken]

[Hien Duy Nguyen <[EMAIL PROTECTED]>]
> From: [EMAIL PROTECTED]
> Operating system: RH7.1
> PHP version:  4.0 Latest CVS (03/05/2001)
> PHP Bug Type: MySQL related
> Bug description:  can't make connection to Mysql DB
> 
> Warning: MySQL Connection Failed: Can't connect to local MySQL server
> through socket '/var/lib/mysql/mysql.sock' (111) in
> /home/hdn/public_html/test.html on line 11
> Couldn't connect to MySQL
> 
> Mysql server is up and running, I can connect to it with shell command.

The MySQL client that comes with PHP has a different default mysql
socket configured than the RedHat-installed MySQL.  Run as root:

echo 'ln -s /var/lib/mysql/mysql.sock /tmp/mysql.sock' >> /etc/rc.d/rc.local
eval `tail -1 /etc/rc.d/rc.local`

 - Stig

-- 
  Stig Sæther Bakken <[EMAIL PROTECTED]>
  Fast Search & Transfer ASA, Trondheim, Norway

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

[PHP-DEV] Bug #5084 Updated: imap_mail_compose produces a SigSegv

[chagenbu]

ID: 5084
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Assigned
Status: Feedback
Bug Type: IMAP related
PHP Version: 4.0 Release Candidate 2
Assigned To: sniper
Comments:

Can you test this with 4.0.6-cvs? It is very likely fixed now.

Previous Comments:
---

[2000-07-29 23:04:42] [EMAIL PROTECTED]
I made a partial fix to this which is committed into the CVS. But there is still some 
bugs in this. 

For now at least the script below works:



I will write some kind of documentation of this soon as possible.

--Jani

---

[2000-07-29 02:49:38] [EMAIL PROTECTED]
IMAP related. 

--Jani

---

[2000-07-29 02:43:54] [EMAIL PROTECTED]
Same as #3337

--Jani

---

[2000-06-16 17:11:06] [EMAIL PROTECTED]
n";
$env = array("From: [EMAIL PROTECTED]");
$body = array("Part 1");

print imap_mail_compose($env,$body);
?>


./configure  --with-apache=../apache_1.3.9 --with-ldap=/opt/ldap
--with-gdbm --with-imap=/opt/apache/apache/src/c-client/imap-4.7b/ --with-zlib 
--enable-sysvshm

gdb backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x80ae8a6 in php_if_imap_mail_compose (ht=2, return_value=0x839834c, this_ptr=0x0, 
return_value_used=1) at php_imap.c:3094
3094bod->nested.part=mail_newbody_part();
(gdb) bt
#0  0x80ae8a6 in php_if_imap_mail_compose (ht=2, return_value=0x839834c, this_ptr=0x0, 

return_value_used=1) at php_imap.c:3094
#1  0x81038dc in execute (op_array=0x83971d4) at ./zend_execute.c:1574
#2  0x8087fab in php_execute_script (primary_file=0xbbec) at main.c:1200
#3  0x80a2b20 in apache_php_module_main (r=0x837f674, fd=40, display_source_mode=0)
at sapi_apache.c:93
#4  0x80844db in send_php ()
#5  0x808451c in send_parsed_php ()
#6  0x8150263 in ap_invoke_handler ()
#7  0x81639b9 in process_request_internal ()
#8  0x8163a1c in ap_process_request ()
#9  0x815b34e in child_main ()
#10 0x815b4fc in make_child ()
#11 0x815b659 in startup_children ()
#12 0x815bc86 in standalone_main ()
#13 0x815c419 in main ()
#14 0x400f6cb3 in __libc_start_main (main=0x815c0cc , argc=2, argv=0xbda4, 
init=0x8082928 <_init>, fini=0x822b90c <_fini>, rtld_fini=0x4000a350 <_dl_fini>, 
stack_end=0xbd9c) at ../sysdeps/generic/libc-start.c:78


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=5084&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] Bug #9209 Updated: imap_fetchstructure doesnt return envelope of 'message/rfc822'-subparts

[chagenbu]

ID: 9209
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: IMAP related
PHP Version: 4.0.4
Assigned To: 
Comments:

Ryan's comment describes the way to get at this info in c-client.

Previous Comments:
---

[2001-03-22 16:06:13] [EMAIL PROTECTED]
From: Ryan Finnie [mailto:[EMAIL PROTECTED]]

I saw your bug report on bugs.php.net -- pity a 3rd party can't add comments or I 
would have posted that there.

Anyways, php uses the c-client library, which can be broken in some aspects.  To get 
information about the envelope, you would need to do 
imap_rfc822_parse_headers(imap_fetchbody($mbox, $msgid, "$part.0"));

In your example in the bug, $part would be "2".  This will return an object similar to 
imap_headerinfo (IE, grabbing the envelope from the main message).  Technically, 
according to the RFC, you should grab $part.HEADER, not $part.0 -- but like I said, 
c-client is a bit screwy.  I left an explanation of that part of the problem in
http://php.net/manual/en/function.imap-fetchbody.php

Please let me know if this helps.
Ryan Finnie

---

[2001-02-10 20:49:04] [EMAIL PROTECTED]
When i connect directly via telnet to my IMAP-Server, 'fetch n (bodystructure)' 
returns the envelope of subparts with the type 'message/rfc822', as described in RFC 
2060. (I do not mean the envelope of the main-part!)

But when i call imap_fetchstructure via PHP, i do NOT get any envelope?!

Is there any other way to get these envelopes? Now i have to download the whole 
message and parse it myself. But this of course is very slow in PHP ;)

--- IMAP-Server Reply ---
BODYSTRUCTURE
(
  (
"TEXT" "PLAIN" ("CHARSET" "iso-8859-1")
NIL NIL "7BIT" 9 1 NIL NIL NIL
  )
  (
"MESSAGE" "RFC822" ("NAME" "Submail.eml")
NIL NIL "7BIT" 335
(
  "Sun, 11 Feb 2001 02:28:41 +0100"
  "Submail"
  (("Tester" NIL "Tester" "host"))
  (("Tester" NIL "Tester" "host"))
  (("Tester" NIL "Tester" "host"))
  ((NIL NIL "Test" ".MISSING-HOST-NAME."))
  NIL NIL NIL NIL
)
(
  "TEXT" "PLAIN" ("CHARSET" "iso-8859-1")
  NIL NIL "7BIT" 9 1 NIL NIL NIL
)
13 NIL ("ATTACHMENT" ("FILENAME" "Submail.eml")) NIL
  )
  "MIXED" ("BOUNDARY" "123") NIL NIL
)

--- PHP imap_fetchstructure Result (shortened) ---
obj [
  "type" = 1
  "subtype" = "MIXED"
  "parameters" = arr {
0 = obj ["attribute" = "BOUNDARY" "value" = "123"]
  }
  "parts" = arr {
0 = obj [
  "subtype" = "PLAIN"
  "lines" = 1
  "bytes" = 9
  "parameters" = arr {
0 = obj ["attribute" = "CHARSET" "value" = "iso-8859-1"]
  }
]
1 = obj [
  "type" = 2
  "subtype" = "RFC822"
  "lines" = 13
  "bytes" = 335
  "disposition" = "ATTACHMENT"
  "dparameters" = arr {
0 = obj ["attribute" = "FILENAME" "value" = "Submail.eml"]
  }
  "parameters" = arr {
0 = obj ["attribute" = "NAME" "value" = "Submail.eml"]
  }
  "parts" = arr {
0 = obj [
  "subtype" = "PLAIN"
  "lines" = 1
  "bytes" = 9
  "parameters" = arr {
0 = obj ["attribute" = "CHARSET" "value" = "iso-8859-1"]
  }
]
  }
]
  }
]

--- Mail Sourcecode (shortened) ---
From: "Tester" 
To: "Someone"
Subject: Mailmail
Date: Sun, 11 Feb 2001 02:29:12 +0100
Content-Type: multipart/mixed;
boundary="123"

This is a multi-part message in MIME format.

123
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Content

123
Content-Type: message/rfc822; name="Submail.eml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="Submail.eml"

From: "Tester" 
To: "Test"
Subject: Submail
Date: Sun, 11 Feb 2001 02:28:41 +0100
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Content

123--


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9209&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] Bug #8625 Updated: can not use imap_open to authenticate with a pop3 server

[chagenbu]

ID: 8625
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: IMAP related
PHP Version: 4.0.3pl1
Assigned To: 
Comments:

Does it work if you specify a port number explicitly?

Previous Comments:
---

[2001-01-10 03:09:01] [EMAIL PROTECTED]
Below is how I call the imap_open function. It works in linux but not BSDI 4.1. Please 
help.

$this->mbox = imap_open("{" . $this->hostname . "/" . $this->protocol . "}
", $this->username, $this->password);


list of module:
'./configure' '--with-apache=../apache_1.3.12' '--with-mysql' '--with-imap' 
'--enable-track-vars'



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8625&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] Bug #9333 Updated: imap_fetchstructure()

[chagenbu]

ID: 9333
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: IMAP related
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

no feedback from user.

Previous Comments:
---

[2001-02-19 11:16:16] [EMAIL PROTECTED]
Can you please use more words to describe this problem, and perhaps provide some 
example code and an example message?

---

[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] Bug #8481 Updated: imap_rfc822_parse_adrlist is too STRICT

[chagenbu]

ID: 8481
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: IMAP related
PHP Version: 4.0.4
Assigned To: 
Comments:

This is the behavior of the underlying c-client function. If you want looser parsing, 
see PEAR's Mail_RFC822 class, which among other things has an option to turn 
validation off.

Previous Comments:
---

[2000-12-29 12:44:41] [EMAIL PROTECTED]
Imap_rfc822_parse_adrlist is too strict: if a double ,, is present in addresslist, 
then the parsing fails and stops (and gives various SYNTAX-ERROR/INVALID HOST)
This is really annoying as many users type double ,, or even , , (a comma, a space, a 
comma) causing most of recipients to be dropped if Imap_rfc822_parse_adrlist is used.

Example:
imap_rfc822_parse_adrlist("smith,jeff,paul","foobar.com")
WORKS
  -BUT-
imap_rfc822_parse_adrlist("smith,,jeff,paul","foobar.com")
DOES NOT WORK: only "smith" is extracted, BUT jeff and paul aren't

Workaround: while exploding recipient list, just IGNORE empty recipient as if they 
didn't exist (and of course continue parsing)



---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8481&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] Bug #8359 Updated: imap_fetchheader and FT_PREFETCHTEXT

[chagenbu]

ID: 8359
Updated by: chagenbu
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: IMAP related
PHP Version: 4.0.4
Assigned To: 
Comments:

Fixed in 4.0.6-cvs.

Previous Comments:
---

[2000-12-21 12:23:55] [EMAIL PROTECTED]
Referring to bug #4447: (closed)
I think you introduced a bug when "solving" #4447.
I believe (as did the IMP developers) that imap_fetchheader should ALWAYS return ONLY 
the header.
The flag FT_PREFETCHTEXT is just for optimization and  informs c-client that the 
message text will be needed soon as well.


---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8359&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] Bug #10644: __FILE__ missing path delimiters

[chagenbu]

From: [EMAIL PROTECTED]
Operating system: Linux (Debian) 2.2
PHP version:  4.0.5
PHP Bug Type: Scripting Engine problem
Bug description:  __FILE__ missing path delimiters

With 4.0.6 latest cvs (not 4.0.5; is there a reason the latest cvs option in the 
versions menu is dated March?), __FILE__ is returning the filename with no path 
delimiters. For example, if the script is /var/www/foo.php, __FILE__ contains 
'varwwwfoo.php'.


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



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

[PHP-DEV] Bug #10574 Updated: Gets stuck on explode() when delimiter is not in the string

[andi]

ID: 10574
Updated by: andi
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Arrays related
PHP Version: 4.0.5
Assigned To: 
Comments:

I can't reproduce this on Windows either. Can you please try and run this from command 
line and see if it still creates problems? Without any prepends or anything

Previous Comments:
---

[2001-05-03 14:21:23] [EMAIL PROTECTED]
Maybe is a bug related to WIN NT ?
Do you need more info about the settings of my phpinfo() ?

---

[2001-05-02 23:19:23] [EMAIL PROTECTED]
I can't reproduce this with latest CVS on Linux using
the following test script:



--Jani


---

[2001-05-01 06:23:12] [EMAIL PROTECTED]
If I perform an 
explode(",",$str);
on
$str = "hi there this is a test";

Php gets "stuck" and can eventually bing the memroy of the server down.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10574&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 #4630 Updated: Segmentation fault(coredump) in apache startup

[david-shafer]

ID: 4630
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Compile Failure
Description: Segmentation fault(coredump) in apache startup

Still happening as of 4.0.5.

Previous Comments:
---

[2001-04-26 17:05:24] [EMAIL PROTECTED]
Still happening as of 4.0.4pl1. It seems like there's enough information to fix the 
problem, for somebody who knows the source code. Would someone be able to look at 
this? Is there any more information you need?

---

[2001-02-15 15:10:36] [EMAIL PROTECTED]
The segfault still occurs as of php4-200102131445.

---

[2000-12-18 10:55:46] [EMAIL PROTECTED]
Could you try the latest snapshot from http://snaps.php.net/
to see if this is fixed now?

--Jani

---

[2000-09-08 19:42:47] [EMAIL PROTECTED]
After forwarding the issue to a compiler expert at IBM, I received the fix below, 
which I've tested and confirmed. Does anyone know how best to implement this fix?

-
The point where you found the segment fault was when php_create_dir attempted to call 
ap_register_cleanup. As it happens, php_create_dir is in libphp4.so and 
ap_register_cleanup is in httpd. In order to make this work on AIX, httpd has to be 
bound with an export list and
libphp4.so has to be bound with an import list.

Fortunately, the Apache part is already set up correctly.  When you install apache on 
AIX, $PREFIX/libexec/httpd.exp is a correctly formatted import/export file.

The PHP4 part, however was not set up correctly. In fact it was set up in the worst 
possible way under the circumstances. If you were to attempt to naively bind 
libphp4.so, the linker would produce a fatal error because ap_register_cleanup is 
undefined. $PHP4/libtool (which
I believe is generated by configure) gets around this inconvenience by adding a 
-berrok linker option. (It's called ${allow_undefined_flag}) So, the linker on AIX 
basically leaves the reference to ap_register_cleanup untouched so the call branches 
to a pseudo-random piece of code. After that, bad things happen.

I'm running now because I manually changed $PHP4/libtool so that it contains these 
lines:

# Commands used to build and install a shared archive.
archive_cmds="$CC ${wl}-bM:SRE -o $objdir/$soname $libobjs $deplibs $linkopts 
${wl}-bexpall ${wl}-bI:/usr/local/apache/libexec/httpd.exp 
${wl}-bnoentry${allow_undefined_flag}"
archive_expsym_cmds="$CC ${wl}-bM:SRE -o $objdir/$soname $libobjs $deplibs $linkopts 
${wl}-bI:/usr/local/apache/libexec/httpd.exp ${wl}-bE:$export_symbols 
${wl}-bnoentry${allow_undefined_flag}"

The bit I added (in both lines) is:
${wl}-bI:/usr/local/apache/libexec/httpd.exp

I have no idea what the ${wl} is; I just copied the existing pattern. I hard coded 
/usr/local/apache/libexec/httpd.exp. Obviously, the real export file should be 
identifed using something like apxs, but I don't know how to do that.

At any rate, httpd has now been running for a while on my machine.

---

[2000-08-24 00:02:42] [EMAIL PROTECTED]
Here are the results from the latest version. The following have changed:

PHP 4-28230945

export CFLAGS="-g -ma"

./configure --enable-c9x-inline 
--enable-debug 
--prefix=/local/www/php 
--with-apxs=/local/www/bin/apxs 
--with-config-file-path=/local/www/php/etc 
--without-mysql

bud # ./httpd -X
Segmentation fault(coredump)

bud # dbx httpd
Type 'help' for help.
reading symbolic information ...
[using memory image in core]

Segmentation fault in php_save_umask at line 121 in file "" ($t1)
could not read "mod_php4.c"
(dbx) where   
php_save_umask(), line 121 in "mod_php4.c"
php_create_dir(p = 0x2001ef28, dummy = (nil)), line 556 in "mod_php4.c"
ap_single_module_configure(0x2001ef28, 0x2001ef50, 0x200b9db8), line 1500 in 
"http_config.c"
load_module(0x2ff22948, 0x0, 0x200432d0, 0x200432e0), line 282 in "mod_so.c"
invoke_cmd(0x2000f5e0, 0x2ff22948, 0x0, 0x2ff20920), line 818 in "http_config.c"
unnamed block $b14, line 1008 in "http_config.c"
ap_handle_command(0x2ff22948, 0x2001f480, 0x2ff208f0), line 1008 in "http_config.c"
unnamed block $b16, line 1022 in "http_config.c"
ap_srm_command_loop(0x2ff22948, 0x2001f480), line 1022 in "http_config.c"
ap_process_resource_config(0x2001ef50, 0x2001f608, 0x2001ef28, 0x20022f68), line 1202 
in "http_config.c"
ap_read_config(0x2001ef28, 0x20022f68, 0x200052a0), line 1481 in "http_config.c"
http_main.main(argc = 2, argv = 0x2ff22b3c), line 4955 in "http_main.c"
(dbx) quit

bud # gdb httpd
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see 

[PHP-DEV] DOMXML maintainer

[Joseph Tate]

Who is the domxml maintainer?  I would like to make some of the functions a
little more useful/robust, less verbose (about warning messages, and so
forth).

Joseph


-- 
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: Jeremy Jones
Email: [EMAIL PROTECTED]
ID: jjones
Purpose: Karma to edit bug reports

-- 
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 #10635 Updated: fopen

[jhurshman]

ID: 10635
User Update by: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Filesystem function related
Description: fopen

I have solved the problem. It was not a bug, but rather a permission issue on the php 
executables.

Previous Comments:
---

[2001-05-03 11:28:04] [EMAIL PROTECTED]
I just upgraded one of my servers to 4.0.5, and am having a problem where any attempt 
to fopen a PHP file on that server via HTTP will fail.

>From another (4.0.4pl1 on Unix) PHP server if I try the following code:

$handle = fopen("http://405host/phpinfo.php";, "r");

I get the following error (and fopen returns false):

Warning: fopen("http://405host/phpinfo.php","r";) - Inappropriate ioctl for device in 
/path/read.php on line 8

If I try the same code from the 4.0.5 server, or from a 4.0.4pl1-on-NT server, fopen 
returns false with the following error message:

Warning: fopen("http://405host/phpinfo.php","r";) - No error in 
E:Inetpubwwwrootread.php on line 8

If I try the same code and attempt to open a plain HTML file or an ASP file, 
everything works fine. It's only when trying to open a PHP file that these mysterious 
errors occur.

I also have a ASP component that opens an HTTP connection to a URL and prints the 
returned HTML. This component also can no longer access any PHP files on the 4.0.5 
server.

---


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


-- 
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 #10574 Updated: Gets stuck on explode() when delimiter is not in the string

[xyztheweb]

ID: 10574
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Arrays related
Description: Gets stuck on explode() when delimiter is not in the string

Maybe is a bug related to WIN NT ?
Do you need more info about the settings of my phpinfo() ?

Previous Comments:
---

[2001-05-02 23:19:23] [EMAIL PROTECTED]
I can't reproduce this with latest CVS on Linux using
the following test script:



--Jani


---

[2001-05-01 06:23:12] [EMAIL PROTECTED]
If I perform an 
explode(",",$str);
on
$str = "hi there this is a test";

Php gets "stuck" and can eventually bing the memroy of the server down.

---


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


-- 
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-QA] Re: 4.0.6

[Zak Greant]

Jani wrote:
> 
> Maybe we should have something like the terrorist cells?
> ie. groups of 3 persons who know only about the one above them?
>
>X
>  __|_
> /\
>a  b
>  / | \   / \
> c (d) e e   g
>
[...]
> 

Wow this sounds like one of my ideas Jani.  :)

All we need now are some phpqat_tree_balance, phpqat_tree_...
functions and we are good to go! ;)

Seriously, IMO, this would be something fun to test off list
in one of the lags between a RC. We might learn something
neat and we might come up with a bunch of useless but
wickedly funny TLAs. :)

> >>4.0.5 took very long to release, and it seems like it could
> >>have been released a month ago - pl1 is inevitable anyway.
> >I don't see a pl1 happening. We will go right to 4.0.6.
>
> Why would we need a pl? As there really isn't anything that
> broken which would need it? (nothing that broken that wasn't
> broken before)
>
> >I don't think that the QA team is a joke just because they can't
> >necessarily pull the plug on a release. Don't forget that a lot of the QA
>
> Yes it is. As long as there is less than 5 persons who can decide
> on this, QA is a joke.
>
> >Anyway, why are we continuing to waste time on this instead of fixing
bugs
> >and emptying the bugs database.
>
> At last he gets to the point! :)


After taking the time to really think about the current state
of the QA process, I think that we are doing just fine.

Our current process is better than the old process (aka none)

Now, each of us is smart enough to be able to single-handedly
rework the process into a perfect shining vision of how
QA should run. ;)  However, as a group, we have to be
moderate - or perhaps to rephrase that, we can't ramrod
changes past Zeev. ;)

Those of us who want to improve the process can do so by
watching the areas that matter to us.

I want to keep unneeded changes out of the RC process.
My opinion on RCs is like my mother's opinion on dinner:

Don't heap up your plate so much, you can always
go back for seconds.

So, I should watch CVS and squeal when anything non
bug related comes down the pipe.

If I do this regularly, I would guess that I would
have a much greater effect than any written set
of strict guidelines.

I think that if each of us takes a healthy interest
in the areas that matter to us and works to help
handle the relevant part of the process, we will find
that the process smooths out.

Take a look at who has made the most difference in how
we do things - it is not the people who make policies
for other people to follow.  It is the people who do
the work and in doing so, establish how others should
do it.

--zak


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

[PHP-DEV] Bug #10643: PHP 4.0.5 linked against openldap 2.x segfaults on Apache startup

[Edwin . Chiu]

From: [EMAIL PROTECTED]
Operating system: Linux 2.2.14
PHP version:  4.0.5
PHP Bug Type: LDAP related
Bug description:  PHP 4.0.5 linked against openldap 2.x segfaults on Apache startup

My configure string:

./configure  --prefix=/software/php-4 --with-apxs=/software/apache-1.3/bin/apxs 
--with-gdbm --with-ldap=/software/openldap-2 --with-pgsql=/software/postgresql-7 
--with-config-file-path=/software/php-4/lib

Using OpenLDAP 2.0.7 and PostgreSQL 7.1 on a SuSE 6.4 box.

# ldd libphp4.so 
libpam.so.0 => /lib/libpam.so.0 (0x40144000)
libdl.so.2 => /lib/libdl.so.2 (0x4014c000)
libpq.so.2 => /software/postgresql-7/lib/libpq.so.2 (0x4015)
libldap.so.2 => /software/openldap-2/lib/libldap.so.2 (0x4015f000)
liblber.so.2 => /software/openldap-2/lib/liblber.so.2 (0x40249000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40256000)
libresolv.so.2 => /lib/libresolv.so.2 (0x4025e000)
libm.so.6 => /lib/libm.so.6 (0x4026d000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4028a000)
libnsl.so.1 => /lib/libnsl.so.1 (0x402b7000)
libc.so.6 => /lib/libc.so.6 (0x402ce000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x8000)

Here is an strace of an Apache child that died. I'm using NSS_LDAP and PAM_LDAP.

open("/lib/libpthread.so.0", O_RDONLY)  = 4
fstat(4, {st_mode=S_IFREG|0755, st_size=289663, ...}) = 0
read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200?\0"..., 4096) = 4096
mmap(NULL, 75832, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x405aa000
mprotect(0x405b5000, 30776, PROT_NONE)  = 0
mmap(0x405b5000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0xa000) = 
0x405b5000
close(4)= 0
mprotect(0x40592000, 90112, PROT_READ|PROT_WRITE) = 0
mprotect(0x40592000, 90112, PROT_READ|PROT_EXEC) = 0
getpid()= 15900
getrlimit(RLIMIT_STACK, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
setrlimit(RLIMIT_STACK, {rlim_cur=2040*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys="Linux", node="oradev", ...}) = 0
rt_sigaction(SIGRT_0, {0x405b1c60, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x405b1d00, [], 0x400}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x405b1e20, [], 0x400}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RT_0], NULL, 8) = 0
munmap(0x402c8000, 28943)   = 0
geteuid()   = 0
getpid()= 15900
open("/etc/ldap.conf", O_RDONLY)= 4
fstat(4, {st_mode=S_IFREG|0644, st_size=213, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000
read(4, "# $Id$\n\nhost 192.168.0.1\nbase o="..., 4096) = 213
read(4, "", 4096)   = 0
close(4)= 0
munmap(0x40015000, 4096)= 0
uname({sys="Linux", node="oradev", ...}) = 0
open("/etc/hosts", O_RDONLY)= 4
fcntl(4, F_GETFD)   = 0
fcntl(4, F_SETFD, FD_CLOEXEC)   = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=708, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000
read(4, "#\n# hosts This file desc"..., 4096) = 708
close(4)= 0
munmap(0x40015000, 4096)= 0
getrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
open("/software/openldap-2/etc/openldap/ldap.conf", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=337, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000
read(4, "# $OpenLDAP: pkg/ldap/libraries/"..., 4096) = 337
read(4, "", 4096)   = 0
close(4)= 0
munmap(0x40015000, 4096)= 0
open("/root/ldaprc", O_RDONLY)  = -1 ENOENT (No such file or directory)
open("/root/.ldaprc", O_RDONLY) = -1 ENOENT (No such file or directory)
open("ldaprc", O_RDONLY)= -1 ENOENT (No such file or directory)
uname({sys="Linux", node="oradev", ...}) = 0
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 4
ioctl(4, FIONBIO, [1])  = 0
connect(4, {sin_family=AF_INET, sin_port=htons(389), 
sin_addr=inet_addr("192.168.0.1")}}, 16) = -1 EINPROGRESS (Operation now in progress)
select(1024, NULL, [4], NULL, NULL) = 1 (out [4])
getpeername(4, {sin_family=AF_INET, sin_port=htons(389), 
sin_addr=inet_addr("192.168.0.1")}}, [16]) = 0
ioctl(4, FIONBIO, [0])  = 0
brk(0x811e000)  = 0x811e000
time(NULL)  = 988912101
write(4, "0\f\2\1\1`\7\2\1\2\4\0\200\0", 14) = 14
select(1024, [4], [], NULL, NULL)   = 1 (in [4])
read(4, "0\f\2\1\1a\7\n\1\0\4\0\4\0", 16384) = 14
time(NULL)  = 988912101
geteuid()   = 0
getpid()= 15900
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
getpeername(135365352, 0xbfffef1c, [1025]) = -1 

[PHP-DEV] Bug #10642 Updated: error connecting to database

[cynic]

ID: 10642
Updated by: cynic
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Duplicate
Bug Type: *Install and Config
PHP Version: 4.0.5
Assigned To: 
Comments:

duplicate of #10612

Previous Comments:
---

[2001-05-03 13:57:05] [EMAIL PROTECTED]
Identical problem as Bug#10612.

I installed the CVS php4-200105030445 and still have the same problem.

Your help would be appreciated.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10642&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] Bug #10638: exec(), system(), ... without reply

[Andi Gutmans]

At 07:42 PM 5/3/2001 +0200, Daniel Beulshausen wrote:
>At 19:24 03.05.2001 +0200, Daniel Beulshausen wrote:
>>At 20:04 03.05.2001 +0300, Andi Gutmans wrote:
>>>At 12:59 PM 5/3/2001 -0400, Joe Brown wrote:
echo typically is not a program.
It is a command in the CMD.exe or COMMAND.com programs.

$output=exec("cmd -c echo hello"); //should produce the desired effect.

Why piping output to a file changes this fact, is beyond me.
>>>
>>>The definition of exec() is that it uses popen() which starts a shell 
>>>automatically. Anyway, the problem was very Windows specific and doesn't 
>>>have anything to do with the syntax he used.
>>
>>right now we are executing the programm direct, without creating a console.
>>maybe we should manage a list of internal commands, like echo, dir, 
>>copy,... and create  a console for them...
>
>no it's a bad idea, i'll shut up :)
>cmd line parsing is a pretty bad idea, and the user is better of doing
>passthru( getenv("COMSPEC") . " /c echo")

Ouch but then the fix isn't popen() compatible.

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] Bug #10642: error connecting to database

[miller]

From: [EMAIL PROTECTED]
Operating system: RH 6.2
PHP version:  4.0.5
PHP Bug Type: *Install and Config
Bug description:  error connecting to database

Identical problem as Bug#10612.

I installed the CVS php4-200105030445 and still have the same problem.

Your help would be appreciated.


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