Re: [PHP-DEV] New Build System Committed to HEAD

[Boian Bonev]

> For some reason ncurses ends up twice in internal_functions_cli.c; I 
> can't figure out why though:
> 
> phpext_overload_ptr,
> phpext_ncurses_ptr,
> phpext_ncurses_ptr,
> phpext_mysql_ptr,

xmm. i couldn't verify this... (updated before 10-20 minutes)

phpext_overload_ptr,
phpext_ncurses_ptr,
phpext_mysql_ptr,

> 
> Derick

b.


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

Re: Re[2]: [PHP-DEV] [NEW EXTENSTION]: templates

[Boian Bonev]

hi Daniel,

> when I look at /ext/ (PHP source) just to pick a random example:
> what's 'vpopmail' doing there (no personal offense to the author,
> really randomly picked)? I mean, vpopmail has it's own deamon and an
> interface written in PHP (ok, that one is ugly, it depends on global
> variables and has to be rewritten), but why create a /compiled/ module
> for this? doesn't make sense to me. no gain in performance. and even
> the module is WORSE than the PHP interface, because it requires you to
> run PHP as CGI binary, fiddling around with sudo etc.. (whereas the
> PHP just opens a socket to the vpopmail-daemon, sends some commands
> etc..)

i would not like to put any offense but you are technicaly wrong - the
fastest way to access vpopmail functionality is to call native api instead
execute something external. this can be observed on high loaded servers of
course. one cannot skip the sudo stuff with vpopmail anyway - you must be
root to manage domains, and at least vpopmail to manage users. when one
really need to manage vpopmail at high web load she can compile a separate
apache for the management site and run it under vpopmail instead using slow
CGIs. prehapse you mess vpopmail with vmailmgr - the first one have
management daemon, second does not (at least an official one). the third
reason is the unified interface - vpopmail command line tools differ between
versions and one have to tweak her script for each different version.

about the first part of your email - i would vote with two hands for PEAR
repository of php modules written in C, vpopmail extension's place is
definitely there

> anyone interested in /ext/daniel/ printing out some greetings to my
> friends? how about daniel_greet_his_friends(); and
> daniel_send_email_to_his_friends(), etc?

:))

b.


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

Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity

[Boian Bonev]

> BB>> why not => then. imo the parser will easily distinguish array
> BB>> definition from an expression
> The last thing we need is symbol reuse. The parser can distinguish a lot
> of things, the problem is that the human developer would be confused. =>
> has a clear meaning in PHP, adding other meaning to it would have very
> high WTF factor for the developer.

sure. the F'ed WTF... :)

anyway this is a better solution if the best syntax :: makes stuff slow.

thinking in general a namespace is very close to a class, so if there's no
tech reasons not to make a single implementation of both it'd be perfect

b.


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

Re: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity

[Boian Bonev]

why not => then. imo the parser will easily distinguish array definition
from an expression

b.

- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Zeev Suraski" <[EMAIL PROTECTED]>; "Stig Sæther Bakken" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, September 30, 2001 11:02 PM
Subject: [PHP-DEV] Re: [Zend Engine 2] Re: [PHP-DEV] namespaces ambiguity


Well the difference is that C++ can figure out what to do at compile-time.
I don't think we can which means that it would put more logic into run-time
which is a bad thing IMO (especially for something new like this).
Or can you think of a way to differ between these at compile-time?
Andi

At 09:56 PM 9/30/2001 +0200, Zeev Suraski wrote:
>:: is taken, but why not do it the C++ way?  It also uses :: for both
>classes and namespaces.
>
>Zeev
>
>At 21:35 30-09-01, Stig Sæther Bakken wrote:
>>[Andi Gutmans <[EMAIL PROTECTED]>]
>> > Hey,
>> >
>> > I just started playing around with the parser to support the
>> > namespaces syntax Stig laid out in his RFC. I think I've thought of an
>> > ambiguity (with constants) which makes me wonder how feasible the
>> > proposed syntax is.
>> > Consider the following expression:
>> > $test?FOO:BAR:BARBARA
>> >
>> > Would this mean that the person meant $test?(FOO):(BAR:BARBARA) or
>> > $test?(FOO:BAR):BARBARA?
>>
>>Okay, is there another character we can use?  Doesn't look that way.
>>Maybe we need to use two characters then?  Since both "::" and "->"
>>are taken, "//" is the best suggestion I can come up with.
>>
>>  - 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 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 id #11998 - source code patch - Dont Use Previous (fwd)

[Boian Bonev]

indeed boyer-moore is slower for short strings...

anyway i have made a patch that addresses both mac/unix/dos line endings and
also works with files that have different endings inside (imagine a file
created on *nix edited under windows), which is a very common case.

it is slightly slower than current ver (89 seconds before patch/92 seconds
after patch for a very big test) but makes stuff more compatible.

b.




- Original Message -
From: "Derick Rethans" <[EMAIL PROTECTED]>
To: "Andi Gutmans" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, September 21, 2001 8:14 PM
Subject: Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous
(fwd)


> On Fri, 21 Sep 2001, Andi Gutmans wrote:
>
> > Seems like boyer_str_to_str() is buggy. If I change it to
php_str_to_str()
> > it seems to work.
> > I think Sascha added this function but I might be wrong.
>
> When I added some support for MAC line endings, I was told
> boyer_str_to_Str() was the faster method... so I choose that one. Not
> knowing that it was still experimental. Maybe place a comment about things
> being experimental in the source next time would guard against this kind
> of problems
>
> Derick
>
> >
> > Andi
> >
> > At 06:46 PM 9/21/2001 +0300, Boian Bonev wrote:
> > >please check bug id 13385, i hope that this is my mistake or
inappropriate
> > >build, but if i am not wrong, it is a serious thing...
> > >
> > >in short  hangs
with
> > >latest cvs.
> > >
> > >b.
> > >
> > >- Original Message -
> > >From: "Andi Gutmans" <[EMAIL PROTECTED]>
> > >To: <[EMAIL PROTECTED]>
> > >Sent: Friday, September 21, 2001 6:18 PM
> > >Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use
> > >Previous (fwd)
> > >
> > >
> > > > Guys,
> > > >
> > > > I think this is the last problem which is holding up RC3 and
hopefully
> > >4.0.7.
> > > >
> > > > Does anyone here know the code in rfc1867? I don't know it well
enough in
> > > > order to decide if this patch is OK or not.
> > > > If no one answers I'll apply it and we should as the QA guys to test
file
> > > > uploads extensively in RC3.
> > > >
> > > > Andi
> > > >
> > > > >Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST)
> > > > >From: Jani Taskinen <[EMAIL PROTECTED]>
> > > > >Sender: <[EMAIL PROTECTED]>
> > > > >To: <[EMAIL PROTECTED]>
> > > > >Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use
Previous
> > >(fwd)
> > > > >
> > > > >
> > > > >Could someone who knows the current code better
> > > > >check this out and apply this patch?
> > > > >
> > > > >My work for the other issues is not done yet..and it's too
> > > > >big of a change for this release.
> > > > >
> > > > >--Jani
> > > > >
> > > > >
> > > > >
> > > > >-- Forwarded message --
> > > > >Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST)
> > > > >From: Ralf Bolte <[EMAIL PROTECTED]>
> > > > >To: [EMAIL PROTECTED]
> > > > >Cc: [EMAIL PROTECTED]
> > > > >Subject: Bug id #11998 - source code patch - Dont Use Previous
> > > > >
> > > > >Sorry Sorry Sorry,
> > > > >
> > > > >about an hour ago i send you my patch for the critical BUG with the
ID
> > > > >11998.
> > > > >Unfourtunately, i sent a totally fucked up patch (file). DO NOT
APPLY it.
> > > > >Here is the correct patch, with some additional checks and with the
> > > > >header end check finally working. Sorry for my mistake ;) My only
apology
> > > > >is, that
> > > > >it is deep midnight here in germany *g*
> > > > >
> > > > >Yours,
> > > > >Ralf
> > > > >
> > > > >PS: as a side effect of my patch, the 30 files crash bug is fixed,
too :)
> > > > >
> > > > >
> > > > >--- Weitergeleitete Nachricht / Forwarded Message ---
> > > > >Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST)
> > > > >From: Ralf Bolte <[EMAIL PROTECTED]>
> > > > >To: [EMAIL PROTECTED]
> > > > >Subject: Bug i

Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd)

[Boian Bonev]

currently i am rewriting the nl2br stuff. two reasons:

1. current ver does not handle nicely text with mixed dos/unix/mac line
endings
2. using generic str_replace for exactly 1 or 2 chars is really slower (IMHO
this is used too often to pay the 200-500 bytes code overhead)

when it is stable, i'll post a patch

b.

- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Boian Bonev" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: "Sascha Schumann" <[EMAIL PROTECTED]>
Sent: Friday, September 21, 2001 7:13 PM
Subject: Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous
(fwd)


> Seems like boyer_str_to_str() is buggy. If I change it to php_str_to_str()
> it seems to work.
> I think Sascha added this function but I might be wrong.
>
> Andi
>
> At 06:46 PM 9/21/2001 +0300, Boian Bonev wrote:
> >please check bug id 13385, i hope that this is my mistake or
inappropriate
> >build, but if i am not wrong, it is a serious thing...
> >
> >in short  hangs with
> >latest cvs.
> >
> >b.
> >
> >- Original Message -
> >From: "Andi Gutmans" <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Friday, September 21, 2001 6:18 PM
> >Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use
> >Previous (fwd)
> >
> >
> > > Guys,
> > >
> > > I think this is the last problem which is holding up RC3 and hopefully
> >4.0.7.
> > >
> > > Does anyone here know the code in rfc1867? I don't know it well enough
in
> > > order to decide if this patch is OK or not.
> > > If no one answers I'll apply it and we should as the QA guys to test
file
> > > uploads extensively in RC3.
> > >
> > > Andi
> > >
> > > >Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST)
> > > >From: Jani Taskinen <[EMAIL PROTECTED]>
> > > >Sender: <[EMAIL PROTECTED]>
> > > >To: <[EMAIL PROTECTED]>
> > > >Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use
Previous
> >(fwd)
> > > >
> > > >
> > > >Could someone who knows the current code better
> > > >check this out and apply this patch?
> > > >
> > > >My work for the other issues is not done yet..and it's too
> > > >big of a change for this release.
> > > >
> > > >--Jani
> > > >
> > > >
> > > >
> > > >-- Forwarded message --
> > > >Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST)
> > > >From: Ralf Bolte <[EMAIL PROTECTED]>
> > > >To: [EMAIL PROTECTED]
> > > >Cc: [EMAIL PROTECTED]
> > > >Subject: Bug id #11998 - source code patch - Dont Use Previous
> > > >
> > > >Sorry Sorry Sorry,
> > > >
> > > >about an hour ago i send you my patch for the critical BUG with the
ID
> > > >11998.
> > > >Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY
it.
> > > >Here is the correct patch, with some additional checks and with the
> > > >header end check finally working. Sorry for my mistake ;) My only
apology
> > > >is, that
> > > >it is deep midnight here in germany *g*
> > > >
> > > >Yours,
> > > >Ralf
> > > >
> > > >PS: as a side effect of my patch, the 30 files crash bug is fixed,
too :)
> > > >
> > > >
> > > >--- Weitergeleitete Nachricht / Forwarded Message ---
> > > >Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST)
> > > >From: Ralf Bolte <[EMAIL PROTECTED]>
> > > >To: [EMAIL PROTECTED]
> > > >Subject: Bug id #11998 - source code patch
> > > >
> > > > > Hello,
> > > > >
> > > > > today i browsed through the php bug database on the search for
> >critical
> > > > > bugs.
> > > > > I then saw Bug id #11998 which speaks of some bugs in rfc1867.c.
Due
> >to
> > > > > the
> > > > > fact i saw several flaws in the source code some time ago, i
patched
> >my
> > > > > version.
> > > > > I now send you my patch and the patch applied to the cvs snapshot
of
> > > > > today,
> > > > > that fixes several bugs...
> > > > >
> > > > > first and foremost the "fix" that went into 4.0.6 was not only
broken,
> >but
>

Re: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous (fwd)

[Boian Bonev]

please check bug id 13385, i hope that this is my mistake or inappropriate
build, but if i am not wrong, it is a serious thing...

in short  hangs with
latest cvs.

b.

- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 21, 2001 6:18 PM
Subject: Fwd: [PHP-DEV] Bug id #11998 - source code patch - Dont Use
Previous (fwd)


> Guys,
>
> I think this is the last problem which is holding up RC3 and hopefully
4.0.7.
>
> Does anyone here know the code in rfc1867? I don't know it well enough in
> order to decide if this patch is OK or not.
> If no one answers I'll apply it and we should as the QA guys to test file
> uploads extensively in RC3.
>
> Andi
>
> >Date: Tue, 18 Sep 2001 17:22:41 +0200 (CEST)
> >From: Jani Taskinen <[EMAIL PROTECTED]>
> >Sender: <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Subject: [PHP-DEV] Bug id #11998 - source code patch - Dont Use Previous
(fwd)
> >
> >
> >Could someone who knows the current code better
> >check this out and apply this patch?
> >
> >My work for the other issues is not done yet..and it's too
> >big of a change for this release.
> >
> >--Jani
> >
> >
> >
> >-- Forwarded message --
> >Date: Tue, 18 Sep 2001 03:21:52 +0200 (MEST)
> >From: Ralf Bolte <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Cc: [EMAIL PROTECTED]
> >Subject: Bug id #11998 - source code patch - Dont Use Previous
> >
> >Sorry Sorry Sorry,
> >
> >about an hour ago i send you my patch for the critical BUG with the ID
> >11998.
> >Unfourtunately, i sent a totally fucked up patch (file). DO NOT APPLY it.
> >Here is the correct patch, with some additional checks and with the
> >header end check finally working. Sorry for my mistake ;) My only apology
> >is, that
> >it is deep midnight here in germany *g*
> >
> >Yours,
> >Ralf
> >
> >PS: as a side effect of my patch, the 30 files crash bug is fixed, too :)
> >
> >
> >--- Weitergeleitete Nachricht / Forwarded Message ---
> >Date: Tue, 18 Sep 2001 02:05:42 +0200 (MEST)
> >From: Ralf Bolte <[EMAIL PROTECTED]>
> >To: [EMAIL PROTECTED]
> >Subject: Bug id #11998 - source code patch
> >
> > > Hello,
> > >
> > > today i browsed through the php bug database on the search for
critical
> > > bugs.
> > > I then saw Bug id #11998 which speaks of some bugs in rfc1867.c. Due
to
> > > the
> > > fact i saw several flaws in the source code some time ago, i patched
my
> > > version.
> > > I now send you my patch and the patch applied to the cvs snapshot of
> > > today,
> > > that fixes several bugs...
> > >
> > > first and foremost the "fix" that went into 4.0.6 was not only broken,
but
> > > also
> > > implemented a possible NULL pointer dereference. The main problem with
> > > that
> > > fix
> > > was, that it applied the "search end of headers" functionality to the
> > > wrong
> > > place.
> > > The array upload was also crashable by simply using a name like
> > > "invalid]["
> > > as var name.
> > > I fixed it by correcting the IF clause that decides if it is an array
> > > upload
> > > or not.
> > > In fact my fix consists of several stability fixes that also make the
> > > upload
> > > more
> > > robust against browsers that are not 100% rfc conform.
> > >
> > > Hope my patch helps you to improve php even more. I really like the
whole
> > > idea of
> > > php and would be lucky if my contribution helps to make it even better
> > > than
> > > it already is.
> > >
> > > Yours,
> > > Ralf Bolte
> > >
> > > --
> > > GMX - Die Kommunikationsplattform im Internet.
> > > http://www.gmx.net
> >
> >--
> >GMX - Die Kommunikationsplattform im Internet.
> >http://www.gmx.net
> >
> >
> >--
> >PHP Development Mailing List 
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >To contact the list administrators, e-mail: [EMAIL PROTECTED]
>






> --
> PHP 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] Fw: [PHP-CVS] cvs: php4 /ext/standard php_string.h string.c

[Boian Bonev]

no response, so i noticed that i forgot to cc: the dev list.

b.

- Original Message -
From: "Boian Bonev" <[EMAIL PROTECTED]>
To: "Derick Rethans" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, September 09, 2001 10:29 PM
Subject: Re: [PHP-CVS] cvs: php4 /ext/standard php_string.h string.c


> hi,
>
> IMHO this is incorrect again :))
>
> you should not return when there are some translations, because it is a
> common practice to have code with mixed line endings [most commonly
> win/unix].
>
> the perfect solution [only like algorithm] is:
> ereg_replace('\n\r?|\r','')
>
> talking for speed - as far as i know boyer-moore algorithm is not good
with
> short strings :)) so instead of three times calling boyer_str_to_str, it
> will be better to scan the string once and code the above regexp in two
ifs
> ;)
>
> anyway not be only speaking, if it will be helpful, i can send a patch on
> this...
>
> b.
>
> - Original Message -
> From: "Derick Rethans" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Sunday, September 09, 2001 3:55 PM
> Subject: [PHP-CVS] cvs: php4 /ext/standard php_string.h string.c
>
>
> > derick Sun Sep  9 08:55:48 2001 EDT
> >
> >   Modified files:
> > /php4/ext/standard php_string.h string.c
> >   Log:
> >   - Really fix nl2br now... it's actaulyl faster now
> >
> >
> > Index: php4/ext/standard/php_string.h
> > diff -u php4/ext/standard/php_string.h:1.51
> php4/ext/standard/php_string.h:1.52
> > --- php4/ext/standard/php_string.h:1.51 Tue Sep  4 05:35:53 2001
> > +++ php4/ext/standard/php_string.h Sun Sep  9 08:55:48 2001
> > @@ -17,7 +17,7 @@
> >
> +--+
> >  */
> >
> > -/* $Id: php_string.h,v 1.51 2001/09/04 09:35:53 sterling Exp $ */
> > +/* $Id: php_string.h,v 1.52 2001/09/09 12:55:48 derick Exp $ */
> >
> >  /* Synced with php 3.0 revision 1.43 1999-06-16 [ssb] */
> >
> > @@ -117,7 +117,7 @@
> >  PHPAPI void php_trim2(zval **str, zval **what, zval *return_value, int
> mode TSRMLS_DC);
> >  PHPAPI void php_strip_tags(char *rbuf, int len, int state, char *allow,
> int allow_len);
> >
> > -PHPAPI void php_char_to_str(char *str, uint len, char from, char *to,
int
> to_len, pval *result);
> > +PHPAPI int php_char_to_str(char *str, uint len, char from, char *to,
int
> to_len, pval *result);
> >
> >  PHPAPI void php_implode(zval *delim, zval *arr, zval *return_value);
> >  PHPAPI void php_explode(zval *delim, zval *str, zval *return_value, int
> limit);
> > Index: php4/ext/standard/string.c
> > diff -u php4/ext/standard/string.c:1.238
php4/ext/standard/string.c:1.239
> > --- php4/ext/standard/string.c:1.238 Sun Sep  9 07:42:36 2001
> > +++ php4/ext/standard/string.c Sun Sep  9 08:55:48 2001
> > @@ -18,7 +18,7 @@
> >
> +--+
> >   */
> >
> > -/* $Id: string.c,v 1.238 2001/09/09 11:42:36 derick Exp $ */
> > +/* $Id: string.c,v 1.239 2001/09/09 12:55:48 derick Exp $ */
> >
> >  /* Synced with php 3.0 revision 1.193 1999-06-16 [ssb] */
> >
> > @@ -2473,10 +2473,11 @@
> >
> >  /* {{{ php_char_to_str
> >   */
> > -PHPAPI void php_char_to_str(char *str, uint len, char from, char *to,
int
> to_len, zval *result)
> > +PHPAPI int php_char_to_str(char *str, uint len, char from, char *to,
int
> to_len, zval *result)
> >  {
> > - int char_count=0;
> > - char *source, *target, *tmp, *source_end=str+len, *tmp_end=NULL;
> > + int char_count = 0;
> > + int replaced = 0;
> > + char *source, *target, *tmp, *source_end=str+len, *tmp_end = NULL;
> >
> >   for (source=str; source >   if (*source==from) {
> > @@ -2486,7 +2487,7 @@
> >
> >   if (char_count==0) {
> >   ZVAL_STRINGL(result, str, len, 1);
> > - return;
> > + return 0;
> >   }
> >
> >   Z_STRLEN_P(result) = len + (char_count * (to_len - 1));
> > @@ -2495,6 +2496,7 @@
> >
> >   for (source = str; source < source_end; source++) {
> >   if (*source == from) {
> > + replaced = 1;
> >   for (tmp = to, tmp_end = tmp+to_len; tmp < tmp_end; tmp++) {
> >   *target = *tmp;
> >   target++;
> > @@ -2505,6 +2507,7 @@
> >   }
> >   }
> >   *target = 0;
> > + return replaced;
> >  }
> >  /* }}} */
> >
> > @@ -2992,13 +2995,12 @@
> >   if (new_length != (*str)->value.str.len)
> >   RETURN_STRING

Re: [PHP-DEV] Better shell scripting

[Boian Bonev]

> > i can see just one reason - most people use the same php binary both for
cgi
> > and shell scripting. if this change is to be introduced in php then at
least
> > three builds will be performed - for shell, cgi and web server module.
btw
> > what happened with the change to the build system to allow simultaneous
> > building of both cgi-sapi and another one?
>
> Why would you build all 3? It seems to me that at most only 2 would be
> built: web-server + shell, or cgi + shell.

you are right - most people build just 2.

b.


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

Re: [PHP-DEV] Better shell scripting

[Boian Bonev]

i can see just one reason - most people use the same php binary both for cgi
and shell scripting. if this change is to be introduced in php then at least
three builds will be performed - for shell, cgi and web server module. btw
what happened with the change to the build system to allow simultaneous
building of both cgi-sapi and another one?

b.

- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "Stig Sæther Bakken" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, September 07, 2001 6:00 PM
Subject: Re: [PHP-DEV] Better shell scripting


On Fri, 07 Sep 2001, Stig Sæther Bakken wrote:
> What if we introduced a -p option to PHP that starts the Zend parser
> in "PHP mode"?  For any other files (include/require), it starts in
> "HTML mode" though.

How about we have a separate sapi backend that really does all this
stuff properly without relying on command-line options (which I hate)?
This suggestion has been made long ago, so what's stopping us?

-Andrei

"Everything should be made as simple
as possible, but not simpler."
  -- Albert Einstein

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




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

Re: [PHP-DEV] Better shell scripting

[Boian Bonev]

sure it will be ok. but this is change in zend, not php.

to make this working zend people must export a call/option/global/something
to change the flex scanner initial state.

and a question of design - shall this be a permanent or first execute
change? i mean if a script run with -S includes another php script, then
what shall be the initial state for the included script?

to Zeev: then why not remove 1/3 of the code ifdefed __cpluplus?

b.
- Original Message -
From: "Brian Moon" <[EMAIL PROTECTED]>
To: "Boian Bonev" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Stig
Sæther Bakken" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, September 07, 2001 5:41 PM
Subject: Re: [PHP-DEV] Better shell scripting


> We could make this part of the -S option that I have just submitted a
patch
> for.
>
> Brian Moon
> --
> dealnews.com, Inc.
> Makers of dealnews & dealmac
> http://dealnews.com/ | http://dealmac.com/
>
>
> - Original Message -
> From: "Boian Bonev" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; "Stig Sæther Bakken"
<[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, September 07, 2001 9:51 AM
> Subject: Re: [PHP-DEV] Better shell scripting
>
>
> > +1 :))
> >
> > and a
> >
> > #!/bin/php -p
> > echo "some string here\n";
> > ?>some html here ;)))
> > 
> >
> > although this requires a patch in Zend/zend_language_scanner.l line 279
> :)))
> > for plain c, and i didn't look where for c++.
> >
> > b.
> > - Original Message -
> > From: "Stig Sæther Bakken" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>
> > Sent: Friday, September 07, 2001 12:28 PM
> > Subject: Re: [PHP-DEV] Better shell scripting
> >
> >
> > > What if we introduced a -p option to PHP that starts the Zend parser
> > > in "PHP mode"?  For any other files (include/require), it starts in
> > > "HTML mode" though.
> > >
> > >  - Stig
> > >
> > > [<[EMAIL PROTECTED]>]
> > > > Yeah, I agree. However, it might make things a bit muddled
> > > > for people using it as cgi? How would PHP tell if the following
> > > > was PHP code or if its supposed to be echoed to the web browser?
> > > >
> > > > I would rather see a -shell option which does what you describe.
> > > >
> > > > Mike (long-time listener, first-time poster ;)
> > > >
> > > > >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
> > > >
> > > > On 9/7/01, 11:27:30 AM, Edin Kadribasic wrote
> > > > regarding Re: [PHP-DEV] patch to make for better shell scripting:
> > > >
> > > >
> > > > > Almost forgot. IMO -q swich should make starting  > > > instead
> > > > > of writing:
> > > >
> > > > > #!/usr/bin/php -q
> > > > >  > > > > print "Hello, world!\n";
> > > > > ?>
> > > >
> > > > > I could simply say:
> > > >
> > > > > #!/usr/bin/php -q
> > > > > print "Hello, world!\n";
> > > >
> > > >
> > > >
> > > > > Edin
> > > >
> > > >
> > > > > --
> > > > > PHP Development Mailing List <http://www.php.net/>
> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > > To contact the list administrators, e-mail:
> > [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List <http://www.php.net/>
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > > To contact the list administrators, e-mail:
> [EMAIL PROTECTED]
> > >
> > > --
> > >   Stig Sæther Bakken <[EMAIL PROTECTED]>
> > >   Fast Search & Transfer ASA, Trondheim, Norway
> > >
> > > --
> > > PHP Development Mailing List <http://www.php.net/>
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > To contact the list administrators, e-mail:
[EMAIL PROTECTED]
> > >
> > >
> >
> >
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

Re: [PHP-DEV] Better shell scripting

[Boian Bonev]

+1 :))

and a

#!/bin/php -p
echo "some string here\n";
?>some html here ;)))


although this requires a patch in Zend/zend_language_scanner.l line 279 :)))
for plain c, and i didn't look where for c++.

b.
- Original Message -
From: "Stig Sæther Bakken" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, September 07, 2001 12:28 PM
Subject: Re: [PHP-DEV] Better shell scripting


> What if we introduced a -p option to PHP that starts the Zend parser
> in "PHP mode"?  For any other files (include/require), it starts in
> "HTML mode" though.
>
>  - Stig
>
> [<[EMAIL PROTECTED]>]
> > Yeah, I agree. However, it might make things a bit muddled
> > for people using it as cgi? How would PHP tell if the following
> > was PHP code or if its supposed to be echoed to the web browser?
> >
> > I would rather see a -shell option which does what you describe.
> >
> > Mike (long-time listener, first-time poster ;)
> >
> > >> Original Message <<
> >
> > On 9/7/01, 11:27:30 AM, Edin Kadribasic wrote
> > regarding Re: [PHP-DEV] patch to make for better shell scripting:
> >
> >
> > > Almost forgot. IMO -q swich should make starting  > instead
> > > of writing:
> >
> > > #!/usr/bin/php -q
> > >  > > print "Hello, world!\n";
> > > ?>
> >
> > > I could simply say:
> >
> > > #!/usr/bin/php -q
> > > print "Hello, world!\n";
> >
> >
> >
> > > Edin
> >
> >
> > > --
> > > 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]
>
> --
>   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 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] Warning

[Boian Bonev]

> > > At link I'm getting "gcc: unrecognized option `-prefer-non-pic'"
> > > My gcc version:
> > > Reading specs from
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
> > > gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
> > >
> > > It's not an error but is this option really necessary?
> >
> > i've seen in yesterday... maybe it makes things a bit faster/smaller. i
do
> > not know exactly how, but if it does not break non-gcc compilers (it
will if
> > it appear to them, perhapse) why not?
>
> I'm currently considering ripping out automake completely.
> As a side-effect that problem would go away, too.

isn't it easier fixing automake itslef? or there is some non gnu stuff it
cannot held?

b.


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

Re: [PHP-DEV] Warning

[Boian Bonev]

> At link I'm getting "gcc: unrecognized option `-prefer-non-pic'"
> My gcc version:
> Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs
> gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)
>
> It's not an error but is this option really necessary?

i've seen in yesterday... maybe it makes things a bit faster/smaller. i do
not know exactly how, but if it does not break non-gcc compilers (it will if
it appear to them, perhapse) why not?

b.


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

Re: [PHP-DEV] Bug #9859 Updated: mail() doesn't send cc or bcc as in the manual instructions

[Boian Bonev]

> > then maybe close the related bug 10136...

or better reopen both, since this is a problem.

> >
> > although it would be better if win32 smtp code is made more consistent
and
> > compatible with the unix sendmail one
>
> Making Cc and cc both work is a one-line fix. (Patch attached, but as I
> can not test this, I didn't commit). But while looking at the
> code, I see nothing about Bcc. Strange, or I'm i missing something?

sure but not. you do not check for cC and CC :) the best way is to use case
insesitive strstr (this shall not be so hard to code)

there is one more prob - looking for \r\n exact match. in case of \n
terminated input, this call returns NULL and logic goes to alloc deadly too
much ram.

about bcc - yes it is missing, but as far as i remember i have seen it
eighter in an older version of this code, or in another related code. it
must be processed exactly like cc.

b.


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

[PHP-DEV] Bug #11010 Updated: current cvs cannot configure

[boian]

ID: 11010
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *Install and Config
Operating system: Linux glibc 2.1
PHP Version: 4.0 Latest CVS (2001-05-22)
Description: current cvs cannot configure

freshmeat on autoconf:

Changes: This version includes 2 years of accumulated improvements and bugfixes. While 
almost every line of code has been touched since version 2.13, Autoconf 2.50 aims to 
be backward compatible for well-written configure.in scripts. 

i removed 2.50 and put back 2.13 and everything is ok now

i've looked further but they do not define well-written...


Previous Comments:
---

[2001-05-22 02:34:54] [EMAIL PROTECTED]
after upgrading libtool to 1.4 i have upgraded automake and autoconf to latest stable 
versions, here is the result:

buildconf: checking installation...
buildconf: autoconf version 2.50 (ok)
build/buildcheck.sh: test: 4-p1: integer expression expected
buildconf: automake version 1.4-p1 (ok)
buildconf: libtool version 1.4 (ok)
WARNING: automake and libtool are installed in different
 directories.  This may cause aclocal to fail.
 continuing anyway
rebuilding Makefile templates
automake: configure.in: installing `Zend/ylwrap'
rebuilding configure
./aclocal.m4:904: error: m4_defn: undefined: _m4_divert_diversion
./aclocal.m4:452: PHP_SUBST is expanded from...
./aclocal.m4:904: the top level
rebuilding acconfig.h
rebuilding main/php_config.h.in
autoheader: error: shell error while sourcing /tmp/ah26273/traces.sh

in build/buildcheck.sh:
first problem - automake version is 1.4-p1 and this check fails:
IFS=.; set $am_version; IFS=' '
if test "$1" = "1" -a "$2" -lt "4" || test "$1" -lt "1"; then

fix:

Index: build/buildcheck.sh
===
RCS file: /repository/php4/build/buildcheck.sh,v
retrieving revision 1.8
diff -u -r1.8 buildcheck.sh
--- build/buildcheck.sh 2001/05/06 18:51:21 1.8
+++ build/buildcheck.sh 2001/05/22 00:25:01
@@ -40,7 +40,7 @@
 fi
 
 # automake 1.4 or newer
-am_version=`automake --version 2>/dev/null|head -1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* 
*$//'`
+am_version=`automake --version 2>/dev/null|head -1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* 
+*$//' -e 's/-/./'`
 if test "$am_version" = ""; then
 echo "buildconf: automake not found."
 echo "   You need automake version 1.4 or newer installed"

second problem - 

after double checking for libtool, $libtool is set to `which libtool` or `which 
glibtool`. in the check if libtool and automake are in the same path again which is 
used that is incorrect because which /bin/libtool founds nothing.

fix: 

Index: build/buildcheck.sh
===
RCS file: /repository/php4/build/buildcheck.sh,v
retrieving revision 1.8
diff -u -r1.8 buildcheck.sh
--- build/buildcheck.sh 2001/05/06 18:51:21 1.8
+++ build/buildcheck.sh 2001/05/22 00:30:21
@@ -81,7 +81,7 @@
 fi
 
 am_prefix=`which automake | sed -e 's#/[^/]*/[^/]*$##'`
-lt_prefix=`which $libtool | sed -e 's#/[^/]*/[^/]*$##'`
+lt_prefix=`echo $libtool | sed -e 's#/[^/]*/[^/]*$##'`
 if test "$am_prefix" != "$lt_prefix"; then
 echo "WARNING: automake and libtool are installed in different"
 echo " directories.  This may cause aclocal to fail."

i'd update this bug when i find what else is going wrong

---


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


-- 
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 #9859 Updated: mail() doesn't send cc or bcc as in the manual instructions

[Boian Bonev]

hi,

then maybe close the related bug 10136...

although it would be better if win32 smtp code is made more consistent and
compatible with the unix sendmail one

b.


- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 22, 2001 4:33 AM
Subject: [PHP-DEV] Bug #9859 Updated: mail() doesn't send cc or bcc as in
the manual instructions


> ID: 9859
> Updated by: danbeck
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Closed
> Bug Type: Mail related
> Operating system:
> PHP Version: 4.0.4pl1
> Assigned To:
> Comments:
>
> If this is the case, then I'm closing this bug report and I will document
the behavior under the mail function.
>
> Previous Comments:
> --
-
>
> [2001-05-22 01:45:29] [EMAIL PROTECTED]
> see also bug #10136
>
> the facts are: mail on win32 require rn newlines
> also it is case sensitive on Cc: and Bcc: - it will not honour them if
spelled any other way.
>
> here is the offending code (located in win32/sendmail.c):
>
> if (headers && (pos1 = strstr(headers, "Cc:"))) {
>   pos2 = strstr(pos1, "rn");
>   tempMailTo = estrndup(pos1, pos2-pos1);
>   token = strtok(tempMailTo, ",");
>
> i do not have win32 build env setup so cannot fix this
>
> --
-
>
> [2001-05-21 05:06:18] [EMAIL PROTECTED]
> I've corrected the Cc: and Bcc: problems in the mail() example, but I'm
reclassifying this as a Mail Function problem.  Is it necessary for the
win32 version of the mail() function to require that you use rn?
>
> If it is, I can add this information to the mail function docs.
>
> --
-
>
> [2001-03-20 02:42:22] [EMAIL PROTECTED]
> script example:
> --
---
>  $returnvar="false";
>
> $mailto="[EMAIL PROTECTED]";
> $mailsubject="cc test";
> $mailmessage="message content";
> $mailHeader="cc:[EMAIL PROTECTED]";
>
> $returnvar=mail($mailto,$mailsubject,$mailmessage,$mailHeader);
>
> ?>
> 
> 
> the mail was sent?
>  echo "returnvar= $returnvar";
> ?>
> 
> 
> --
---
> The above does not send the carbon copy.
>
> The pdf manual says:
> --

> $headers .= "cc:[EMAIL PROTECTED]"; // CC to
> $headers .= "bcc:[EMAIL PROTECTED], [EMAIL PROTECTED]"; // BCCs
to
> /* and now mail it */
> mail($recipient, $subject, $message, $headers);
> --
-
>
> That does not work since Win32 sendmail.c looks for case sensitve "Cc:"
> sendmail.c also does not look for "bcc:"
>
> Also you must have "rn" not just "n".
>
> I think the problem is here in win32 sendmail.c :
>
> if (headers && (pos1 = strstr(headers, "Cc:"))) {
> pos2 = strstr(pos1, "rn");
> tempMailTo = estrndup(pos1, pos2-pos1);
>
>
>
> --
-
>
>
>
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at
http://bugs.php.net/?id=9859&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 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 #11010: current cvs cannot configure

[boian]

From: [EMAIL PROTECTED]
Operating system: Linux glibc 2.1
PHP version:  4.0 Latest CVS (2001-05-22)
PHP Bug Type: *Install and Config
Bug description:  current cvs cannot configure

after upgrading libtool to 1.4 i have upgraded automake and autoconf to latest stable 
versions, here is the result:

buildconf: checking installation...
buildconf: autoconf version 2.50 (ok)
build/buildcheck.sh: test: 4-p1: integer expression expected
buildconf: automake version 1.4-p1 (ok)
buildconf: libtool version 1.4 (ok)
WARNING: automake and libtool are installed in different
 directories.  This may cause aclocal to fail.
 continuing anyway
rebuilding Makefile templates
automake: configure.in: installing `Zend/ylwrap'
rebuilding configure
./aclocal.m4:904: error: m4_defn: undefined: _m4_divert_diversion
./aclocal.m4:452: PHP_SUBST is expanded from...
./aclocal.m4:904: the top level
rebuilding acconfig.h
rebuilding main/php_config.h.in
autoheader: error: shell error while sourcing /tmp/ah26273/traces.sh

in build/buildcheck.sh:
first problem - automake version is 1.4-p1 and this check fails:
IFS=.; set $am_version; IFS=' '
if test "$1" = "1" -a "$2" -lt "4" || test "$1" -lt "1"; then

fix:

Index: build/buildcheck.sh
===
RCS file: /repository/php4/build/buildcheck.sh,v
retrieving revision 1.8
diff -u -r1.8 buildcheck.sh
--- build/buildcheck.sh 2001/05/06 18:51:21 1.8
+++ build/buildcheck.sh 2001/05/22 00:25:01
@@ -40,7 +40,7 @@
 fi
 
 # automake 1.4 or newer
-am_version=`automake --version 2>/dev/null|head -1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* 
*$//'`
+am_version=`automake --version 2>/dev/null|head -1|sed -e 's/^[^0-9]*//' -e 's/[a-z]* 
+*$//' -e 's/-/./'`
 if test "$am_version" = ""; then
 echo "buildconf: automake not found."
 echo "   You need automake version 1.4 or newer installed"

second problem - 

after double checking for libtool, $libtool is set to `which libtool` or `which 
glibtool`. in the check if libtool and automake are in the same path again which is 
used that is incorrect because which /bin/libtool founds nothing.

fix: 

Index: build/buildcheck.sh
===
RCS file: /repository/php4/build/buildcheck.sh,v
retrieving revision 1.8
diff -u -r1.8 buildcheck.sh
--- build/buildcheck.sh 2001/05/06 18:51:21 1.8
+++ build/buildcheck.sh 2001/05/22 00:30:21
@@ -81,7 +81,7 @@
 fi
 
 am_prefix=`which automake | sed -e 's#/[^/]*/[^/]*$##'`
-lt_prefix=`which $libtool | sed -e 's#/[^/]*/[^/]*$##'`
+lt_prefix=`echo $libtool | sed -e 's#/[^/]*/[^/]*$##'`
 if test "$am_prefix" != "$lt_prefix"; then
 echo "WARNING: automake and libtool are installed in different"
 echo " directories.  This may cause aclocal to fail."

i'd update this bug when i find what else is going wrong


-- 
Edit Bug report at: http://bugs.php.net/?id=11010&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] Latest commit -- depreciation of call_user_method()

[Boian Bonev]

> One thing I'd like to see is a utility which could check a source
directory and
> warn about obviously deprecated / insecure / inefficient things. It'd make
life
> easier for that hypothetical ISP admin with a large pile of code which has
been
> haphazardly maintained for years.

hey, guys, how do you imagine an isp admin changing hosted code in order to
upgrade php to a newer incompatible version?

this is a dream - if isps are not sure it will work without changes, they
will never upgrade. if they upgrade and thousands of sites stop working many
people will _really_hate_ php

lets say i am the client and my isp decides to upgrade - they change my .php
files so they now work with the latest php version, tommorow i login and
upload my newer version and everything stops working, yes everything because
one of the files included everywhere uses a deprecated construct and bloats
with a syntax error...

breaking backward compatibility in php is not a good thing - it even cannot
be compared to apache 1.2.x differences to 1.3.x ones. for isps the
webserver is their responsibility but php code is user's. moving from apache
1.2.x to 1.3.x for a server with hundreds of hosted sites is a piece of cake
compared to upgrading from php3 to php4 - this is the reason many isps do
not upgrade and will not

b.


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

Fw: [PHP-DEV] 4.0.6

[Boian Bonev]

- Original Message -
From: "Boian Bonev" <[EMAIL PROTECTED]>
To: "Dave Jones" <[EMAIL PROTECTED]>
Sent: Tuesday, May 08, 2001 6:29 PM
Subject: Re: [PHP-DEV] 4.0.6


> hi,
>
> > And also line number don't get incremented if there are no line ends, so
> > all syntax errors are reported as being on line 1.
> > The issue might have never come up if the code used "r" mode for opens
> > rather that "rb", since the file are 'text' files.  On platforms that
> > don't used embedded newline characters as the record delimiters, the
> > implementation of fread is responsible for mapping the underlying file
> > format to cannonical form (i.e. \n's delimiting lines).
>
> you are partially correct - if we have only 'native' files - yes this is
the
> case. but imagine tons of downloaded code, parts of it originating from
*nix
> others from windows, and parts of them edited so all the three possible
> combinations are used. perhapse you know that most editors convert line
> endings only for edited lines not for the whole file. now the task of
> correctly counting line numbers is not that easy. neighter file conversion
> is. of course some editors pretend to be that clever to interprete all the
> three formats - something like greedy eating \n\r|\n|\r in this order...
>
> b.
>

forgot to say that php must flawlessly interprete all the combinations
provided that it is a platform independant language and never rely on os
specific stuff - win php source must work on unix as unix php source on
windows...



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

Re: [PHP-DEV] mailparse extension

[Boian Bonev]

> 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 also like to see this one released in php. :)

b.


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

Re: [PHP-DEV] 4.0.6

[Boian Bonev]

> >Note that there was no such problem with PHP 4.0.4pl1 and earlier.
> That's very odd, as PHP never considered \r alone to be a linefeed...

it is not that odd because it may have treated it like whitespace - imagine
a long line script. now it may treat it not as whitespace and hence the
problem

there is no big difference between whitespace and newline(s) in php, is it?

b.


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

Re: [PHP-DEV] Re: Crypt salts not random.. (fwd)

[Boian Bonev]

hi,

> >That only really works for forking webservers, does it not? Another
> >alternative
> >would be to use microseconds...
>
> Yeah we could use microseconds but are they available on all platforms?
> In any case, on non-forking servers we can use thread id.

if it is a threading server then why not make crypt's salt seed global... at
least there is no wat to generate two equal salts with it.

btw, in real life when one needs security he will generate the salt himself

b.



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

Re: [PHP-DEV] Bug #10528: I have been unable to find any documentation on the SAPI interface.

[Boian Bonev]

hi,

i have already did the same thing for a radiusd server - it is not rocket
science but the apache module is not the right starter point.

i can send you code or put it in php's CVS (only if the community agree on
this)

i had one big problem with integrating php into some software - if i write a
simple test case and interprete 1 scripts from there it is ok. when i
link it to a bigger software it begins to leak...

about the sapi docs - the code is the best doc and you can find everything
there, but a sample program will help you a lot before someone writes the
doc

b.

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 27, 2001 9:59 PM
Subject: [PHP-DEV] Bug #10528: I have been unable to find any documentation
on the SAPI interface.


> From: [EMAIL PROTECTED]
> Operating system: Linux
> PHP version:  4.0.4pl1
> PHP Bug Type: Documentation problem
> Bug description:  I have been unable to find any documentation on the SAPI
interface.
>
> I need to incorporate a PHP engine into a program which is very similar to
a web server.
>
> I am thoroughly familiar with the documentation and I have written normal
extensions to PHP to call functions in a library. No problem.
>
> Have I overlooked the SAPI docs?
>
> Is there a simple example?
>
> If not I will have to hack away at the Apache SAPI but I'd rather have a
route map!
>
> Thanks.
>
>
> --
> Edit Bug report at: http://bugs.php.net/?id=10528&edit=1
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

Re: [PHP-DEV] Bug #10510 Updated: ini_set() as relates to max upload filesize setting

[Boian Bonev]

sure. i guess at least about egpcs handling, arg separator, magic quotes,
perhapse some session options, register_globals, safe_mode.

lets make a list - this can be easily fixed. :)

b.

- Original Message -
From: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, April 26, 2001 5:59 PM
Subject: Re: [PHP-DEV] Bug #10510 Updated: ini_set() as relates to max
upload filesize setting


> [EMAIL PROTECTED] wrote:
> > Please take into account that the processing of post data happens
> > _before_ your call to ini_set. Thus your new limit value has no effect
> > to the upload and succeeds (of course) after the upload is rejected.
>
> maybe we should think about a way to mark all ini settings like these
> and generate warnings when ini_set is used at runtime to change them
>
> --
> Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

Re: [PHP-DEV] Bug #10510 Updated: ini_set() as relates to max upload filesize setting

[Boian Bonev]

i forgot to say that maybe we shall add two more bugs from this one -

- a feature request for not allowing nonsense settings like the mentioned in
the list
- i don't know if is it a good idea post file upload to generate a warning
when limit is exceeded

b.

- Original Message -
From: "Hartmut Holzgraefe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, April 26, 2001 5:59 PM
Subject: Re: [PHP-DEV] Bug #10510 Updated: ini_set() as relates to max
upload filesize setting


> [EMAIL PROTECTED] wrote:
> > Please take into account that the processing of post data happens
> > _before_ your call to ini_set. Thus your new limit value has no effect
> > to the upload and succeeds (of course) after the upload is rejected.
>
> maybe we should think about a way to mark all ini settings like these
> and generate warnings when ini_set is used at runtime to change them
>
> --
> Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

Re: [PHP-DEV] RE: 4.0.5: Merge Request

[Boian Bonev]

hi,

> Maybe something like this
>
> 1. Any problems which result in seg faults/gpfs are show stoppers, code
doesnt
> go out till its fixed, or feature is removed till we can fix it.

this is not correct (in general :) - there are segfaults in experimental
stuff that do not imply exploits, are no security risk and are just a
new/unused feature that does not work as expected. it IS ok to release with
such a segfault. an example:

bbonev@orange:~$ echo "" | php -a
Interactive mode enabled

X-Powered-By: PHP/4.0.5RC6
Content-type: text/html

Segmentation fault

see bug id 8621

i think commonsense shall be used to judge what is showstopper and what is
not :)
this one definitely is not

b.


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

Re: [PHP-DEV] request

[Boian Bonev]

> > You could have two classes both defining an innocent method toString(),
> > for example, and with your suggestion, inheriting from those classes
> > would cause a hard error? Why would "first encountered" definition
> > change?
> If anything that affected how classes were ordered changed, if the classes
were
> renamed, if the class definitions changed...

first occurence means the first occurence in the inheritance list. then it
is important how you order the class names when you inherit them, not when
they got defined.

b.


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

Re: [PHP-DEV] always building cgi...

[Boian Bonev]

> > With some more minor restructuring, we can then let people build _all_
> > sapi modules in one go if they like.
> Without careful consideration, I would not say that it would
> require only minor restructuring.  If we would implement that
> change, it would have a direct effect upon the installation
> procedure of PHP.  That is not a problem with online
> documentation, but what about printed manuals and the dozens
> of books on PHP?  I'd be very hesitant to change anything
> here which would render those descriptions invalid.

if a backwards compatible configure command line is kept valid why not? if
the sapi module(s) to install becomes a list of --with-somesapi it would not
break neighter descriptions nor saved built scripts.

> On the implementation side, I'm not convinced of the
> usefulness of such a change.  The way libphp4.la is built
> directly depends upon the chosen SAPI module (thread-safety,
> shared/static).  As of today, there are only a few possible
> combinations.  From day-to-day experience, I have yet to see
> an installation where web-servers run parallelly (and which
> use PHP/require the same build options).

there are two ways of building libphp4.la - thread safe and not thread safe.
let us say libphp4.la and libphp4ts.la. the rest is just a linker option or
am i missing something? i think the idea to separate the sapi stuff from the
rest of php is not that bad - you build php once (or twice for TS) and then
link to sapi modules at will.

b.


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

[PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] RE: changes

[Boian Bonev]

hi,

i am speaking for the main branch. if the community decides that adding a
function declaration can break anything then just do not commit this into
4.0.5 :)

as far as i have seen many major changes have been made to 4.0.5. anyway it
will work both ways except that calling the function with wrong args wont
issue a warning (at least for gcc - i have seen compilers pretending to be
more strict than needed and giving errors in such a condition).

btw. a month ago Rasmus asured me that the change is in cvs but perhapse he
has commited it to the wrong branch.

b.

> > the idea is that it would be better if the line above is included in
> > exec.h... of course it works without it but at least i am not happy with
it
> > this way.
>
> You would be perfectly right, if we would be dealing with the
> main branch of CVS.  In the case of the release branch, many
> people consider changes to be "bad" per default.  So, if we
> can release working code without applying any changes, we
> usually prefer that route.



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

[Boian Bonev]

> > > a single compiler warning issue - in ext/standard/exec.h there must be
a
> > > declaration of php_Exec:
> > >
> > > int php_Exec(int type, char *cmd, pval *array, pval *return_value);
> >
> > People what do you think? does this need to be fixed? Im no compiler
guru,
> > Sascha do you know you seem to have a pretty good idea of what compilers
> > will cope with what?
>
>  Every compiler should be able to cope with function calls to
>  functions without prototypes.  In this case, there should not
>  be problems regarding default argument promotions.

hi,

the idea is that it would be better if the line above is included in
exec.h... of course it works without it but at least i am not happy with it
this way.

b.


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

Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Boian Bonev]

> > i'd also preffer to have both versions - on all of my production servers
i
> > do install both apache module and cgi version. the latter i use for cron
> > jobs, background processing and whatsoever tasks that need to do
something
> > outside the web. so in my opinion both sapi module and cgi will be a
fine
> > default. one more 'little' binary in /usr/local/bin would harm noone.
also
> > some isp configurations with several sapi setups on the same machine
would
> > benefit easier maintenance with this option. of course a way to disable
it
> > is ok but since PEAR needs the cgi ver to be able to fetch modules and
etc
> > the default should be 'enabled'.
> Also it make sense to separate all but SAPI modules into shared library
> to which SAPI module is linked dynamically. Then SAPI module binaries will
> all share one code.

indeed this is only one more step in the build process - make the core php
lib then link to all the sapi modules on the configure command line and
install them one by one. you did not mean dll/so right? because the base
library must be a static one and then the sapi modules themselves may be
either dynamic or static...

b.


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

Re: [PHP-DEV] RE: [PEAR-DEV] Re: [PHP-DEV] Re: [PEAR-DEV] --with-pear[=DIR] patch

[Boian Bonev]

> > > Perhaps optionally disabled.. --without-cgi?
> > I would go for optionally on, I really dont want to build both the
apache
> > module (p.e.) AND the CGi at the same time. For QA testing this is fine,
> > but not for production servers.
>
> If you want to use the PEAR tools, you need the CGI version.  These
> are definitely intended for production servers.
>

i'd also preffer to have both versions - on all of my production servers i
do install both apache module and cgi version. the latter i use for cron
jobs, background processing and whatsoever tasks that need to do something
outside the web. so in my opinion both sapi module and cgi will be a fine
default. one more 'little' binary in /usr/local/bin would harm noone. also
some isp configurations with several sapi setups on the same machine would
benefit easier maintenance with this option. of course a way to disable it
is ok but since PEAR needs the cgi ver to be able to fetch modules and etc
the default should be 'enabled'.

b.




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

Re: [PHP-DEV] efree/emalloc in sapi

[Boian Bonev]

> Generally, the emalloc should be working all the way since
> start_memory_manager was called  - which means, from engine startup. The
> "request cleanup" (freeing all non-persistent memory blocks) happens on
> shutdown_memory_manager, which is called from php_request_shutdown,
> after calling request shutdown routines for all modules and extensions,
> including SAPI request shutdown.
>
> Giving second look on what I wrote, you code (from what I got from your
> description) generally should be safe to use emalloc... Maybe you have
> some other problem there?

first to tell you what exactly am i doing - a sapi module for a radius
server... (i have posted a note a while ago here)

the thing is not threaded and there are several processes calling external
stuff. i have replaced the exec call to process php files natively. my
future plan is to make some checks on file extension and process it both
ways but this is not important for my problem.

generally the radius server processes two types of requests:
- login (query) that goes in a single new process which dies afterwards
- accounting - start/alive and stop that is handled sequentially in a single
process that never exits

my first code used emalloc/efree in the following places:

sapi_startup...
php_module_startup...
  *  some emalloc
php_request_startup
php_execute_script
php_request_shutdown
  *  some efree
php_module_shutdown
sapi_shutdown

this works fine if called one time (login works ok). if an acct request
comes in - the first one works fine and the next one segfaults or infinitely
loops in libc's free.

the whole thing works fine again if i remove the efree calls. (with a small
leak but i am not sure if this isn't some cache) here i conclude that the
request_shutdown call is freeing my memory and when i free it again there is
a memory mess.

after replacing emalloc/efree with malloc/free the code works (with a small
leak but i am not sure if this isn't some cache)

i know that if i repeatedly execute php scripts from a single process it is
better to sapi/module startup once then execute_script and at exit
sapi/module shutdown. but i think it shall work both ways only with a
performance penalty in my case...

b.


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

Re: [PHP-DEV] RE: ; arg seperator

[Boian Bonev]

hi,

> > There was a discussion about things to break in 4.1. magic_quotes_gpc
would
> > definitely be my favourite. I'd like to see it set to off for good and
> > removed from php.ini.
>
> I'd be completely against removing the concept of magic_quotes altogether.
> We can discuss changing the default, but for someone writing simple sql
> pages, it is extremely handy to have PHP deal with escaping stuff for you
> so you don't have a bunch of addslashes() calls everywhere.

perhapse all those topics must be decided on a statistical basis. lets name
it:

count of boxes broken if arg_separator is '&;'
count of boxes that dont care about arg_separator default
count of boxes that need arg_separator to be '&;'
count of boxes relying on magic_quotes_gpc
count of boxes that dont care about magic_quotes_gpc
count of boxes that need magic_quotes_gpc set to off

the decision must break least possible count of php setups when they upgrade
to the newest version.

it would be a disaster for people who have a running server/site and
everything or even worse something somewhere goes wrong.

not to speak about hosting providers who upgrade farms of servers. their
users will have to track problems that occur depending on the input data and
mostly in rare cases. i think this will be a negative impact on many sites
making people reluctant to upgrade to newer php versions. php4.0.5 is not
that better that 4.0.x compared to the difference between 3 and 4 to afford
to break existing functionality...

b.


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

Re: [PHP-DEV] efree/emalloc in sapi

[Boian Bonev]

hi,

i know. the problem is i have used the thttpd sapi module as a sample and it
is supposed to be stable. i have solved my problem by using plain
malloc/free - my reason to share this experience is that there may be a leak
or segfault in some of the sapi modules. i haven't found neighter bug nor
leak still but it is possible.

can someone tell me the exact places where emalloced memory begins to be
tracked and where the leaks are efreed?

b.

> BB>> i have hit on this issue while trying to make a sapi module. my
> BB>> problem was that memory emalloc-ed _before_ the request got
> BB>> efree-ed by the memory manager after the request and when i
> BB>> efree it afterwards a total memory mess occurs (sigsegv,
> BB>> infinite loop in libc free or something more nasty)...
>
> You probably should use plain old malloc when you not inside the request.



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

[Boian Bonev]

hi,

> I won't be holding my breath for it. That's the basic property of
> reference-counting, so it's not easy to make it behave differently.
> Anyway, unless you have very-long-running very-memory-greedy scripts,
> these leaks shouldn't bother you - Zend memory manager cleans them up on
> every request.

i have hit on this issue while trying to make a sapi module. my problem was
that memory emalloc-ed _before_ the request got efree-ed by the memory
manager after the request and when i efree it afterwards a total memory mess
occurs (sigsegv, infinite loop in libc free or something more nasty)...

is there more info on exactly where emalloc tracks memory and when frees all
unfreed blocks in the process of

sapi_startup
php_module_startup
// memory alloced here gets freed by request_shutdown (i suppose)
php_request_startup
php_execute_script
php_request_shutdown
php_module_shutdown
sapi_shutdown

or i am missing something important?

b.


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

Fw: [PHP-DEV] feature request

[Boian Bonev]

oops, forgot the list.

i think no lang extension is needed. here is my reason - you can very easy
test for isset, what about !isset? then the condition will be or not and and
all the thing becomes messy.

b.

- Original Message -
From: "Boian Bonev" <[EMAIL PROTECTED]>
To: "Gavin Sherry" <[EMAIL PROTECTED]>; "Cameron" <[EMAIL PROTECTED]>
Sent: Monday, March 19, 2001 2:23 PM
Subject: Re: [PHP-DEV] feature request


> hi,
>
> better write you own checker in php... and implement and/or...
> here is a sample :-)))
>
>  function isset_and() {
> $numargs=func_num_args();
> $tt=func_get_arg($i);
> $res=isset($tt);
> for ($i=1;$i<$numargs;$i++) {
> $tt=func_get_arg($i);
> echo "$tt\n";
> $res&=isset($tt);
> }
> return $res;
> }
> $a='asda';
> $b='asa';
> echo isset_and($a,$b,$c);
> echo "\n";
> $c='asa';
> echo isset_and($a,$b,$c);
> ?>
>
>


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

[PHP-DEV] php sapi 4 radiusd

[Boian Bonev]

hi,

today i made something crazy - even i didn't believe it will do but i made
it through and i want to hear your opinion...

i am getting pissed from writing c code in one of our client's radius
servers and decided to ease the whole process, put it under control and make
the auth/account logic more maintainable...

i have started a sapi module for the xtradius server (www.xtradius.com) and
got something near working copy. the concept is clean - radiusd passes envp
style attributes to the sapi module, then all of them translate into a http
get like request. script output is parsed by the radius server against its
disctionary. xtradius forks on requests so there is no thread safety stuff.
the only problem is how to integrate into its code - there is neighter api
nor modules. a patch file will do but only for the current and near
versions.

i could use perl or cmdline php but with the sapi i save one fork per
request, one exec and php image loading...

still not sure,
b.


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

Re: [PHP-DEV] X-Powered-by

[Boian Bonev]

hi,

> header("Foo: bar\r\n");
> Get rid of that CRLF and it should work.

this is an idea. what about if header stripped all \n \r? i cant see a
reasonable use of \n in a header line...

b.


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

Re: [PHP-DEV] popen() spans >100 processes

[Boian Bonev]

> Encountered > 100 spanned cmd.exe + php.exe using win32 CGI, this does
> not happen using apachemod, my task manager was open by accident,
> otherwise I would not have noticed this...

sounds like the second php 'detects' CGI mode, reads script name from
environment vars then executes the same script again and again?

b.


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

Re: [PHP-DEV] Rsync and CVS

[Boian Bonev]

hi,

> >i'd suggest to make things simpler - just plain pre-generated html with
the
> >notes part. name it after TOPIC and include it in the proper place. the
> >generator script may run as cron job. there is only one problem - to
> prevent
> >rsync client from getting a semi-generated copy. this can be achieved
like:
> >or better - why not generate html upon comment add and use the html on
the
> >main site also?
>
> The reason the HTML is not pregenerated, is so that we can change the
> formatting etc on the fly. Perhaps according to a "max comments per page",
> or "look and feel" parameters.  The CPU load in formatting comments is
> pretty insignificant, especially compared to the other things it does at
the
> same time.

keep the stuff in the db like now. when you change design or alignment or
something just generate again... thus loose no flexibility and make
mirroring flawless. the code that generates the html is already written, the
whole thing is just a small rearrange.

why keep the file includes on the main site? just to have exact copies - no
different versions, no if ($mirror)...

about cpu you are partly right (cpu power is cheep these days). but we can't
compare text include/readfile/somthing with db query/fetch/etc right? why
not use the more performant one when nothing is lost.

> There might be some arguements for caching the comments in the filesystem
> (on www.php.net), but the gains are probably not worth the hassle, IMHO.

if mirroring requires it - why not use it in both places and keep code
simple and maintainable?

b.


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

Re: [PHP-DEV] Rsync and CVS

[Boian Bonev]

hi,

> I was thinking of /manual/usernotes/TOPIC.txt, where TOPIC is the subject
in
> question. The contents of those files would just be a serialize array,
> exactly as would be returned by the DB.  My local setup actually does
that,
> but loading those files requires a semi-backdoor into www.php.net, which
I'm
> a bit uncomfortable about.

i'd suggest to make things simpler - just plain pre-generated html with the
notes part. name it after TOPIC and include it in the proper place. the
generator script may run as cron job. there is only one problem - to prevent
rsync client from getting a semi-generated copy. this can be achieved like:

write_content($content,$tmpname);
unlink($path.$topic);
link($path.$topic,$tmpname);
unlink($tmpname);

if $path.$topic is being opened by rsync, after the unlink it will continue
to read the old version. when closed the os will delete the file.
next attempts will result in opening the new version of the file. if rsync
tries to open/find the file between unlink/link the client will lack the
comments until next update...

or better - why not generate html upon comment add and use the html on the
main site also?

> I know, installing a DB on the mirror and loading it with a dump of the
> master is another option, but rsync'd files is just *simpler*.

this is ok but it makes mirror administration harder. also pregenerated
content will require less cpu power...

b.


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

Re: [PHP-DEV] RE: PHP 4.0 Bug #9529 Updated: php4_module is garbled

[Boian Bonev]

did you 

rm httpd
make

 or 

make clean all install?

b.

- Original Message - 
From: "Mike Gibbons" <[EMAIL PROTECTED]>
To: "Bug Database" <[EMAIL PROTECTED]>
Sent: Sunday, March 04, 2001 3:17 AM
Subject: [PHP-DEV] RE: PHP 4.0 Bug #9529 Updated: php4_module is garbled


> ldd httpd
> libm.so.6 => /lib/libm.so.6 (0x40017000)
> libcrypt.so.1 => /lib/libcrypt.so.1 (0x40034000)
> libdb.so.3 => /lib/libdb.so.3 (0x40061000)
> libdl.so.2 => /lib/libdl.so.2 (0x4009b000)
> libc.so.6 => /lib/libc.so.6 (0x4009e000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000)



-- 
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] ctype function (re?)naming

[Boian Bonev]

hi,

> I am for uniform names but not if it's at the price of adding a zillion of
> aliases or at a price of making 50% of people's old scripts not work. I am
> also very much against compile-time options because I'd expect a script
> written in PHP and posted on some sites code exchange to work for
everybody.

code exchange do not work well even now - think about magic quotes and magic
quotes runtime.

compile-time defaut of some old versions of php (3.x as far as i remember)
is to disable magic quotes. my setup is
magic quotes set to yes, runtime to no.

many hosting providers still have a default setup of php3 and making a
shareable script needs the get_magic_quotes_qpc/set_magic_quotes_runtime and
addslashesh stuff. why make more difficulties? if there is an option about
function aliases then there will be times more different (incompatible)
envirnonments than now and perhapse autoconf stuff will be needed to setup
and run a simple php script on different server... just imagine the
"Checking for is_alpha..." ;-)

b.


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

Re: [PHP-DEV] PHP 4.0 Bug #9528 Updated: /home/sas/src/php4/ext/standard/url_scanner_ex.re ... permission denied

[Boian Bonev]

>>> Maybe this should be mentioned at http://bugs.php.net/anoncvs.php page?
>>> (why would some non-developer get his PHP 4 from CVS anyway? :)
>>there is at least one reason - to compile with a new feature that is not
>>released still. it is not recommended but i know about people doing
this...

> Well, it's not our fault then. :)
> Maybe they should be encouraged to use the CVS snapshots?

it is not of course.

encouraged yes, but cvs update uses less bandwidth and is a better way than
downloading the whole thing...
just a note that total regeneration is made by (this will also solve some
build problems):

./cvsclean
./buildconf
./genfiles
./configure 
make depend
make

b.


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

Re: [PHP-DEV] PHP 4.0 Bug #9528 Updated: /home/sas/src/php4/ext/standard/url_scanner_ex.re ... permission denied

[Boian Bonev]

> Yes, in CVS those directives can be found. But not in CVS snapshots
> or in releases. So this shouldn't be a problem if people are using
> those.
>
> >these are put automaticaly by re2c. it is invoked with full path in make
> >file, so it generates #line-s with full path.
> >non-developers really do not need these #line directives and developer
will
> >recreate them by remaking c from re.
> >so the best solution is to remove #line-s from the c file in cvs.
>
> I don't think it's necessary. If someone is getting PHP from CVS they
> just have to run ./genfiles to get rid of the #line directives.

hmm. i didn't know this eighter. then everything is ok :)

> Maybe this should be mentioned at http://bugs.php.net/anoncvs.php page?
> (why would some non-developer get his PHP 4 from CVS anyway? :)

there is at least one reason - to compile with a new feature that is not
released still. it is not recommended but i know about people doing this...

b.


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

Re: [PHP-DEV] PHP 4.0 Bug #9528 Updated: /home/sas/src/php4/ext/standard/url_scanner_ex.re ... permission denied

[Boian Bonev]

> Are you sure you're using the php4.0.4pl1 source tarball from
www.php.net??
> I just checked that file and it doesn't have any #line directives in it.

> [2001-03-02 14:04:44] [EMAIL PROTECTED]
> the following is the second line of the file
[path-to-php]/ext/standard/url_scanner_ex.c :
> #line 1 "/home/sas/src/php4/ext/standard/url_scanner_ex.re"

look in url_scanner_ex.c not in url_scanner_ex.re. at least in latest cvs
there are #line-s. my gcc does like them no matter there is no home/sas -
perhapse rick's is old or something... non-gcc compilers may complain badly
on these also

these are put automaticaly by re2c. it is invoked with full path in make
file, so it generates #line-s with full path.
non-developers really do not need these #line directives and developer will
recreate them by remaking c from re.
so the best solution is to remove #line-s from the c file in cvs.

b.


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

Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming

[Boian Bonev]

Just +1 :)

- Original Message -
From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
To: "Ron Chmara" <[EMAIL PROTECTED]>
Cc: "PHP Development" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 1:47 PM
Subject: Re: [PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] ctype function (re?)naming


> RC>> It's more legible for the same reason that it's easier (and
> RC>> faster) to read "one two three" than "onetwothree". The human
> RC>> mind can easily tokenize at the appropriate places, when it has
> RC>> a token. Without a token, the string is much harder to parse.
>
> For me, "isalpha" is single token. That's the name, much like Johnson or
> Chandrabharmata.
>
> RC>> There's several, in order of use: ldap_connect, ldap_bind,
ldap_search.
> RC>> Without looking in the manual, I _don't_ have to guess if it's
ldap_search
> RC>> or ldapsearch. Which is my entire point. I know the ldap functions
were
>
> Exactly. Because you don't know the "search" part, wondering on underscore
> is useless. That's my point. I repeat it once more, to be clear:
> 
> Functions that have "well known" names should not be touched. That
> includes fopen (not open_file, neither file_open or filesystem_open_file,
> thankyouverymuch), isaplha, ImageGif, etc., etc. Functions that do not
> have established names (like most third-party libraries) can be named by
> any standard that feels warm on your heart, I have no objection on this.
> 
>
> RC>> I didn't check a manual. Ldap functions aren't named in a mixed
fashion
> RC>> of word_wordword and word_word_word. They follow the *most common*
PHP
> RC>> syntax of using word_word_word.
>
> Don't try to make me believe you remember all the "non-underscore" part of
> all functions by hard and your only problem is knowing where's the
> underscore.
>
> RC>> To stop confusing the *language*, as a whole, we should be doing this
with
> RC>> some consistency, so we're not confusing people as they try to learn
new
> RC>> function names. They shouldn't have to guess, or read the manual,
just
> RC>> to figure out the "proper spacing" in invoking it.
>
> That's not "confusing". That's "remaining in touch with the rest of the
> known world". I do not want function to open file be
> "filesystem_open_file". I want my old trusty fopen. It served me well for
> years.



-- 
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-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS Makefile.in config.m4 php_vpopmail.c php_vpopmail.h

[Boian Bonev]

hi,

[i move this to php-dev where is the right place IMHO]

indeed the library is used by me, you and perhapse two more people (two have
asked how to get/make/use it). my code is not problematic to change - i am
using different servers for test and production and i can change it with not
more than a minute downtime. not to mention that i can build version with
aliases, change the code live and reinstall version without the aliases...

tell us how hard it is to change your code... now is the most appropriate
time to agree on a certain naming convention. there is a huge discussion
about this on php-dev and my opinion is that once released things must not
be changed. it is better two or four of us change our code and achieve
consistency than release this and tomorrow make aliases and stuff...

both ways look ok to me - vpopmail_ and vpopmail_
the api is not something like isalpha and noone is stuck to a name so both
conventions are acceptable now.

btw. i have started an xml doc - would you help me with language stuff -
english is not native for me and i do not feel confident when writing
non-code...

b.

- Original Message -
From: "David Croft" <[EMAIL PROTECTED]>
To: "Andrei Zmievski" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, March 01, 2001 11:02 PM
Subject: Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS
Makefile.in config.m4 php_vpopmail.c php_vpopmail.h


>
> On Tue, 16 Jan 2001, Andrei Zmievski wrote:
>
> > > PHP_FE(vpopmail_passwd, NULL)
> > > PHP_FE(vpopmail_setuserquota, NULL)
> [snip]
> > Didn't we agree to put underscores between words in function names, i.e.
> > vpopmail_del_user?
>
> At the expense of losing compatability with the library's existing naming
> convention?
>
> David
>
>
> --
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP Development Mailing List 
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] anyone with m4 knowledge -> [PHP-DEV] please patch for dbmaker

[Boian Bonev]

forgot to say that in case of [[ the test word is not needed - [[ is a test
itself:

if [[ -x somefile ]]; .

if test -x somefile; 

b.

- Original Message -
From: "Boian Bonev" <[EMAIL PROTECTED]>
To: "André Langhorst" <[EMAIL PROTECTED]>; "PHP Development"
<[EMAIL PROTECTED]>
Sent: Thursday, February 22, 2001 5:40 AM
Subject: Re: [PHP-DEV] anyone with m4 knowledge -> [PHP-DEV] please patch
for dbmaker


> hi,
>
> this is not m4 but /bin/sh stuff... afaik [[ is bash specific boolean
test.
> so the patch _seems_ to be correct...
>
> b.
>
> - Original Message -
> From: "André Langhorst" <[EMAIL PROTECTED]>
> To: "PHP Development" <[EMAIL PROTECTED]>
> Sent: Thursday, February 22, 2001 5:31 AM
> Subject: [PHP-DEV] anyone with m4 knowledge -> [PHP-DEV] please patch for
> dbmaker
>
>
> > could anyone with basic m4 knowledge look into this, this should be a
> > matter of minutes then I guess.
> >
> > andré
> >
> > --
> > · André Langhorstt: +49 331 5811560 ·
> > · [EMAIL PROTECTED]  m: +49 173 9558736 ·
> > * PHP Quality Assurance  http://qa.php.net  *
> >
>
>
> --
--
> 
>
>
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

Re: [PHP-DEV] anyone with m4 knowledge -> [PHP-DEV] please patch for dbmaker

[Boian Bonev]

hi,

this is not m4 but /bin/sh stuff... afaik [[ is bash specific boolean test.
so the patch _seems_ to be correct...

b.

- Original Message -
From: "André Langhorst" <[EMAIL PROTECTED]>
To: "PHP Development" <[EMAIL PROTECTED]>
Sent: Thursday, February 22, 2001 5:31 AM
Subject: [PHP-DEV] anyone with m4 knowledge -> [PHP-DEV] please patch for
dbmaker


> could anyone with basic m4 knowledge look into this, this should be a
> matter of minutes then I guess.
>
> andré
>
> --
> · André Langhorstt: +49 331 5811560 ·
> · [EMAIL PROTECTED]  m: +49 173 9558736 ·
> * PHP Quality Assurance  http://qa.php.net  *
>






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


-- 
PHP 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 #9231 Updated: when usign ob_gzhandler HTTP HEAD does not work

[boian]

ID: 9231
User Update by: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Output Control
Description: when usign ob_gzhandler HTTP HEAD does not work

yep. both seem to be apache SAPI module problem related to ob in general (at least i 
suppose so)

Previous Comments:
---

[2001-02-19 23:03:00] [EMAIL PROTECTED]
similar to Bug id #9031


---

[2001-02-17 11:51:19] [EMAIL PROTECTED]
reopened

---

[2001-02-17 11:50:18] [EMAIL PROTECTED]
HTTP-1.0 and HTTP/1.0 are just the same for apache

this bug report says that ob_gzhandler crashes HEAD requests when php is an apache 
module

---

[2001-02-14 12:25:12] [EMAIL PROTECTED]
shouldn't it reaad

HEAD / HTTP/1.0


bogus


---

[2001-02-12 15:05:20] [EMAIL PROTECTED]
php.ini:
output_handler = ob_gzhandler

tests:

a plain html request:

root@orange:~# telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
HEAD / HTTP-1.0   

HTTP/1.1 200 OK
Date: Mon, 12 Feb 2001 19:57:47 GMT
Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev
Last-Modified: Mon, 04 Dec 2000 13:01:35 GMT
ETag: "ac04-1f6-3a2b95af"
Accept-Ranges: bytes
Content-Length: 502
Connection: close
Content-Type: text/html

Connection closed by foreign host.

php script request:

root@orange:~# telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
HEAD / HTTP-1.0 
host: mail.bonev.com

same php script, but now GET instead of HEAD:

root@orange:~# telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
GET / HTTP/1.0
host: mail.bonev.com

HTTP/1.1 302 Found
Date: Mon, 12 Feb 2001 19:57:22 GMT
Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev
X-Powered-By: PHP/4.0.5-dev
location: /6bcf63364235c745643078ff1e0df2d6/
Connection: close
Content-Type: text/html

Connection closed by foreign host.


---

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


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

Re: [PHP-DEV] PHP 4.0 Bug #9177 Updated: crypt problems with openssl

[Boian Bonev]

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

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

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

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

the best solution is to fix openssl.

b.


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

[PHP-DEV] PHP 4.0 Bug #9231 Updated: when usign ob_gzhandler HTTP HEAD does not work

[boian]

ID: 9231
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Output Control
Description: when usign ob_gzhandler HTTP HEAD does not work

HTTP-1.0 and HTTP/1.0 are just the same for apache

this bug report says that ob_gzhandler crashes HEAD requests when php is an apache 
module

Previous Comments:
---

[2001-02-14 12:25:12] [EMAIL PROTECTED]
shouldn't it reaad

HEAD / HTTP/1.0


bogus


---

[2001-02-12 15:05:20] [EMAIL PROTECTED]
php.ini:
output_handler = ob_gzhandler

tests:

a plain html request:

root@orange:~# telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
HEAD / HTTP-1.0   

HTTP/1.1 200 OK
Date: Mon, 12 Feb 2001 19:57:47 GMT
Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev
Last-Modified: Mon, 04 Dec 2000 13:01:35 GMT
ETag: "ac04-1f6-3a2b95af"
Accept-Ranges: bytes
Content-Length: 502
Connection: close
Content-Type: text/html

Connection closed by foreign host.

php script request:

root@orange:~# telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
HEAD / HTTP-1.0 
host: mail.bonev.com

same php script, but now GET instead of HEAD:

root@orange:~# telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
GET / HTTP/1.0
host: mail.bonev.com

HTTP/1.1 302 Found
Date: Mon, 12 Feb 2001 19:57:22 GMT
Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev
X-Powered-By: PHP/4.0.5-dev
location: /6bcf63364235c745643078ff1e0df2d6/
Connection: close
Content-Type: text/html

Connection closed by foreign host.


---


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


-- 
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 #9231: when usign ob_gzhandler HTTP HEAD does not work

[boian]

From: [EMAIL PROTECTED]
Operating system: Linux glibc 2.1
PHP version:  4.0 Latest CVS (12/02/2001)
PHP Bug Type: Output Control
Bug description:  when usign ob_gzhandler HTTP HEAD does not work

php.ini:
output_handler = ob_gzhandler

tests:

a plain html request:

root@orange:~# telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
HEAD / HTTP-1.0   

HTTP/1.1 200 OK
Date: Mon, 12 Feb 2001 19:57:47 GMT
Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev
Last-Modified: Mon, 04 Dec 2000 13:01:35 GMT
ETag: "ac04-1f6-3a2b95af"
Accept-Ranges: bytes
Content-Length: 502
Connection: close
Content-Type: text/html

Connection closed by foreign host.

php script request:

root@orange:~# telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
HEAD / HTTP-1.0 
host: mail.bonev.com

same php script, but now GET instead of HEAD:

root@orange:~# telnet 0 80
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
GET / HTTP/1.0
host: mail.bonev.com

HTTP/1.1 302 Found
Date: Mon, 12 Feb 2001 19:57:22 GMT
Server: Apache/1.3.17 (Unix) PHP/4.0.5-dev
X-Powered-By: PHP/4.0.5-dev
location: /6bcf63364235c745643078ff1e0df2d6/
Connection: close
Content-Type: text/html

Connection closed by foreign host.



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

[Boian Bonev]

hi,
 
can someone commit the 
following change:
 
Index: 
ext/standard/exec.h===RCS 
file: /repository/php4/ext/standard/exec.h,vretrieving revision 1.6diff 
-u -r1.6 exec.h--- ext/standard/exec.h 2000/09/05 
16:55:32 1.6+++ ext/standard/exec.h 2001/02/07 
17:55:20@@ -29,4 +29,6 
@@ PHP_FUNCTION(shell_exec);  char 
*php_escape_shell_cmd(char *);+int php_Exec(int type, char *cmd, pval 
*array, pval *return_value);+ #endif /* EXEC_H */
 
b.
 
 

Re: [PHP-DEV] The library yes/lib does not exist

[Boian Bonev]

hi,

> > i've seen the same really soon and could track it:
> Cool, I looked further down the specific config.m4 and it
> appears that the zlib check was copied and not modified
> correctly.  Fix committed.

10x :)) it was annoying and hard to track because i have 10+ --with-
configure options.

another thing - i have noticed that when i issue

configure 
make
configure 
make

in phpinfo i get  as config options. also not all of the stuff
is rebuilt properly.
it is not a good idea to rebuild all the stuff. currently less than needed
is rebuilt. especially when i remove modules - when i add everything seems
fine.
i know i can make clean or even distclean but it is not nice...

b.


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

Re: [PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinite function calls causes seg fault

[Boian Bonev]

hi,

> > indeed it is theoretically impossible to track this :)
> >
> > implement a recursive alrorithm for something e.g.:
> >
> > function foo($n) { // calc $n!
> > if ($n<=1)
> > return $n;
> > else
> > return foo($n-1)*$n;
> > }
> >
> > now tell me if it is infinite or finite? ;-) this is a verification and
> > cannot be solved runtime.
> >
> > the best thing that can be done is to set a stack limit (php function
call
> > level) to something reasonable and thus avoid the segfault.
>
> This gives a problem itself, how many levels before the stack is full? Not
> every function call has the same memory footprint, so you can't tell after
> how many levels the stack is full.

of course. but it is better to set something like 1000(or 100) and be
sure that a malicious user cannot exploit it. as far as i remember php local
vars are emalloc-ed and are not on the stack. so there is an average value
like 64(or 640) bytes per stack frame or something...

b.


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

Re: [PHP-DEV] The library yes/lib does not exist

[Boian Bonev]

hi,

i've seen the same really soon and could track it:


checking for DOM support... yes
checking for DOM in default path... found in /usr/local
checking for libxml version... >= 2.2.7
- ac_add_library_path /usr/local/lib

 -lxml -ldb -lgdbm -lcurl -lbz2 -lssl -lcrypto -lresolv -lm -ldl -lcrypt
 -lnsl -lresolv
checking for libz needed by libxml ... already zlib support
--- -lxml -ldb -lgdbm -lcurl -lbz2 -lssl -lcrypto -lresolv -lm -ldl -lcrypt 
-lnsl -lresolv -Lyes/lib -lz
checking whether to enable exif support... no



the --- is debug echo from ext/domxml/config.m4:

withval=$old_withval
  else
echo  $LIBS
echo "checking for libz needed by libxml ... already zlib support"
LIBS="$LIBS -L$withval/lib -lz"
echo --- $LIBS
  fi

  AC_DEFINE(HAVE_DOMXML,1,[ ])
  AC_ADD_LIBRARY(z)



b.

- Original Message -
From: "Sascha Schumann" <[EMAIL PROTECTED]>
To: "Derick Rethans" <[EMAIL PROTECTED]>
Cc: "PHP Developers Mailing List" <[EMAIL PROTECTED]>
Sent: Wednesday, February 07, 2001 1:30 AM
Subject: Re: [PHP-DEV] The library yes/lib does not exist


> On Wed, 7 Feb 2001, Derick Rethans wrote:
>
> > On Wed, 7 Feb 2001, Sascha Schumann wrote:
> >
> > > Please post your full configure line.
>
> Ok, those are quite a lot entries.  Did you add one recently?
> When did you see that kind of error for the first time?  Did
> you change anything related to those third party libraries in
> your system?
>
> - Sascha
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

Re: [PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinite function calls causes seg fault

[Boian Bonev]

hi,

indeed it is theoretically impossible to track this :)

implement a recursive alrorithm for something e.g.:

function foo($n) { // calc $n!
if ($n<=1)
return $n;
else
return foo($n-1)*$n;
}

now tell me if it is infinite or finite? ;-) this is a verification and
cannot be solved runtime.

the best thing that can be done is to set a stack limit (php function call
level) to something reasonable and thus avoid the segfault.

b.

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 07, 2001 12:31 AM
Subject: [PHP-DEV] PHP 4.0 Bug #9136 Updated: simple script with infinite
function calls causes seg fault


> ID: 9136
> Updated by: waldschrott
> Reported By: [EMAIL PROTECTED]
> Status: Closed
> Bug Type: Reproduceable crash
> Assigned To: waldschrott
> Comments:
>
> and guess this "bug" was present in any version before, what
> do you expect to happen here? you will never leave these
> function calls (as you know I guess), as far as your stack
> is full it is full
>
> remember php has to remember each and every function call it
> did...
>
> a()
>b()
>   a()
>  b()
>
>
> if you really need exactly this construct, I would suggest
> you to use a static variable to count the total function
> calls and find the critical values a specific system
> segfaults (with your original code), then you stick a
> for(;;) around it and implement a check (eg. in a()) against
> the static variable to leave the recursion if a value with
> enough distance to the critical value is reached, then you
> should be able to begin the recursion again
>
> any recursion can be displayed as a loop, do not use
> recursion if you want to recurse infinitely
>
> Previous Comments:
> --
-
>
> [2001-02-06 17:22:36] [EMAIL PROTECTED]
> PHP doesn't handle infinite recursion, and as earlier was discussed on the
php-dev list, it wont be implemented to guard for this, because of the high
performance impact.
>
> --
-
>
> [2001-02-06 17:18:03] [EMAIL PROTECTED]
> ---
> <%
>
> function a () {
> b();
> }
>
> function b () {
> a();
> }
>
> a();
>
> %>
>
> done
> -
>
> The simple script above causes a seg fault.  If you need more info on
configuration etc please mail me.  We made this simple example from a more
compilcated instance.  This bug was also present in 4.0.3pl1, we upgraded to
try and stop the seg fault...
>
> thanks!
>
> --
-
>
>
>
> ATTENTION! Do NOT reply to this email!
> To reply, use the web interface found at
http://bugs.php.net/?id=9136&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 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: safe_mode redesign

[Boian Bonev]

hi,

here is something i have posted some days ago:

or better if you have untrusted users who shall have php access, give
them
cgi php and use apache's exec wrapper to setuid to user's uid and chroot to
her home dir.

if their count is not too big run their own web servers under their uids and
again chrooted to their home dirs. this is the best solution i know of.

...

most of the shared hosting environments at least allow one user to access
another's files. not mentioning system access, etc.
a safe_mode will not help in these cases - like named buffer overruns a
safe_mode hole will be discovered weekly.

i am running both configs since apache1.2/php3.0.5 and except performance
issues i have seen no other drawbacks...

b.

- Original Message -
From: "Jason Greene" <[EMAIL PROTECTED]>
To: "Zeev Suraski" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, February 06, 2001 9:53 PM
Subject: [PHP-DEV] Re: safe_mode redesign


> Zeev,
>
> I understand your viewpoint, but I respectfully disagree. I believe that
there are multiple levels of security, and that the OS is
> just part of the picture. There always is some layer of application
security(especially for those apps that run id=0). If you are a
> hosting company ( which is becoming a very large business), then you
desire a way to provide your customers with a programming
> interface that does not infringe on other customers, or your systems
security. Without a safe_mode, 
> is still allowed.
>
> While the details get tricky, and sometime complex, the overall concept is
simple. Before any risky activity is performed, check the
> list of things to block. There are tons of applications out there that
perform these  kind of important checks. ProFTPD is a good
> example of one such application. It allows you to lock users into certain
areas, use specific uids etc.
>
> It seems that your biggest concern is giving users a false sense of
security. This feature is something that would not be used by
> the average user. The people who would mainly be using this would have an
ok knowledge of security, and if you have an ok knowledge,
> then you will know to Never Trust Anything
> There is always a possibility of security methods being penetrated,
everyone just has to be made aware that security is just
> something that rules out the majority of breach attempts. That is why you
need multiple levels
>
> I believe that performing something similar to a chroot in the lower level
file operations, would lock php itself into a protected
> area. PHP is very modular, and has an excellent lower level API., both of
which makes this a very possible thing.
>
> I have spent quite a bit of time customizing PHP to work well in a secure
environment, and I have seen other service providers doing
> the same thing. The problem is that ppl are still going to do this whether
its part of the codebase or not. If all of this work was
> combined, then it can be shared, repaired, and optimized by everyone.
>
> A safe programming chapter could be referred to in documentation as "An
experimental security option designed for ISP and hosting
> providers. This is by no means the finality of security, just a tool to
help
> in developing a secure environment"
>
>
> Thanks,
> Jason
>
> - Original Message --
> From: "Zeev Suraski" <[EMAIL PROTECTED]>
> To: "Jason Greene" <[EMAIL PROTECTED]>
> ACc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Sunday, February 04, 2001 6:43 AM
> Subject: Re: safe_mode redesign
>
>
> > Jason,
> >
> > The one main problem with safe_mode in general is that the idea is
> > problematic by definition.  Security outside the OS level is prone to
> > errors, and a false sense of security is much worse than knowing you're
> > insecure.
> >
> > In my opinion, safe mode should only feature features which can have an
> > infrastructure-level solution, and are not prone to errors.  There
aren't
> > too many of these.  The current safe mode implementation is extremely
prone
> > to errors because it tries to protect opened files, and the way its
built,
> > it's bound to be missing checks in many places...
> >
> > Zeev
> >
> > At 22:53 1/2/2001, Jason Greene wrote:
> > >Is anyone up for a discussion on the redesign of safe_mode? I would
like
> > >to start working on this sometime soon, and I have a lot of
> > >ideas, but I know this is going to be something of a large debate.
> > >
> > >Some of the  new features I think would benefit php include:
> > >
> > >* safe_mode_hide_env_vars - will allow extra protection on removing
> > >environmental vars from hosted users ( I actually have a patch
> > >for this but  I have been waiting on it to discuss the redesign)
> > >
> > >* User configurable policy - safe_mode could have configuration
directives
> > >to specify exactly what checks are desired
> > >
> > >* Virtual Chroot - the ability to perform a chroot to a virtual host
> > >directory structure, so that a hosted user can not access
> > >an

Re: [PHP-DEV] nested functions

[Boian Bonev]

hi,

> Andrei Zmievski wrote:
> > > i'm not sure about it, is this a usefull feature (although it
> > > behaves very different to, say, PASCAL or gcc with nested
> > > functions enabled where the inner function is 'local' to the
> > > namespace of the outer one) or should the engine prevent
> > > nested function declarations in the first place?
> >
> > How about a simple check:
> >
> > function outer()
> > {
> > if (!function_exists('inner')) {
> > function inner() {
> > }
> > }
> > }
>
> sure, this fixes the symptoms,
> bit if noone can think of a reason or situation where nesting
> functions would make sense i'd like to have this 'feature'
> removed
> it's confusing, unseless IMHO and leaving it possible will
> block any chance to implement it the way Pascal or gcc in
> extended mode handle it with the inner function only
> visible within the scope of the outer one ...

we might have both. now all functions are global and this is ok (if people
knew about it). in the future when scope comes in - a modifier before the
function keyword will solve the problem with scoping and more - everything
will be kept backward compatible.
say that the modifier is local or static or...

b.


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

Re: [PHP-DEV] security issue

[Boian Bonev]

hi,

or better if you have untrusted users who shall have php access, give them
cgi php and use apache's exec wrapper to setuid to user's uid and chroot to
her home dir.

if their count is not too big run their own web servers under their uids and
again chrooted to their home dirs. this is the best solution known by me.

b.

- Original Message -
From: "Chris Newbill" <[EMAIL PROTECTED]>
To: "Lou Spironello" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Saturday, February 03, 2001 12:20 AM
Subject: RE: [PHP-DEV] security issue


> A good start would be to make sure the user your web server is running as
> cannot read the shadow file.  Also that the permissions are set properly.
>
> Chris
>
> -Original Message-
> From: Lou Spironello [mailto:[EMAIL PROTECTED]]
> Sent: Friday, February 02, 2001 2:17 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] security issue
>
>
> 
> 
> etc..
> Produces listing of the entire system and dump of the password file.
>
> This is a security hole.
>
> How can I prevent this?
>
> Lou.
>
>
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

Re: [PHP-DEV] PHP 4.0 Bug #9064 Updated: Functions inside functions cause errors if the outer function is called twice.

[Boian Bonev]

hi,


> ID: 9064
> Updated by: hholzgra
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Closed
> Bug Type: Scripting Engine problem
> Assigned To:
> Comments:
>
> php has no "nested function" feature like you'll find in PASCAL
> or in gcc if you enable the feature
>
> what happens here is that test2 is registered on execution of
> test in the global namespace, and when you call test a second time
> it cannot register test2 again
>
> (the engine shouldn't  accept nested functions at all i think)

why not - imagine the case you want to define a function with an
eval('function body here');
at i am using this feature - i have a project with many long functions and
do not need them in all logic paths. i define (let php parse) them on demand
and this is faster. i have tried to have functions in separate files but
this is slower than having all of them into array and etc.

b.




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

Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed.

[Boian Bonev]

hi,

i'd disagree on this - imagine you have a webserver with reasonable load and
99.9% of php page requests use max 10mb ram. you have 1% that use 100mb ram.
then it not a good idea to upgrade to 1g ram just for these 0.1% since each
httpd process will hold 100mb ram after certain time (the 0.1% will spread
on all httpd processes)

on the other side getting and returning ram to the system is not a fast
thing and should be avoided. most common solution is to tell the memory
cache how much ram to held. or preset it at compile time.

i see that my most loaded system (most complex scripts) uses about 10m per
process.

b.

> Seems to me like it would be a lot easier just to add more RAM.  $89 for
> 256M these days.  RAM is cheap.
>
> > That is what we are doing now.  We have it at 5.  Any higher and we are
> > running out.  There is only 128MB of RAM in our machine.  I am
considering
> > switching to CGI PHP just to eliviate this problem.  Of course, that
sucks.
> >
> > > > Yes, yes, I agree ! But this is the problem ! Unfortunatelly "memory
> > > > hungry script" happens from time to time and there's no chance to
prevent
> > > > httpd processes from keeping memory (which is not used again in most
> > > > cases). Maybe it is not a problem for you, but it is for us.
> > >
> > > A quick fix would be to set your MaxRequestsPerChild to a lower value.
> > >



-- 
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] Proposal for updating the PDF-extension

[Boian Bonev]

hi,

> >There are probably other points which need to be discussed like
> >what a function should return if it fails. Many php functions return
> >false but pdflib's api requires to return -1.
>
> Again, we should be consistant within PHP the language.
> ie. if function fails -> RETURN_FALSE.
>
> IMO.

+1

also you can manage extension global errno and handle errors, provide for
example pdf_str_error(void) or something.

most people need not check all possible cases. on the other side it should
be possible and not only possible but easy.

b.


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

Re: [PHP-DEV] EXTENSIONS file refresh..

[Boian Bonev]

hi,

> >>Another thing: Would it be good idea to have the EXPERIMENTAL
> >>text in configure help for such options? This could be automated
> >>in the buildconf ie. it could check if the EXPERIMENTAL is in the
> >>extension's dir and adds the text before/after the option in
> >>the help display..? And maybe even a note after configure that
> >>there are extensions configured in which are considered experimental
> >>thus those might not work as expected.
> >
> >Good idea!
>
> Anyone else agreeing with us? :)

of course. most people don't really bother to read even the configure
output, i suppose 10% (or less) look into ext/extdir to find
readme/experimental.

another idea is to have an extension txt help file shown by configure with
something like --help-extname or so.
anyway these are bells and whistles - good to have but can live without.

b.

pp. Jani, sorry for double mailing but forgot to click reply-all :(


-- 
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] vchkpw (vpopmail) & qmail

[Boian Bonev]

hi,

yes, there is something in progress... it is in development state and there
is no documentation still

the php management of vpopmail is not easy but it may exist in one or
another way. please check the README in ext/vpopmail
get it from php's latest CVS

b.

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 23, 2001 7:34 AM
Subject: [PHP-DEV] vchkpw & qmail


> Is anyone doing anything with PHP and vchkpw?
>
> There isn't much about it in the archives, but I'd hate to wast a bunch
> of time and find out there is already something in progress.
>
>
> I just built a mail server using these packages, and I'm quite
> impressed.  I like the way vchkpw only needs a single user/group to
> manage unlimited virtual domains.




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

[Boian Bonev]

hi,

in the vpopmail module there are two possible implementations of the domain
functions.

one is to call library function, another to exec external binary.

both are needed in different cases - when php is run as root we may call
library,
when php is run as someuser, we need a suid operation and hence the exec.

which one you think is better:

for example the standard function with lib call is:
proto bool vpopmail_add_domain(string domain, string dir, int uid, int gid)

proto bool vpopmail_add_domain_ex(string domain, string dir, int uid, int
gid)
or
proto bool vpopmail_exec_add_domain(string domain, string dir, int uid, int
gid)
or
add optional arg and export only one function
or
...

b.


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS Makefile.in config.m4 php_vpopmail.c php_vpopmail.h

[Boian Bonev]

hi,

sure.

can i ask you another style question?

snips form a config.m4 file:
---
AC_MSG_RESULT(found in $VPOPMAIL_LIB_DIR)
---

---
AC_MSG_CHECKING(for vpopmail install directory)
... code follows...
AC_MSG_RESULT($VPOPMAIL_DIR)
---

i wonder which one is preferable to use.

b.

- Original Message -
> > I just wanted to say that vpopmail's api uses function naming convention
> > which is incomatible with php style. This is the reason to name php
> > functions after vpopmail api, prefixing them with vpopmail_. We can fix
this
> > easy.
>
> The PHP interface to vpopmail does not have to depend on the naming
> conventions used by the vpopmail library.



-- 
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-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS Makefile.in config.m4 php_vpopmail.c php_vpopmail.h

[Boian Bonev]

sorry for broken english.

I just wanted to say that vpopmail's api uses function naming convention
which is incomatible with php style. This is the reason to name php
functions after vpopmail api, prefixing them with vpopmail_. We can fix this
easy.

b.

- Original Message -
From: "Boian Bonev" <[EMAIL PROTECTED]>
To: "Andrei Zmievski" <[EMAIL PROTECTED]>; "PHP Development"
<[EMAIL PROTECTED]>; "David Croft" <[EMAIL PROTECTED]>
Sent: Wednesday, January 17, 2001 5:03 PM
Subject: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS
Makefile.in config.m4 php_vpopmail.c php_vpopmail.h


> hi,
>
> i do not like this too but this are the names exported by vpopmail api.
> this can be changed very easy. i am currently waiting for reply from David
> about what the php api support, what not and how...
>
> b.
> - Original Message -
> From: "Andrei Zmievski" <[EMAIL PROTECTED]>
> To: "David Croft" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, January 16, 2001 4:42 PM
> Subject: Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS
> Makefile.in config.m4 php_vpopmail.c php_vpopmail.h
>
>
> > On Sun, 14 Jan 2001, David Croft wrote:
> > > function_entry vpopmail_functions[] = {
> > > PHP_FE(vpopmail_auth_user, NULL)
> > > PHP_FE(vpopmail_adddomain, NULL)
> > > PHP_FE(vpopmail_deldomain, NULL)
> > > PHP_FE(vpopmail_adduser, NULL)
> > > PHP_FE(vpopmail_deluser, NULL)
> > > PHP_FE(vpopmail_passwd, NULL)
> > > PHP_FE(vpopmail_setuserquota, NULL)
> > > {NULL, NULL, NULL}
> > > };
> >
> > Didn't we agree to put underscores between words in function names, i.e.
> > vpopmail_del_user?
> >
> > -Andrei
> > * Life may be expensive, but it includes an annual free trip around the
> sun. *



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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS Makefile.in config.m4 php_vpopmail.c php_vpopmail.h

[Boian Bonev]

hi,

i do not like this too but this are the names exported by vpopmail api.
this can be changed very easy. i am currently waiting for reply from David
about what the php api support, what not and how...

b.
- Original Message -
From: "Andrei Zmievski" <[EMAIL PROTECTED]>
To: "David Croft" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 16, 2001 4:42 PM
Subject: Re: [PHP-CVS] cvs: php4 /ext/vpopmail .cvsignore CREDITS
Makefile.in config.m4 php_vpopmail.c php_vpopmail.h


> On Sun, 14 Jan 2001, David Croft wrote:
> > function_entry vpopmail_functions[] = {
> > PHP_FE(vpopmail_auth_user, NULL)
> > PHP_FE(vpopmail_adddomain, NULL)
> > PHP_FE(vpopmail_deldomain, NULL)
> > PHP_FE(vpopmail_adduser, NULL)
> > PHP_FE(vpopmail_deluser, NULL)
> > PHP_FE(vpopmail_passwd, NULL)
> > PHP_FE(vpopmail_setuserquota, NULL)
> > {NULL, NULL, NULL}
> > };
>
> Didn't we agree to put underscores between words in function names, i.e.
> vpopmail_del_user?
>
> -Andrei
> * Life may be expensive, but it includes an annual free trip around the
sun. *
>
> --
> PHP CVS Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


-- 
PHP Development Mailing List 
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] TSRM and Zend directories disappeared from cvs

[Boian Bonev]

sorry - too stupid that early in the morning... :((( shame on me

i've done it before, then i've made somthing and...

b.

- Original Message - 


-- 
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] TSRM and Zend directories disappeared from cvs

[Boian Bonev]

hi,
 
do someone know what is happening?
 
b.
 

Re: [PHP-DEV] Hanging process

[Boian Bonev]

hi,

there are several things i can think of - in the order of probability to
happen:

- you use built in mysql client lib and your ext uses something linked to
the /usr/local/mysql/lib/libmysqlclient.so
- your child execs something and waits for pid, output, etc
- there is some mess with memory or something and behavior is hazardous

b.

- Original Message -
From: "Bill McCaffrey" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 15, 2001 8:36 PM
Subject: [PHP-DEV] Hanging process


> I am writing a module for php, every so often an apache process will hang
> when it reaches MaxRequestsPerChild. It grabs all available cpu time, yet
> server-status reports no additional usage. I have removed the
PHP_MSHUTDOWN
> function from my code in case I was making a hash out of something
> inadvertently, yet this has not helped.
>
> It is only occurring 1 in 20 times (approximately) apache tries to close a
> process.
>
> I am new to development on Linux and do not know all the tools available,
is
> there some way that I can find out what this process is doing or at least
if
> the loop is in apache, php or my code so I can trace it back?
>
> Thanks,
>
> Bill
>
>
> --
> 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] module to interface vpopmail

[Boian Bonev]

hi,

i am using vpopmail for a large site with many users signing in or changing
quotas, etc. for those who are not familiar to vpopmail - it is free qmail
addon to implement easy virtual domain management - more info on
http://www.inter7.com/vpopmail/.

the site is wholy php based. for more than an year i were using interafce
module written in php that exec'd suid ~vpopmail/bin/* for various
operations and emulating vpopmail api to php.

since in my setup (and i suppose in most large scale ones) php is built into
apache thus gaining performance over cgi exec and etc., i have decided to
make a php wrapper module for the vpopmail api providing the functionality
through 'native' php calls.

part of vpopmail functionality does not require suid root. only vpopmail and
apache must be run as the same user. this is not a big pain - only domain
management requires qmail interaction and must be implemented as external
process exec.

i think the stuff will be of high interest to all vpopmail users but i
cannot estimate their volume.

i am writing this message to see the interest in this stuff and also get
ideas about the way php modules may be distributed...

b.


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

Re: [PHP-DEV] cgi+dso

[Boian Bonev]

hi,

i'd appreciate this feature very much (perhaps many others also will)...

in most of my setups (about 10 servers) i need to compile both versions and
keeping apache module and command line php setup in sync is somewhat hard
and sometimes problematic ;)

b.

> I was wondering if there's currently any way to compile up
> both the CGI version, and the Apache DSO in a single compile?
>
> Looking at the autoconf stuff implies that there isn't, since
> there's a single PHP_SAPI variable that defaults to cgi.
>
> Is there any interest in this changing?  With the rise of PEAR,
> it's more and more important to provide a binary, and I'd like
> to install it by default on the OpenBSD port.  However, it seems
> a bit wasteful to require two compilations, when the vast majority
> of what is compiling stays the same.
>


-- 
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] fopen() changes, please review this patch

[Boian Bonev]

hi,

only one thing - insted of two empty lines it sounds (at least to me) that a
false value or a single empty line will be ok. there cannot be empty line in
header.

i haven't time to look at the patch, sorry.

b.

- Original Message -
From: "Stig Venaas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 11, 2001 10:09 AM
Subject: [PHP-DEV] fopen() changes, please review this patch


> Hi
>
> I've changed http_fopen_wrapper.c (not in CVS yet) so that it follows
> redirects, just like fopen() did before 4.0.3, which I think is good.
> I've also changed $http_response_header so that all headers will be
> present. For instance if I do fopen("http://yahoo.com/", "r") the
> contents will be:
>
> array(7) {
>   [0]=>
>   string(15) "HTTP/1.0 302 RD"
>   [1]=>
>   string(31) "Location: http://www.yahoo.com/"
>   [2]=>
>   string(0) ""
>   [3]=>
>   string(0) ""
>   [4]=>
>   string(15) "HTTP/1.0 200 OK"
>   [5]=>
>   string(21) "Content-Length: 15315"



-- 
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 #8621 Updated: be careful with interactive cmd line mode

[boian]

ID: 8621
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproduceable crash
Description: be careful with interactive cmd line mode

really i think that merely noone cares about interactive mode but... problem exists in 
latest CVS:

Interactive mode enabled



X-Powered-By: PHP/4.0.5-dev
Content-type: text/html


Segmentation fault

Previous Comments:
---

[2001-01-09 18:26:15] [EMAIL PROTECTED]
tst.php: 

php -a tst.php 

produces:

Interactive mode enabled

X-Powered-By: PHP/4.0.3pl1
Content-type: text/html

Segmentation fault

---

another command line example:

php -a
Interactive mode enabled



X-Powered-By: PHP/4.0.3pl1
Content-type: text/html


Segmentation fault


same result with 4.0.4 soon will test with latest CVS


---


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


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

[PHP-DEV] Re: PHP 4.0 Bug #8242 Updated: the date('B') gives bogus output when system date is Thu Dec 14 01:56:02 EET 20

[Boian Bonev]

hi,

i see you take care about timezones with offset bigger than one day... is it
possible?

thank you :))

b.

- Original Message -
From: "Bug Database" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 10, 2001 8:49 AM
Subject: PHP 4.0 Bug #8242 Updated: the date('B') gives bogus output when
system date is Thu Dec 14 01:56:02 EET 20


> ID: 8242
> Updated by: david
> Reported By: [EMAIL PROTECTED]
> Old-Status: Open
> Status: Closed
> Bug Type: Date/time related
> Assigned To:
> Comments:
>
> fixed with:
> while (beat < 0) {
> beat += 1000;
> }
> beat = beat % 1000;
>
> Swatch Internet Time is very, very sad.
>
> Previous Comments:
> --
-
>
> [2000-12-13 18:59:39] [EMAIL PROTECTED]
> Sometimes in tzones GMT+something the calculation below can give negative
or time greater than 1000
>
> the fix just checks both cases since timezone cannot add more than a day
(or less respectively) or in other terms 1000 swatch beats
>
> case 'B':   /* Swatch Beat a.k.a. Internet Time */
> beat =  (long)the_time)-(((long)the_time) -
> long)the_time) % 86400) + 3600))) * 10) / 864);
>
> -- the fix --
>
> if (beat < 0) beat += 1000;
> if (beat > 999) beat -= 1000;
>
> -- end fix --
>
> sprintf(tmp_buff, "%03d", beat); /* SAFE */
> strcat(return_value->value.str.val, tmp_buff);
> break;
>
> --
-
>
>
> Full Bug description available at: http://bugs.php.net/?id=8242
>
>


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

Re: [PHP-DEV] PHP 4.0 Bug #8622: Using "0" as a key in accociative arrays crashes reset() , next(), etc.

[Boian Bonev]

hi,

the 0 evals to false and stops your for loop, not reset... try the following
loop line instead:

while (list($key,$dummy)=each($groupid)) {

b.

- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 10, 2001 2:05 AM
Subject: [PHP-DEV] PHP 4.0 Bug #8622: Using "0" as a key in accociative
arrays crashes reset() , next(), etc.


> From: [EMAIL PROTECTED]
> Operating system: Linux (also NT)
> PHP version:  4.0.4
> PHP Bug Type: Scripting Engine problem
> Bug description:  Using "0" as a key in accociative arrays crashes reset()
, next(), etc.
>
>print "Using \"0\" as a key in accociative arrays\n"
>."crashes reset() , next(), etc.\n\n";
>
>   $groupid["SHOOT"] = "DARNIT";
>   $groupid["DER"] = "DARNIT";
>   $groupid["FSD"] = "DARNIT";
>   $groupid["SDF"] = "DARNIT";
>   $groupid["DSF"] = "DARNIT";
>   $groupid["0"] = "DARNIT";
>   $groupid["DSF2"] = "DARNIT";
>
>   print "REGULAR VARIABLE REFERENCING WORKS:\n";
>   print "\$groupid[\"SHOOT\"] = ".$groupid["SHOOT"]."\n";
>   print "\$groupid[\"DER\"] = ".$groupid["DER"]."\n";
>   print "\$groupid[\"FSD\"] = ".$groupid["FSD"]."\n";
>   print "\$groupid[\"0\"] = ".$groupid["0"]."\n";
>   print "\$groupid[\"SDF\"] = ".$groupid["SDF"]."\n";
>   print "\$groupid[\"DSF\"] = ".$groupid["DSF"]."\n";
>   print "\$groupid[\"DSF2\"] = "
>.$groupid["DSF2"]."\n";
>
> print "arraycount = ".count($groupid)."\n";
> print "Using 'for (reset(\$groupid); \$key = key(\$groupid);
next(\$groupid))'\n";
> for (reset($groupid); $key = key($groupid); next($groupid)) {
>print "\$groupid[\"$key\"] = $groupid[$key]\n";
> }
> print "\nThe arraycount still works and so does\n"
>  ."referencing the variable, however, the reset()\n"
>  ."next(), and associated functions crash.\n";
> ?>
>
>
> --
> Edit Bug report at: http://bugs.php.net/?id=8622&edit=1
>
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>


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

[PHP-DEV] PHP 4.0 Bug #8621: be careful with interactive cmd line mode

[boian]

From: [EMAIL PROTECTED]
Operating system: Linux glibc 2.1
PHP version:  4.0.3pl1
PHP Bug Type: Reproduceable crash
Bug description:  be careful with interactive cmd line mode

tst.php: 

php -a tst.php 

produces:

Interactive mode enabled

X-Powered-By: PHP/4.0.3pl1
Content-type: text/html

Segmentation fault

---

another command line example:

php -a
Interactive mode enabled



X-Powered-By: PHP/4.0.3pl1
Content-type: text/html


Segmentation fault


same result with 4.0.4 soon will test with latest CVS



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