Re: [PHP-DEV] [PATCH] OCI8 link failure (Tru64/AIX) (#22324)

[Jani Taskinen]

Attached is patch for ext/oci8/config.m4, please try it out.

--Jani


On Tue, 11 Mar 2003, Michael Mauch wrote:

>Jani Taskinen <[EMAIL PROTECTED]> wrote:
>> 
>>I still don't think we should be linking with libocijdbc8 in any case.
>>Can you ask some Oracle support why their libs differ with same version 
>>but in different OSes??
>
>I can try to do so [1], although I don't see what that will buy us.
>
>>From "Oracle9i Administrator's Reference"
><http://download-east.oracle.com/docs/html/A97297_01/ch4_comp.htm#i26133>,
>chapter 4, "Using Oracle Precompilers and the Oracle Call Interface":
>
>| Custom Make Files
>| 
>| Oracle Corporation recommends that you use the provided demo_product.mk
>| make files to create user programs as described in the specific product
>| sections of this chapter.
>| [...]
>| If you choose to use a make utility such as nmake or GNU make, be aware
>| of how macro and suffix processing differs from the make utility
>| provided with the platform. Oracle make files are tested and are
>| supported with the make utility for your platform.
>
>The "demo_product.mk" is in reality called demo_rdbms.mk - and of course
>it's virtually undocumented.
>
>| Oracle library names and the contents of Oracle libraries are subject to
>| change between releases. Always use the demo_product.mk make file that
>| ships with the current release as a guide to determine the required
>| libraries.
>
>Then they go on to explain their "symfind" utility, which is a shell
>script around "find", "grep" and "nm" - with platform-specific output [2].
>
>| Correcting Undefined Symbols (Solaris Only)
>|
>| Oracle provides the symfind utility to assist you in locating a library
>| or object file where a symbol is defined. When linking a program,
>| undefined symbols are a common error that produce an error message
>| similar to the following:
> 
>IMHO this is totally unacceptable. If they can't provide a well-defined
>set of interface libraries, they should at least offer some kind of
>"oci-config" or a few text files with -lsomelib -lanotherlib lines.
>
>But no matter how hard we wish they had some such thing, they don't have
>it at the moment - and even if they would suddenly start to clean up
>that whole mess, it would probably take a long time until their patches
>would be installed everywhere.
>
>I still think that the best solution would be to check if linking with
>-lcntsh alone is enough to get OCILobIsTemporary, and if not, check if
>it works with -locijdbc8.
>
>Regards...
>   Michael
>
>[1]: My question in the "Oracle Technology Network" forum has not been
>answered for two weeks now, ditto in comp.databases.oracle.misc.
>
>[2]: Symfind (or nm) finds the OCILobIsTemporary definition (T) not only
>in libocijdbc8.so, but also in libclntsh.so and a few other libs:
>
>OCILobIsTemporary|  | U | 0008
>^^^ ./lib/libsql8.a
>OCILobIsTemporary| 0004396969863776 | T | 0008
>^^^ ./lib/libnjni8.so
>OCILobIsTemporary| 5408 | T | 0008
>^^^ ./lib/libclient8.a
>OCILobIsTemporary| 5408 | T | 0008
>OCILobIsTemporary|  | U | 0008
>^^^ ./lib/libclntst8.a
>OCILobIsTemporary| 0004396969227952 | T | 0008
>^^^ ./lib/libocijdbc8.so
>OCILobIsTemporary| 0004396962545744 | T | 0008
>^^^ ./lib/libocijdbc8_g.so
>OCILobIsTemporary|  | U | 0008
>^^^ ./lib/libsqlplus.a
>OCILobIsTemporary|  | U | 0008
>^^^ ./lib/libordim8.a
>OCILobIsTemporary| 0004396966909952 | T | 0008
>^^^ ./lib/libclntsh.so
>
>This is on the Compaq/HP test drive with Tru64 5.1 and Oracle 8.1.7.
>
>

-- 
<- For Sale! ->
Index: config.m4
===
RCS file: /repository/php4/ext/oci8/config.m4,v
retrieving revision 1.37.2.3
diff -u -r1.37.2.3 config.m4
--- config.m4   25 Feb 2003 04:37:08 -  1.37.2.3
+++ config.m4   23 Mar 2003 01:17:41 -
@@ -88,14 +88,7 @@
 
 8.1)
   PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIB

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

[Jani Taskinen]

It really doesn't matter anyhow, the HEAD of php4 only works
with ZE2 anyway.

--Jani


On Wed, 19 Mar 2003, Greg Beaver wrote:

>Hi,
>
>shouldn't the first REGISTER_LONG_CONSTANT("T_DOC_COMMENT", etc. etc.) 
>be within the #ifdef ZEND_ENGINE2 at the end of the list of 
>registration, or enclosed within an #ifdef?
>
>Greg
>
>Jani Taskinen wrote:
>> sniper   Wed Mar 19 18:10:27 2003 EDT
>> 
>>   Modified files:  
>> /php4/ext/tokenizer  tokenizer.c 
>>   Log:
>>   And this too..
>>   
>> Index: php4/ext/tokenizer/tokenizer.c
>> diff -u php4/ext/tokenizer/tokenizer.c:1.16 php4/ext/tokenizer/tokenizer.c:1.17
>> --- php4/ext/tokenizer/tokenizer.c:1.16  Wed Mar 19 18:08:58 2003
>> +++ php4/ext/tokenizer/tokenizer.c   Wed Mar 19 18:10:27 2003
>> @@ -259,6 +259,7 @@
>>  REGISTER_LONG_CONSTANT("T_LINE", T_LINE, CONST_CS | CONST_PERSISTENT);
>>  REGISTER_LONG_CONSTANT("T_FILE", T_FILE, CONST_CS | CONST_PERSISTENT);
>>  REGISTER_LONG_CONSTANT("T_COMMENT", T_COMMENT, CONST_CS | CONST_PERSISTENT);
>> +REGISTER_LONG_CONSTANT("T_DOC_COMMENT", T_DOC_COMMENT, CONST_CS | 
>> CONST_PERSISTENT);
>>  REGISTER_LONG_CONSTANT("T_OPEN_TAG", T_OPEN_TAG, CONST_CS | CONST_PERSISTENT);
>>  REGISTER_LONG_CONSTANT("T_OPEN_TAG_WITH_ECHO", T_OPEN_TAG_WITH_ECHO, CONST_CS 
>> | CONST_PERSISTENT);
>>  REGISTER_LONG_CONSTANT("T_CLOSE_TAG", T_CLOSE_TAG, CONST_CS | 
>> CONST_PERSISTENT);
>> @@ -481,6 +482,7 @@
>>  case T_CURLY_OPEN: return "T_CURLY_OPEN";
>>  case T_PAAMAYIM_NEKUDOTAYIM: return "T_DOUBLE_COLON";
>>  #ifdef ZEND_ENGINE_2
>> +case T_DOC_COMMENT: return "T_DOC_COMMENT";
>>  case T_ABSTRACT: return "T_ABSTRACT";
>>  case T_CATCH: return "T_CATCH";
>>  case T_FINAL: return "T_FINAL";
>> 
>> 
>
>

-- 
<- For Sale! ->



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

Re: [PHP-DEV] 4.3.2RC1: patch to compile with libgd < 2

[Jani Taskinen]

Please try the latest STABLE cvs snapshot
from http://snaps.php.net as this seems to be fixed
already.

--Jani


On Sat, 15 Mar 2003, Roberto Biancardi wrote:

>--- ext/gd/gdttf.c.orig Sat Mar 15 22:38:28 2003
>+++ ext/gd/gdttf.c  Sat Mar 15 22:42:42 2003
>@@ -744,9 +744,13 @@
>if (tweencolorkey.pixel > 0) {
>x3 = x2 + col;
>if (x3 >= im->sx || x3 < 0) continue;
>+#if HAVE_LIBGD20
>if (im->trueColor) {
>pixel = &im->tpixels[y3][x3];
>} else {
>+#else
>+   {
>+#endif
> #if HAVE_LIBGD13
>pixel = &im->pixels[y3][x3];
> #else
>
>

-- 
<- For Sale! ->


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

RE: [PHP-DEV] Possible problem in the parser

[Jani Taskinen]

On Fri, 14 Mar 2003, Andi Gutmans wrote:

>You are right that it doesn't behave the same as C. However, personally 
>although it might have been better for it to work like C I don't think it's 
>a good idea to change it now. First of all it would break backwards 
>compatibility in a way which would be hard for people to find where the bug 
>is and how to fix it. Secondly, not meaning to insult anyone here, but I 
>think people who write such code without using parentheses should improve 
>their coding style :)

Amen. :)

--Jani


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

Re: [PHP-DEV] Moderate PHP-DEV

[Jani Taskinen]

On Wed, 12 Mar 2003, Sascha Schumann wrote:

>> I wouldn't consider 3rd one that drastic.
>> It has worked very well for me, I haven't got any spam
>> to my php.net addy, but people who really wanted to send me
>> email got through..
>
>Well, maybe I am an exception, but I usually don't bother to
>"register" myself anywhere, unless there is a really good
>reason.  Thus, the proposed measure increases the bar for
>contributions significantly.

If I remember correctly, this 'registration' is just
replying to single email, as you do when you subscribe to
the list. Not that big deal, IMO. :)

>We don't lose anything by giving the first two items some
>time to prove their usefullness.  On the other hand, it is
>very likely that we will lose useful input, if we implement
>the third item prematurely.

I can live with that. Let's see for couple of weeks how it works.

--Jani



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

Re: [PHP-DEV] Moderate PHP-DEV

[Jani Taskinen]

On Wed, 12 Mar 2003, Sascha Schumann wrote:

>Jani,
>
>> 1. Rename the list to php-group
>
>bad name for obvious reasons.  Georg's suggestion of
>"internals" sounds ok to me.  Or "hackers" from the FreeBSD
>community.

internals,hackers,whatever, as long as it's not php-dev. :)
 
>> 2. Separate the list entries in mailing-lists.php  [DONE!]
>> 3. Apply the same system as is in use for
>
>Let's evaluate the results of the first two items before
>going one step further.  There is no need for haste.

I wouldn't consider 3rd one that drastic.
It has worked very well for me, I haven't got any spam
to my php.net addy, but people who really wanted to send me
email got through..

--Jani



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

Re: [PHP-DEV] Moderate PHP-DEV

[Jani Taskinen]

After reading all the comments, I came to conclusion that
we will do the following compromise:

1. Rename the list to php-group
2. Separate the list entries in mailing-lists.php  [DONE!]
3. Apply the same system as is in use for
   our @php.net addresses for spam-protection,
   but have the message sent to people to tell them
   that where their message is going to go and what the list 
   is about. (for the first message..)
   
This all should be easy/fast to implement..afaik. :I

(And it doesn't restrict anyone from still sending their
support questions here, but at least would cut the amount
a bit..)

So who will rename the list and apply the spam protection thing?
I already did the separation in mailing-lists.php..
  
--Jani



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

Re: [PHP-DEV] Moderate PHP-DEV

[Jani Taskinen]

On Wed, 12 Mar 2003, Andrey Hristov wrote:

> Okay Jani,
>I also read every mail here but a non-related to this mail is easily
>recognizable in 2-3 secs.
  
Whatever. It's still noise.

>Most time loses Derick who answers (thanks).

Yeah, as I don't bother replying to those. :)

>May be the change of the list name is good idea.

For a day or two? :)

--Jani


>Andrey
>
>----- Original Message -
>From: "Jani Taskinen" <[EMAIL PROTECTED]>
>To: "Andrey Hristov" <[EMAIL PROTECTED]>
>Cc: <[EMAIL PROTECTED]>
>Sent: Wednesday, March 12, 2003 7:07 PM
>Subject: Re: [PHP-DEV] Moderate PHP-DEV
>
>
>>
>> It was a 7 hour period. And not only today,
>> this happens daily. (maybe not in this scale)
>> For me, even 1 OT email is too much.
>>
>> (But it's propably just me, who is stupid enough to read
>> EVERY email coming here.)
>>
>> --Jani
>>
>>
>> On Wed, 12 Mar 2003, Andrey Hristov wrote:
>>
>> > I think this is just a bad day :)
>> >
>> >Andrey
>> >
>> >- Original Message -
>> >From: "Jani Taskinen" <[EMAIL PROTECTED]>
>> >To: <[EMAIL PROTECTED]>
>> >Sent: Wednesday, March 12, 2003 6:59 PM
>> >Subject: [PHP-DEV] Moderate PHP-DEV
>> >
>> >
>> >>
>> >> Of about 20 emails today, 6 were posted to wrong mailing
>> >> list. And one of those generated a 5 email thread about not
>> >> posting to wrong mailing list. (counting this one :)
>> >>
>> >> So I suggest we finally make this list MODERATED.
>> >>
>> >> --Jani
>> >>
>> >>
>> >>
>> >> --
>> >> PHP Development Mailing List <http://www.php.net/>
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >>
>> >
>> >
>> >
>>
>> --
>> <- For Sale! ->
>>
>>
>> --
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Moderate PHP-DEV

[Jani Taskinen]

It was a 7 hour period. And not only today,
this happens daily. (maybe not in this scale)
For me, even 1 OT email is too much. 

(But it's propably just me, who is stupid enough to read 
EVERY email coming here.)

--Jani


On Wed, 12 Mar 2003, Andrey Hristov wrote:

> I think this is just a bad day :)
>
>Andrey
>
>- Original Message - 
>From: "Jani Taskinen" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Sent: Wednesday, March 12, 2003 6:59 PM
>Subject: [PHP-DEV] Moderate PHP-DEV
>
>
>> 
>> Of about 20 emails today, 6 were posted to wrong mailing
>> list. And one of those generated a 5 email thread about not
>> posting to wrong mailing list. (counting this one :)
>> 
>> So I suggest we finally make this list MODERATED.
>> 
>> --Jani
>> 
>> 
>> 
>> -- 
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>
>
>

-- 
<- For Sale! ->


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

[PHP-DEV] Moderate PHP-DEV

[Jani Taskinen]

Of about 20 emails today, 6 were posted to wrong mailing
list. And one of those generated a 5 email thread about not
posting to wrong mailing list. (counting this one :)

So I suggest we finally make this list MODERATED.

--Jani



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

Re: [PHP-DEV] Re: php4 /ext/fam fam.c /ext/fbsql php_fbsql.c /ext/hwapi hwapi.cpp /ext/hyperwave hw.c /ext/informix ifx.ec /ext/ingres_iiii.c /ext/interbase interbase.c /ext/ircg ircg.c /ext/ldap

[Jani Taskinen]

Your cvs checkout is broken:

  # cvs -d :pserver:[EMAIL PROTECTED]:/repository co php5

And it works fine.

--Jani


On Tue, 11 Mar 2003, moshe doron wrote:

>>   Renamed OnUpdateInt -> OnUpdateLong to prevent further misunderstandings.
>>   # Intentionally left out any 'alias' for it, this way 3rd party extension
>>   # maintainers will really NOTICE the change.
>
>wl, right now the default php4 tree is broken for cygwin, is this what did u expected 
>to gain?
>
>
>gcc -I/cygdrive/d/php-dev/php4/ext/mysql/libmysql -Iext/mysql/ -I/cygdrive/d/php
>-dev/php4/ext/mysql/ -DPHP_ATOM_INC -I/cygdrive/d/php-dev/php4/include -I/cygdri
>ve/d/php-dev/php4/main -I/cygdrive/d/php-dev/php4 -I/cygdrive/d/php-dev/php4/Zen
>d -I/cygdrive/d/php-dev/php4/ext/xml/expat  -I/cygdrive/d/php-dev/php4/TSRM  -g
>-Wall  -c /cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c -o ext/mysql/php_mysql.
>o  && echo > ext/mysql/php_mysql.lo
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:310: `OnUpdateLong' undeclared he
>re (not in a function)
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:310: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:310: (near initialization for `in
>i_entries[0].on_modify')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:310: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:310: (near initialization for `in
>i_entries[0]')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:311: `OnUpdateLong' undeclared he
>re (not in a function)
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:311: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:311: (near initialization for `in
>i_entries[1].on_modify')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:311: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:311: (near initialization for `in
>i_entries[1]')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:312: `OnUpdateLong' undeclared he
>re (not in a function)
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:312: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:312: (near initialization for `in
>i_entries[2].on_modify')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:312: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:312: (near initialization for `in
>i_entries[2]')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:313: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:313: (near initialization for `in
>i_entries[3]')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:314: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:314: (near initialization for `in
>i_entries[4]')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:315: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:315: (near initialization for `in
>i_entries[5]')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:316: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:316: (near initialization for `in
>i_entries[6]')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:317: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:317: (near initialization for `in
>i_entries[7]')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:318: `OnUpdateLong' undeclared he
>re (not in a function)
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:318: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:318: (near initialization for `in
>i_entries[8].on_modify')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:318: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:318: (near initialization for `in
>i_entries[8]')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:319: `OnUpdateLong' undeclared he
>re (not in a function)
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:319: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:319: (near initialization for `in
>i_entries[9].on_modify')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:319: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:319: (near initialization for `in
>i_entries[9]')
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:320: initializer element is not c
>onstant
>/cygdrive/d/php-dev/php4/ext/mysql/php_mysql.c:320: (near initialization for `in
>i_entries[10]')
>make: *** [ext/mysql/php_mysql.lo] Error 1
>
>
>moshe
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] [patch] solaris getcwd() brokeness

[Jani Taskinen]

Andi, what's the status with this?

--Jani


On Sun, 23 Feb 2003, Wez Furlong wrote:

>Hi Andi (and James)
>
>Andi: I'd appreciate your comments on this patch, specifically if there
>are any concerns about it doing the right thing.
>
>Most people here:
>http://bugs.php.net/bug.php?id=21310&edit=1
>
>report that it fixes their problems with solaris.
>
>I've held off from looking at this, as I didn't want to duplicate any
>effort you have been making.
>
>--Wez.
>
>On Sun, 16 Feb 2003, Andi Gutmans wrote:
>
>> At 03:41 PM 2/13/2003 -0500, James E. Flemer wrote:
>> >RCS file: /repository/TSRM/tsrm_virtual_cwd.c,v
>> >retrieving revision 1.41
>> >diff -u -b -r1.41 tsrm_virtual_cwd.c
>> >--- TSRM/tsrm_virtual_cwd.c 6 Nov 2002 18:07:22 -   1.41
>> >+++ TSRM/tsrm_virtual_cwd.c 13 Feb 2003 20:40:07 -
>> >@@ -303,7 +303,7 @@
>> > return (0);
>> >
>> >  #if !defined(TSRM_WIN32) && !defined(NETWARE)
>> >-   if (IS_ABSOLUTE_PATH(path, path_length)) {
>> >+   if (IS_ABSOLUTE_PATH(path, path_length) || (state->cwd_length < 1)) {
>> > if (use_realpath && realpath(path, resolved_path)) {
>> > path = resolved_path;
>> > path_length = strlen(path);
>>
>> Will realpath() work in cases where getcwd() didn't work? (btw it's nicer
>> to check state->cwd_length == 0 than < 1 IMO).
>>
>> >@@ -363,6 +363,7 @@
>> > }
>> >
>> >
>> >+  if (state->cwd_length > 0 || IS_ABSOLUTE_PATH(path, path_length)) {
>> > ptr = tsrm_strtok_r(path_copy, TOKENIZER_STRING, &tok);
>> > while (ptr) {
>> > ptr_length = strlen(ptr);
>> >@@ -416,6 +417,11 @@
>> > state->cwd[state->cwd_length+1] = '\0';
>> > state->cwd_length++;
>> > }
>> >+  } else {
>> >+   state->cwd = (char *) realloc(state->cwd, path_length+1);
>> >+   memcpy(state->cwd, path, path_length+1);
>> >+   state->cwd_length = path_length;
>> >+  }
>>
>> I'm trying to think if there's some other way of doing this. What is the
>> main problem in this loop? Does it add  / or c:\ in the beginning of the
>> string?
>>
>> Andi
>>
>>
>> --
>> PHP Development Mailing List 
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] [PATCH] OCI8 link failure (Tru64/AIX) (#22324)

[Jani Taskinen]

I still don't think we should be linking with libocijdbc8 in any case.
Can you ask some Oracle support why their libs differ with same version 
but in different OSes??

--Jani


On Sat, 8 Mar 2003, Michael Mauch wrote:

>Hi,
>
>this is a repost of my article from Monday, 03 March. Perhaps it has
>gone unnoticed because of the discussion about OnUpdateInt()? If it was
>noticed, but the patch just sucks, please say so.
>
>
>My older patch for the link problems with OCI8 on Tru64 broke the build
>on AIX and maybe other systems, so Jani commented it out. Here comes a
>better patch. Instead of just linking to libocijdbc8/9 if it is
>available, it tries to find the OCILobIsTemporary function in the normal
>libclntsh first, and does nothing if it's there. Only if
>OCILobIsTemporary is not in libclntsh, another check is done to search
>it in libocijdbc8/9.
>
>I tested it on Linux with Oracle 8.1.6, Tru64 with 8.1.6, 8.1.7 and
>9.0.1, and made sure that libocijdb8/9 is linked only when necessary.
>
>The patch is not yet tested on AIX, though. I'll ask the two people who
>reported bug #22324 after the patch has been applied (or should I ask
>them before the patch is applied, and send them the new configure and
>main/php_config.h.in built here?).
>
>Just before posting this, I became aware that at least here (Linux,
>Oracle 8.1.6), the line
>
>AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ])
>
>results in a core dump at startup, if I use --with-oci8=shared. This is
>a separate problem (#22521), it also happens without my patch. Setting
>OCI_USE_EMALLOC to 1 in oci8.c doesn't change it.
>
>Regards...
>Michael
>
>Index: ext/oci8/config.m4
>===
>RCS file: /repository/php4/ext/oci8/config.m4,v
>retrieving revision 1.37.2.3
>diff -u -B -b -r1.37.2.3 config.m4
>--- ext/oci8/config.m4  25 Feb 2003 04:37:08 -  1.37.2.3
>+++ ext/oci8/config.m4  3 Mar 2003 20:45:03 -
>@@ -89,14 +89,20 @@
> 8.1)
>   PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD)
> 
>-dnl This breaks build on some systems (AIX at least).
>-dnl   if test -f $OCI8_DIR/lib/libocijdbc8.so ; then
>-dnl PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD)
>-dnl   fi
>-
>   PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD)
>+
>+  php_save="$LDFLAGS"
>+  LDFLAGS="-L$OCI8_DIR/lib $LDFLAGS"
>+  AC_CHECK_LIB(clntsh, OCILobIsTemporary, [ ], [
>+AC_CHECK_LIB(ocijdbc8, OCILobIsTemporary, [
>+  PHP_ADD_LIBRARY_WITH_PATH(ocijdbc8, $OCI8_DIR/lib, OCI8_SHARED_LIBADD)
>+], [ ])
>+  ])
>+  LDFLAGS="$php_save"
>+
>   AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ])
>-  AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ])
>+
>+  dnl AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ])
> 
>   dnl 
>   dnl OCI_ATTR_STATEMENT is not available in all 8.1.x versions
>@@ -107,12 +113,17 @@
> 9.0)
>   PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD)
> 
>-dnl This breaks build on some systems (AIX at least)
>-dnl if test -f $OCI8_DIR/lib/libocijdbc8.so ; then
>-dnl   PHP_ADD_LIBRARY(ocijdbc8, 1, OCI8_SHARED_LIBADD)
>-dnl fi
>-
>   PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD)
>+
>+  php_save="$LDFLAGS"
>+  LDFLAGS="-L$OCI8_DIR/lib $LDFLAGS"
>+  AC_CHECK_LIB(clntsh, OCILobIsTemporary, [ ], [
>+AC_CHECK_LIB(ocijdbc9, OCILobIsTemporary, [
>+  PHP_ADD_LIBRARY_WITH_PATH(ocijdbc9, $OCI8_DIR/lib, OCI8_SHARED_LIBADD)
>+], [ ])
>+  ])
>+  LDFLAGS="$php_save"
>+
>   AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ])
>   AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ])
>   AC_DEFINE(HAVE_OCI8_SHARED_MODE,1,[ ])
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] fun with autoconf on Tru64

[Jani Taskinen]

On Fri, 7 Mar 2003, David Hill wrote:

>
>
>> >I set up a debian linux box and after getting the right versions of
>> >things I am still getting the same results from configure. I am
>> >getting a syntax error saying "else" unexpected.
>>
>> With php5 module HEAD?
>
>No - php4 HEAD, should I be doing this with php5 instead ?

Don't even try php4 HEAD, it won't work anyway.
You either use:

  # cvs co -rPHP_4_3 php4

or

  # cvs co php5
  
(with the correct -d option of course)

These are the ONLY useful and up-to-date modules at the moment. 

--Jani


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

Re: [PHP-DEV] fun with autoconf on Tru64

[Jani Taskinen]

On Thu, 6 Mar 2003, David Hill wrote:

>I set up a debian linux box and after getting the right versions of
>things I am still getting the same results from configure. I am
>getting a syntax error saying "else" unexpected.

With php5 module HEAD?
What line is the error at?
What does running the build/buildcheck.sh script output
for the tool versions?

--Jani



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

Re: [PHP-DEV] fun with autoconf on Tru64

[Jani Taskinen]

On Thu, 6 Mar 2003, David Hill wrote:

>I encountered what appears to be a typo in odbc/config.m4:
>+  PHP_EVAL_LIBLINE([$ODBC_LFLAGS $ODBC_LIBS], OBDC_SHARED_LIBADD)
>that should probably be ODBC, but it had nothing to do with my build
>problem.

Good catch..this closed (hopefully) at least one bug report. :)

--Jani



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

Re: [PHP-DEV] Apache2 SAPI

[Jani Taskinen]

On Thu, 6 Mar 2003, Ilia A. wrote:

>On March 6, 2003 11:19 am, Derick Rethans wrote:
>> Our policy is not to merge new things to stable branches (which is
>> PHP_4_3 now).
>
>True, however the apache2handler works much better then the existing 
>apache2filter and as far as I can tell fixes at least 1 crash bug. There 
>maybe more things it fixes, but I have not had the chance to test those yet.
>The only things on my wishlist is some CS cleanup & better Apache info (akin 
>to the one offered by Apache 1) and I hope to have a patch for those shortly.
>The only possible issue that I see with apache2handler, is that is requires 
>the very latest Apache 2, 2.0.44.

I don't think that's an issue. Everyone should be using 2.0.44 anyway,
as it fixes several security related bugs.

  http://www.apache.org/dist/httpd/Announcement2.html
 
(on windows, but still..)

>I think it would be in everyone's best interest if apache2handler was 
>introduced in 4.3.X series & probably replace the current apache2filter all 
>together.

I'm big +1 on this as it can be considered as a FIX..
Let's just replace the other one with this new one.

--Jani



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

Re: [PHP-DEV] Apache2 SAPI

[Jani Taskinen]

On Thu, 6 Mar 2003, Ian Holsman wrote:

>Jani Taskinen wrote:
>| I think it would be okay to just replace the apache2filter
>| with apache2handler altogether..since the former does not
>| work as well anyway.
>|
>| Are there any differences how it is setup in http.conf btw?
>
>no.. not now
>but in previous versions of the setup, it was using
>SetOutputFilter PHP
>SetInputFilter PHP
>which won't work.
>the current implementation doesn't use this method..

So currently, there's no difference how you setup
apache2filter or apache2handler in httpd.conf ??

If so, then IMO, we should just replace the apache2filter
with apache2handler altogether. Also in 4.3.x branch.

And make the configure option --with-apxs2.. :)

--Jani



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

Re: [PHP-DEV] Apache2 SAPI

[Jani Taskinen]

I think it would be okay to just replace the apache2filter
with apache2handler altogether..since the former does not
work as well anyway. 

Are there any differences how it is setup in http.conf btw?

--Jani



On Thu, 6 Mar 2003, Derick Rethans wrote:

>On Thu, 6 Mar 2003, Ian Holsman wrote:
>
>> I've been using the apache2handler on two low/medium-traffic sites for a 
>> while and it appears ok to me.
>> 
>> now.. I'm new to this list, and really don't know how it works, so 
>> excuse me if this is a FAQ or something.
>>
>> I'd like to see this code in 4.3.2/4.3.3?, and if it doesn't blow up,
>> replace the 'apache2filter' as the default apache2 SAPI in a month or two.
>
>Our policy is not to merge new things to stable branches (which is 
>PHP_4_3 now).
>
>> Can I check this into PHP_4 & PHP_4_3 ?
>
>Nope :)
>
>Derick
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] [PATCH] - 64 bit issue with zend_parse_parameterscalls

[Jani Taskinen]

  
Just commit these..

--Jani



On Sat, 1 Mar 2003, Dave Hill wrote:

>Hi all, I am back again
>
>Diff against php4-STABLE-200302241430
>(without the last patch I suggested)
>Applies to 4.5.x and 5.x as well.
>Affects any 64 bit OS.
>
>I ran into another problem after I turned optimization back on. Usually
>these are hell to find, but Julien Soula (who I met through the
>bug database) had encountered this already.
>
>This time I have a 64 bit issue with zend_parse_parameters().
>Luckily the problem is not the implementation, rather the usage.
>
>"s" -> needs a char *, int *
>"l" -> needs a long *
>
>Passing the wrong type into this function will have  unexpected
>results... :-) In my case I was getting string lengths with random
>values in the upper 32 bits making for strings a bit longer than
>in reality.
>
>I did a code inspection (helped by cscope) of the 480 hits,
>checking what the types were passed for s & l entries. I did this
>regardless of if I actually use the code - it was just easier to
>look at them all, but this does mean that I will not be compile
>testing all of them I have 26 changed files. I hope the
>diff will work against 4.5.x and later because that was a lot of
>files to inspect :-p
>
>Where a type like size_t or an enum was used, I converted this to
>a long. I did this because the function is defined as taking a
>long, and in some cases (like enum) you may actually be getting
>an int. Even in a case like size_t where you are probablly safe,
>I have always found it to be safe then sorry.
>
>Interestingly enough I did find one coding error, in
>ext/w32api/w32api.c there are two calls with "s|l" and only
>two arguments passed into the function, so heaven help anyone
>who tries to pass that optional long :-) I guess it is lucky
>that I am using Apache/Unix :-)
>
>Per README.SUBMITTING_PATCH I am trying to copy all
>of the extension owners.
>
>Files affected:
>./ext/domxml/php_domxml.c
>./ext/fdf/fdf.c
>./ext/ftp/php_ftp.c
>./ext/ldap/ldap.c
>./ext/mcrypt/mcrypt.c
>./ext/mhash/mhash.c
>./ext/pgsql/pgsql.c
>./ext/posix/posix.c
>./ext/dio/dio.c
>./ext/sockets/sockets.c
>./ext/standard/exec.c
>./ext/standard/file.c
>./ext/standard/fsock.c
>./ext/standard/head.c
>./ext/standard/html.c
>./ext/standard/metaphone.c
>./ext/standard/string.c
>./ext/sysvsem/sysvsem.c
>./ext/zlib/zlib.c
>./ext/bz2/bz2.c
>./ext/openssl/openssl.c
>./ext/rpc/com/com.c
>./ext/iconv/iconv.c
>./ext/mbstring/mbstring.c
>./ext/mbstring/php_mbregex.c
>./ext/zip/zip.c
>./main/output.c
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[Jani Taskinen]

On Tue, 4 Mar 2003, David Hill wrote:

>
>
>> Is there any specific reason why a single API (OnUpdateLong)
>> is not sufficient?  Is not it a safe assumption that those
>> modules which still use 'int's are simply the result of a
>> mistake on the developer's side?
>
>This is a reasonable assumption actually I can't think of a case
>where a long would not work in place of an int. And given that you are
>talking of only a handfull that would be changed, size would not be an
>issue.

So just 'rename' the OnUpdateInt to OnUpdateLong and replace
all OnUpdateInt with OnUpdateLong? But that doesn't fix anything?

Blah..I'll leave this to David. :)

--Jani




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

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[Jani Taskinen]

Yup, that was the idea. I'll first change them
all to OnUpdateInteger, and then use your patch
to change the ones that need to be long to use OnUpdateLong.

--Jani


On Tue, 4 Mar 2003, David Hill wrote:

>
>
>The patch I sent in should have all of the OnUpdateLong changes in
>them, and the remaining OnUpdateInt should probably be
>OnUpDateInteger. The painful part was actually looking at what was
>passed to match up the calls. That might save you some time.
>
>dave hill
>
>
>>
>> Yes, I know, but we need to remain backwards compatible
>> so I'm adding OnUpdateInteger() and OnUpdateLong().
>>
>> This leaves OnUpdateInt() as it is now. Just need to
>> go through the extensions and change the necessary
>> OnUpdateInt()'s to OnUpdateLong().
>

-- 
<- For Sale! ->


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

[PHP-DEV] OnUpdateLong(), etc. (64bit issues)

[Jani Taskinen]

Attached proposed patch to solve this, just the Zend/ part.
(patch is for PHP_4_3 branch)

--Jani

Index: zend_ini.c
===
RCS file: /repository/Zend/zend_ini.c,v
retrieving revision 1.23.2.1
diff -u -r1.23.2.1 zend_ini.c
--- zend_ini.c  31 Dec 2002 16:23:03 -  1.23.2.1
+++ zend_ini.c  4 Mar 2003 21:40:26 -
@@ -428,6 +428,7 @@
 }
 
 
+/* This should be removed in PHP 5? */
 ZEND_API ZEND_INI_MH(OnUpdateInt)
 {
long *p;
@@ -445,6 +446,44 @@
return SUCCESS;
 }
 
+/*
+ * Note: on 64 bit platforms, sizeof(long) != sizeof(int) and
+ * long* and int* cannot be used interchangably without disaster!
+ * OnUpdateInteger or OnUpdateLong must match the resource type!
+ */
+ZEND_API ZEND_INI_MH(OnUpdateInteger)
+{
+   int *p;
+#ifndef ZTS
+   char *base = (char *) mh_arg2;
+#else
+   char *base;
+
+   base = (char *) ts_resource(*((int *) mh_arg2));
+#endif
+   
+   p = (int *) (base+(size_t) mh_arg1);
+
+   *p = zend_atoi(new_value, new_value_length);
+   return SUCCESS;
+}
+
+ZEND_API ZEND_INI_MH(OnUpdateLong)
+{
+   long *p;
+#ifndef ZTS
+   char *base = (char *) mh_arg2;
+#else
+   char *base;
+
+   base = (char *) ts_resource(*((int *) mh_arg2));
+#endif
+
+   p = (long *) (base+(size_t) mh_arg1);
+
+   *p = zend_atoi(new_value, new_value_length);
+   return SUCCESS;
+}
 
 ZEND_API ZEND_INI_MH(OnUpdateReal)
 {
Index: zend_ini.h
===
RCS file: /repository/Zend/zend_ini.h,v
retrieving revision 1.21.2.1
diff -u -r1.21.2.1 zend_ini.h
--- zend_ini.h  31 Dec 2002 16:23:03 -  1.21.2.1
+++ zend_ini.h  4 Mar 2003 21:40:27 -
@@ -170,7 +170,9 @@
 
 /* Standard message handlers */
 ZEND_API ZEND_INI_MH(OnUpdateBool);
-ZEND_API ZEND_INI_MH(OnUpdateInt);
+ZEND_API ZEND_INI_MH(OnUpdateInt);  /* Remove in PHP 5? */
+ZEND_API ZEND_INI_MH(OnUpdateInteger);
+ZEND_API ZEND_INI_MH(OnUpdateLong);
 ZEND_API ZEND_INI_MH(OnUpdateReal);
 ZEND_API ZEND_INI_MH(OnUpdateString);
 ZEND_API ZEND_INI_MH(OnUpdateStringUnempty);
-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[Jani Taskinen]

   And of course the rest to use OnUpdateInteger()..
   
   --Jani
   

On Tue, 4 Mar 2003, Jani Taskinen wrote:

>
>Yes, I know, but we need to remain backwards compatible
>so I'm adding OnUpdateInteger() and OnUpdateLong().
>
>This leaves OnUpdateInt() as it is now. Just need to
>go through the extensions and change the necessary
>OnUpdateInt()'s to OnUpdateLong().
>   
>--Jani
>
>
>On Tue, 4 Mar 2003, David Hill wrote:
>
>>
>>
>>> So for 4.3.2, we add the OnUpdateLong() and replace
>>> all the calls to OnUpdateInt() to use that instead
>>> and we leave the OnUpdateInt() behaviour same as it was.
>>> This shouldn't cause BC problems then..?
>>
>>If you want to leave the current OnUpdateInt behavior (uses long *
>>internally) ... then that will require some additional changes, as
>>there are a dozen or so places where an int is currently passed to
>>OnUpdateInt, which I left as is because I changed to using
>>OnUpdateLong where a long was used.
>>
>>Dave
>>
>>
>>
>>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[Jani Taskinen]

Yes, I know, but we need to remain backwards compatible
so I'm adding OnUpdateInteger() and OnUpdateLong().

This leaves OnUpdateInt() as it is now. Just need to
go through the extensions and change the necessary
OnUpdateInt()'s to OnUpdateLong().
   
--Jani


On Tue, 4 Mar 2003, David Hill wrote:

>
>
>> So for 4.3.2, we add the OnUpdateLong() and replace
>> all the calls to OnUpdateInt() to use that instead
>> and we leave the OnUpdateInt() behaviour same as it was.
>> This shouldn't cause BC problems then..?
>
>If you want to leave the current OnUpdateInt behavior (uses long *
>internally) ... then that will require some additional changes, as
>there are a dozen or so places where an int is currently passed to
>OnUpdateInt, which I left as is because I changed to using
>OnUpdateLong where a long was used.
>
>Dave
>
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[Jani Taskinen]

On Tue, 4 Mar 2003, Sascha Schumann wrote:

>> So for 4.3.2, we add the OnUpdateLong() and replace
>> all the calls to OnUpdateInt() to use that instead
>> and we leave the OnUpdateInt() behaviour same as it was.
>> This shouldn't cause BC problems then..?
>
>Yes.

Ok, I'll prepare a patch for that.

>> And in 5.0.0 we change OnUpdateInt() to use ints.
>
>No, unless you are into procuring stealth errors which go
>undetected for months.
>
>It would be better drop that interface completely.  Although
>then extension maintainers whose code needs to work with
>several PHP releases will have to resort to preprocessor
>magic once again.

Don't they have to do that anyway..? :)

--Jani



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

Re: [PHP-DEV] [PATCH] - fix for 64 bit issues with OnUpdateInt

[Jani Taskinen]

On Fri, 28 Feb 2003, Andi Gutmans wrote:

>At 04:28 PM 2/28/2003 +0100, Sascha Schumann wrote:
>> > So I think the fix of adding OnUpdateLong() is the correct fix.
>>
>> I was under the impression that OnUpdateInt was actually
>> expecting a long.  I remember changing some int's to long's
>> to address 64 bit issues.  Do I remember this incorrectly?
>
>No, you are correct but misunderstood me. We should introduce 
>OnUpdateLong() for ppl using longs and use OnUpdateInt() for ppl who want 
>to use ints.

So for 4.3.2, we add the OnUpdateLong() and replace
all the calls to OnUpdateInt() to use that instead
and we leave the OnUpdateInt() behaviour same as it was.
This shouldn't cause BC problems then..? 

And in 5.0.0 we change OnUpdateInt() to use ints.

--Jani




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

Re: [PHP-DEV] Tie'ing variables

[Jani Taskinen]

Can't those long names be gone in PHP 5 anyway..? 
Having YASIO is not fun. :)

--Jani




On Sun, 2 Mar 2003, Zeev Suraski wrote:

>I wanted to do this for some time, but until recently, it wasn't very 
>feasible, because the order of registration could be designated by the user 
>(gpc_order, variables_order, etc.).  Now that register_globals is off by 
>default, and that we have the auto-globals, it's much more feasible.
>
>I implemented this optimization in CVS, so far only for $_ENV and 
>$_SERVER.  This alone pushed nearly-empty-page req/sec pages from about 285 
>to about 400 on my Windows box.  I'll look into fixing the other ones later.
>
>Pre-requisites for this optimization to kick in:
>1.  register_globals being off
>2.  register_long_arrays (HTTP_*_VARS) being off
>
>If you want to benchmark w/ vs. w/o, you can disable the optimization by 
>initializing cb to 0 in php_startup_auto_globals() and jit_initialization 
>to 0 in php_hash_environment(), both in main/php_variables.c.
>
>Zeev
>
>At 18:26 01/03/2003, Sterling Hughes wrote:
>>Hi,
>>
>>Analyzing PHP's routines a bit, it seems that the slowest part of a
>>"generic" request is populating the special arrays, $_ENV, $_GET, etc.
>>
>>I was wondering if it might be possible to "tie" these arrays to a
>>function (if you don't understand that, look at Perl for a definition).
>>One could populate them as an overloaded object, and then array accesses
>>would work - I guess.  But I would prefer a cleaner mechanism.
>>
>>This would prevent a costly overhead for elements that don't really need
>>to be there, and yield only a slight performance cost when accessing
>>overloaded elements in these arrays.
>>
>>-Sterling
>>
>>--
>>"The computer programmer is a creator of universes for which he
>>  alone is responsible. Universes of virtually unlimited complexity
>>  can be created in the form of computer programs."
>> - Joseph Weizenbaum
>>
>>
>>--
>>PHP Development Mailing List 
>>To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] bug notification ?

[Jani Taskinen]

No.

--Jani


On Wed, 26 Feb 2003, Corne' Cornelius wrote:

>Are maintainers of extensions automagically notified of bugs submitted 
>regarding the ext's they maintain ?
>
>Corne'
>
>!Exclude Disclaimer!
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Re: Announcement: Next generation ext_skel

[Jani Taskinen]

Krhm...you should make it to produce code that meets 
our coding standards.. :)

Use tabs,  
if (foo) {
   ...
}

etc. 

--Jani



On Wed, 26 Feb 2003, Hartmut Holzgraefe wrote:

>l0t3k wrote:
>> Hartmut,
>>   will this also generate zend_parse_parameters calls based on prototype ?
>> 
>
>Sure, see the two samples below. It even adds return statements for the
>return type specified in the proto where possible.
>
>But unlike the current ext_skel it also supports code generation for
>php.ini values, module globals, constants and resourcetypes ... :)
>
>---
>
>
>   dummy integer conversion
>   int dummy_int(int bar)
>
>
>/* {{{ func int dummy_int(int bar)
>   dummy integer conversion */
>PHP_FUNCTION(dummy_int)
>{
>   int argc = ZEND_NUM_ARGS();
>
>   long bar = 0;
>
>   if (zend_parse_parameters(argc TSRMLS_CC, "l", &bar) == FAILURE) return;
>
>   php_error(E_WARNING, "dummy_int: not yet implemented");
>
>   RETURN_LONG(0);
>}
>/* }}} */
>
>
>---
>
>
>   dummy resource test
>   resource dummy_resource(resource bar)
>
>
>/* {{{ proto resource dummy_resource(resource bar)
>   dummy resource test */
>PHP_FUNCTION(dummy_resource)
>{
>   zval * bar = NULL;
>   int * bar_id = -1;
>   int argc = ZEND_NUM_ARGS();
>
>
>   if (zend_parse_parameters(argc TSRMLS_CC, "r", &bar, &bar_id) == FAILURE) return;
>
>   if (bar) {
> ZEND_FETCH_RESOURCE(???, ???, bar, bar_id, "???", ???_rsrc_id);
>   }
>
>   php_error(E_WARNING, "dummy_resource: not yet implemented");
>}
>/* }}} */
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] "--with-apache" broken in PHP_4_3?

[Jani Taskinen]

eh? Are your apache sources there? :)

--Jani


On Wed, 26 Feb 2003, Sebastian Bergmann wrote:

>  I have installed Apache 1.3.28-dev in /usr/local/apache:
>
>checking for Apache 1.x module support via DSO through APXS... no
>checking for Apache 1.x module support... no
>configure: error: Invalid Apache directory -
>unable to find httpd.h under /usr/local/apache
>
>  httpd.h is in /usr/local/apache/include/.
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] CREDITS/Authors

[Jani Taskinen]

Go ahead. (And don't forget to MFH that config.m4 fix..)
Or the CREDITS file. :)

--Jani


On Tue, 25 Feb 2003, Corne' Cornelius wrote:

>Who adds people to the CREDITS/Authors section of an extension ?
>the maintainers of the module, or someone else assigned to do it ?
>Any objection of adding me to the Informix Extension CREDITS/Authors ?
>
>-Corne'
>
>!Exclude Disclaimer!
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] [WARNING] Release process for 4.3.2 starts RSN..

[Jani Taskinen]

It's just the date for pre1, no need to worry about that yet. :)
(RC1 will be later)

--Jani


On Sun, 23 Feb 2003, Shane Caraveo wrote:

>I wanted to run through all the cgi stuff in detail again for 432, but 
>likely wont have the time by the 26th to do that.
>Shane
>
>Jani Taskinen wrote:
>> To get this thing started, I'm going to roll PHP 4.3.2-pre1
>> on Wednesday, 26th Feb, around 3pm EEST. And I'll announce
>> it on php-general too, to get some more people testing it
>> before we start with any RCs.
>> 
>> Following is collection of bugs marked as critical and verified
>> which should be looked into and dealt with. If not fixed,
>> then please, PLEASE add some comment why they won't ever
>> be fixed and bogus the out.
>> 
>> 
>> Critical:
>>  
>>   http://bugs.php.net/bug.php?id=20190&edit=1 
>>   . Random mem corruption: zend_get_executed_filename() mismatch
>> 
>>   http://bugs.php.net/bug.php?id=21820&edit=1 
>>   . bc break in parser: "$arr[val]" vs "$arr['val']"
>> 
>>   http://bugs.php.net/bug.php?id=22372&edit=1
>>   . Don't forget to bump the PHP API number for 4.3.2 release
>> 
>> 
>> Verified bugs (Scripting Engine related):
>> 
>>   http://bugs.php.net/bug.php?id=15209&edit=1
>> . register_shutdown_function() broke between 4.0.x to 4.1.x
>> - Zeev: Either close as bogus saying it's intended behaviour or 
>> finally get around and FIX IT. ([EMAIL PROTECTED] has a patch?)
>> 
>>   http://bugs.php.net/bug.php?id=21513&edit=1
>> . shutdown functions not executed if timed out [win32 only]
>>   
>>   http://bugs.php.net/bug.php?id=15438&edit=1
>> . include_once fails when comparing output to a value
>> 
>>   http://bugs.php.net/bug.php?id=17997&edit=1
>> . got wanning when combing switch & reference
>>   
>>   http://bugs.php.net/bug.php?id=20548&edit=1
>> . Decrement ("$x[$y]--") doesn't work on uninitiated variable
>> 
>>   http://bugs.php.net/bug.php?id=21478&edit=1
>> . Zend/zend_alloc.c :: shutdown_memory_manager produces segfault
>>   
>>   http://bugs.php.net/bug.php?id=22367&edit=1
>> . undefined variable has a value
>> . RFC: Just bogus with "Don't do this." ?
>> 
>> 
>>   http://bugs.php.net/bug.php?id=21918&edit=1
>> . strange behaviour of mixed type in array-keys
>> . See #21788
>> 
>>   http://bugs.php.net/bug.php?id=21788&edit=1
>> . array_multisort() changes array keys unexpectedly given numeric strings 
>> as keys
>> . See #21918
>> 
>>   Last two are related to each other, afaics, and need some discussion
>>   what we should do about it or if nothing. Also related to these
>>   is http://bugs.php.net/bug.php?id=8325.
>> 
>>
>> --Jani
>> 
>> 
>> 
>> 
>> 
>

-- 
<- For Sale! ->


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

[PHP-DEV] [WARNING] Release process for 4.3.2 starts RSN..

[Jani Taskinen]

To get this thing started, I'm going to roll PHP 4.3.2-pre1
on Wednesday, 26th Feb, around 3pm EEST. And I'll announce
it on php-general too, to get some more people testing it
before we start with any RCs.

Following is collection of bugs marked as critical and verified
which should be looked into and dealt with. If not fixed,
then please, PLEASE add some comment why they won't ever
be fixed and bogus the out.


Critical:
 
  http://bugs.php.net/bug.php?id=20190&edit=1 
  . Random mem corruption: zend_get_executed_filename() mismatch

  http://bugs.php.net/bug.php?id=21820&edit=1 
  . bc break in parser: "$arr[val]" vs "$arr['val']"

  http://bugs.php.net/bug.php?id=22372&edit=1
  . Don't forget to bump the PHP API number for 4.3.2 release


Verified bugs (Scripting Engine related):

  http://bugs.php.net/bug.php?id=15209&edit=1
. register_shutdown_function() broke between 4.0.x to 4.1.x
- Zeev: Either close as bogus saying it's intended behaviour or 
finally get around and FIX IT. ([EMAIL PROTECTED] has a patch?)

  http://bugs.php.net/bug.php?id=21513&edit=1
. shutdown functions not executed if timed out [win32 only]
  
  http://bugs.php.net/bug.php?id=15438&edit=1
. include_once fails when comparing output to a value

  http://bugs.php.net/bug.php?id=17997&edit=1
. got wanning when combing switch & reference
  
  http://bugs.php.net/bug.php?id=20548&edit=1
. Decrement ("$x[$y]--") doesn't work on uninitiated variable

  http://bugs.php.net/bug.php?id=21478&edit=1
. Zend/zend_alloc.c :: shutdown_memory_manager produces segfault
  
  http://bugs.php.net/bug.php?id=22367&edit=1
. undefined variable has a value
. RFC: Just bogus with "Don't do this." ?


  http://bugs.php.net/bug.php?id=21918&edit=1
. strange behaviour of mixed type in array-keys
. See #21788

  http://bugs.php.net/bug.php?id=21788&edit=1
. array_multisort() changes array keys unexpectedly given numeric strings as 
keys
. See #21918

  Last two are related to each other, afaics, and need some discussion
  what we should do about it or if nothing. Also related to these
  is http://bugs.php.net/bug.php?id=8325.

   
--Jani





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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/dba config.m4 dba.cdba_inifile.c php_inifile.h /ext/dba/libinifile .cvsignore inifile.cinifile.h /ext/dba/tests dba_inifile.phpt

[Jani Taskinen]

I kinda missed the point of this thing..any real life examples..? :)

--Jani


On Sat, 22 Feb 2003, Marcus Börger wrote:

>At 18:20 22.02.2003, Marcus Boerger wrote:
>>helly   Sat Feb 22 12:20:06 2003 EDT
>>   Log:
>>   @Added dba handler inifiles to support ini files. (Marcus)
>
>If someone wants to test this stuff:
>
>The layout of the inifile is:
>"["  "]"
> ws* "=" ws*  ws*
>
>The dba keyformat to use is: [ "["  "]" ] [  ]
>
>For example:
>
>dba_insert("[Testgroup]Testvalue", "Value", $f) will insert(append) 
>"Testvalue" with value "Value" to group "Testgroup".
>dba_delete("[Testgroup]Testvalue", $f) will remove the "Testvalue" from the 
>group "Testgroup".
>dba_delete("[Testgroup]", $f) will remove the complete group "Testgroup".
>
>Lines before any group line are possible, too. These are identified by the 
>group "[]" for now.
>Maybe i will change this to "".
>
>Some work is still to be done but in general it works pretty nice here.
>
>regards
>marcus
>
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

[Jani Taskinen]

I object! :) It should be one function with extra parameter
to decide the action..

And named 'file_write_content()'.
And counterpart being 'file_read_content()'.

--Jani


On Thu, 20 Feb 2003, Ilia A. wrote:

>On February 20, 2003 02:51 pm, Sara Golemon wrote:
>
>> Was it decided not to create these?
>
>Yes
>
>> Is it simply a matter of noone having gotten around to it?
>
>Yes
>
>> Am I paying too much attention to the voices in my head?
>
>Maybe ;)
>
>
>Joking aside, I do have a patch to implement the mentioned functionality at 
>http://bb.prohost.org/file2.txt. If there are no objections I'll commit this 
>to the CVS tommorow.
>
>Ilia
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] file_put_contents() / file_add_contents() ?

[Jani Taskinen]

On Thu, 20 Feb 2003, Sara Golemon wrote:

>I recall a discussion sometime back about making file_put_contents() (create
>a file and write the provided contents to it in one command) and
>file_add_contents() (like put but append rather than overwrite) to
>complement file_get_contents() but looking in HEAD I don't see either put or
>add.

   It sure would be nice to have..but why not just one function:

   bool file_write_content(string filename, string data [, bool append [, bool 
use_include_path]]);

   Then you could do something like this:
   
   
   
   Short and simple. With separate functions:

   
  
   btw. Why is that file_get_contents() named like that?
   Wouldn't it better be 'file_read_content()'? 

   --Jani


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

Re: [PHP-DEV] Jumadi

[Jani Taskinen]

Just make this one moderated. (but allow anyone with CVS
access to post freely :)

--Jani



On Thu, 20 Feb 2003, Hartmut Holzgraefe wrote:

>[EMAIL PROTECTED] wrote:
>> Only one question: why not change the name of this mailing list ???
>> 
>> Only a idea.
>
>it is already advertised as
>
>"Internals list
>   A medium volume list for those who want
>   to help out with the development of PHP"
>
>on http://www.php.net/mailing-lists.php,
>
>so maybe changing its name to something like php-internal@
>php-dev-internal@ or php-internal-dev@ might really be
>something to be considered ...?
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] curl bugfix

[Jani Taskinen]

Can you put that patch somewhere where it can be downloaded?
(the bug system mangles it..)

--Jani


On Wed, 19 Feb 2003, Phil Oleson wrote:

>Just posted a fix to a crash causing bug in the curl extension.
>It's applicable to all revs of php. though I only provided a patch
>to HEAD err 5.0 though it should be a quick cut & paste for 4.3.1+
>
>http://bugs.php.net/bug.php?id=22312
>
>Phil.
>
>
>

-- 
<- For Sale! ->


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

[PHP-DEV] PHP Security Advisory: CGI vulnerability in PHP version 4.3.0

[Jani Taskinen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


   PHP Security Advisory: CGI vulnerability in PHP version 4.3.0

Issued on: February 17, 2003
Software:  PHP/CGI version 4.3.0
Platforms: All


   The PHP Group has learned of a serious security vulnerability in 
   the CGI SAPI of PHP version 4.3.0. 
   

Description

   PHP contains code for preventing direct access to the CGI binary with
   configure option "--enable-force-cgi-redirect" and php.ini option
   "cgi.force_redirect". In PHP 4.3.0 there is a bug which renders these
   options useless.
   
   NOTE: This bug does NOT affect any of the other SAPI modules.  
 (such as the Apache or ISAPI modules, etc.)


Impact

   Anyone with access to websites hosted on a web server which employs 
   the CGI module may exploit this vulnerability to gain access to any file
   readable by the user under which the webserver runs.

   A remote attacker could also trick PHP into executing arbitrary PHP code 
   if attacker is able to inject the code into files accessible by the CGI. 
   This could be for example the web server access-logs.


Solution

   The PHP Group has released a new PHP version, 4.3.1, which incorporates
   a fix for the vulnerability. All users of affected PHP versions are
   encouraged to upgrade to this latest version. The downloads web site at

  http://www.php.net/downloads.php
   
   has the new 4.3.1 source tarballs, Windows binaries and source patch
   from 4.3.0 available for download. You will only need to upgrade if 
   you're using the CGI module of PHP 4.3.0. There are no other bugfixes
   contained in this release.


Workaround

   None.

 
Credits

   The PHP Group would like to thank Kosmas Skiadopoulos for discovering 
   this vulnerability.


Copyright (c) 2003 The PHP Group.


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+USOr/HlsOzK2WlERAtLKAJ9GPbPt6Vg77zIcPTGKh78WofmmeACgneDV
tUERfwp/RXtcH13vdv0CGGY=
=rYm5
-END PGP SIGNATURE-



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

Re: [PHP-DEV] Re: php4 /ext/standard/tests/general_functionssunfuncts.phpt

[Jani Taskinen]

On Mon, 17 Feb 2003, moshe doron wrote:

>looks to me unnecessary, since the sixts parameter is the offset.

It affects mktime() and as that timestamp is used to 
generate the SUNFUNCS_RET_TIMESTAMP part of the test,
if it differs, the test fails.

--Jani


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

Re: [PHP-DEV] CLI & long options

[Jani Taskinen]

On Sun, 16 Feb 2003, Moriyoshi Koizumi wrote:

>[EMAIL PROTECTED] (Marcus Börger) wrote:
>
>> Hi,
>> 
>> the patch below allows long option names such as "--version" and "--help"
>> what eases the use of php especially when used on the command line.
>> And it fixes the problem with duplicate error messages if arguments to
>> command line are erroneous.
>>
>> http://marcus-boerger/php/ext/cli-getopt.diff.txt
>
>+1 from me if you are sure it doesn't break BC.

+1 for MFH even if it doesn't break BC. :)

--Jani



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

Re: [PHP-DEV] CLI & long options

[Jani Taskinen]

Erm..that url doesn't look quite ok..? :)

--Jani


On Sat, 15 Feb 2003, Marcus Börger wrote:

>Hi,
>
>the patch below allows long option names such as "--version" and "--help"
>what eases the use of php especially when used on the command line.
>And it fixes the problem with duplicate error messages if arguments to
>command line are erroneous.
>
>http://marcus-boerger/php/ext/cli-getopt.diff.txt
>
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] build no longer working

[Jani Taskinen]

On Fri, 14 Feb 2003, Marcus Börger wrote:


>[marcus@zaphod php4-HEAD]$ m4 --version
>GNU m4 1.4
>[marcus@zaphod php4-HEAD]$ ../make-php-HEAD
>using default Zend directory
>buildconf: checking installation...
>buildconf: autoconf version 2.13 (ok)
>buildconf: automake version 1.5 (ok)
>buildconf: libtool version 1.4.3 (ok)
>rebuilding configure
>configure.in:830: /usr/bin/m4: Undefined macro `AC_PROG_LIBTOOL'

AC_PROG_LIBTOOL is defined in libtool.m4,
which should come from libtool installation.
Most likely you've just got mixed up versions in your
system. Easiest way to get it working is to remove _all_
the auto* tools and libtool. And compile all from sources.
With same prefix..

--Jani


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

RE: [PHP-DEV] Weird PHP5 APXS libtools errors

[Jani Taskinen]

If output of 'm4 --version' != 'GNU m4 1.4'
you need to update it and rebuild autoconf with
the working m4.

--Jani


On Thu, 13 Feb 2003, John Coggeshall wrote:

>>>upgrade your libtool to 1.4.3, it is required now.
>
>[user@localhost php5]# ./buildconf
>using default Zend directory
>buildconf: checking installation...
>buildconf: autoconf version 2.13 (ok)
>buildconf: automake version 1.4-p5 (ok)
>buildconf: libtool version 1.4.3 (ok)
>
>And just to be sure..
>
>[user@localhost php5]# libtool --version
>ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)
>
>Any other thoughts? If there's anything else you need to know, 
>let me know.
>
>John
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Register Shutdown Function for Apache

[Jani Taskinen]

There is now 'HAVE_APACHE' defined when you configure with apache.
(dso or static)

--Jani


On Tue, 11 Feb 2003, Brian Moon wrote:

>Jani, are you volunteering to add it?  If so, please do so at your earliest
>convience.
>
>Brian Moon
>dealnews.com
>
>
>----- Original Message -
>From: "Jani Taskinen" <[EMAIL PROTECTED]>
>To: "Joseph Tate" <[EMAIL PROTECTED]>
>Cc: "Php-Dev List" <[EMAIL PROTECTED]>
>Sent: Monday, February 10, 2003 6:16 PM
>Subject: RE: [PHP-DEV] Register Shutdown Function for Apache
>
>
>|
>| If you need a define for it, we can add one..?
>|
>| --Jani
>|
>|
>| On Mon, 10 Feb 2003, Joseph Tate wrote:
>|
>| >Well, to me, calling the code that flushes the headers and the output
>| >buffers twice doesn't kill us.  Unless someone can come up with a better
>way
>| >to not call these two functions in main/main.c::php_request_shutdown, the
>| >patch suffices for me.  MOD_PHP4_H is undefined in main.c, so it's not
>| >acceptable.
>| >
>| >Joseph
>| >
>| >> -Original Message-
>| >> From: Brian Moon [mailto:[EMAIL PROTECTED]]
>| >> Sent: Monday, February 03, 2003 5:30 PM
>| >> To: Joseph Tate; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>| >> Cc: Php-Dev List
>| >> Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
>| >>
>| >>
>| >> Hmm, there is #define MOD_PHP4_H in sapi/apache/mod_php4.h.  Not real
>| >> descriptive, but seems to be unique to the Apache sapi.
>| >>
>| >> Brian Moon
>| >> dealnews.com
>| >>
>| >>
>| >> - Original Message -
>| >> From: "Joseph Tate" <[EMAIL PROTECTED]>
>| >> To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
>| >> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>| >> Cc: "Php-Dev List" <[EMAIL PROTECTED]>
>| >> Sent: Monday, February 03, 2003 3:45 PM
>| >> Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
>| >>
>| >>
>| >> | Here is an updated patch which copies a few of the methods from
>| >> | main/main.c::php_request_shutdown to
>| >> | sapi/apache/sapi_apache.c::apache_php_module_main.  This has
>| >> flushed both
>| >> | the headers and output buffers in my two test scripts.  Now I need to
>| >> figure
>| >> | out a way to make sure these don't get called in
>| >> | main/main.c::php_request_shutdown on Apache systems.  Any pointers on
>| >> this?
>| >> | Is there a handy #define that I can use if configure is
>| >> called --with-apxs?
>| >> |
>| >> | Joseph
>| >> |
>| >> | P.S.  The two test scripts are:
>| >> |
>| >> | | >> | header('Location: http://www.mi-corporation.com');
>| >> | exit();
>| >> | ?>
>| >> |
>| >> | and
>| >> |
>| >> | | >> | ob_begin();
>| >> | phpinfo();
>| >> | ?>
>| >> |
>| >> | > -Original Message-
>| >> | > From: Brian Moon [mailto:[EMAIL PROTECTED]]
>| >> | > Sent: Tuesday, January 28, 2003 5:50 PM
>| >> | > To: [EMAIL PROTECTED]; Joseph Tate
>| >> | > Cc: Php-Dev List; PHP Group
>| >> | > Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache
>| >> | >
>| >> | >
>| >> | > Give me a patch and I will tell you. ;)
>| >> | >
>| >> | > Brian Moon
>| >> | > dealnews.com
>| >> | >
>| >> | >
>| >> | > - Original Message -
>| >> | > From: "Zeev Suraski" <[EMAIL PROTECTED]>
>| >> | > To: "Joseph Tate" <[EMAIL PROTECTED]>
>| >> | > Cc: "Brian Moon" <[EMAIL PROTECTED]>; "Php-Dev List"
>| >> | > <[EMAIL PROTECTED]>; "PHP Group" <[EMAIL PROTECTED]>
>| >> | > Sent: Tuesday, January 28, 2003 4:03 PM
>| >> | > Subject: RE: [PHP-DEV] Re: Register Shutdown Function for Apache
>| >> | >
>| >> | >
>| >> | > | At 19:54 28/01/2003, Joseph Tate wrote:
>| >> | > | >Then, could we add a sapi_flush()/ob_flush() call at the end of
>| >> | > | >apache_php_module_main after calling the normal
>| >> | > register_shutdown_functions?
>| >> | > |
>| >> | > | Yeah, something along these lines.
>| >> | > |
>| >> | > | >What else might have problems?
>| >> | > |
>| >> | > | Might is a powerful word :)
>| >> | > |
>| >> | > | Zeev
>| >> | > |
>| >> | > |
>| >> | > |
>| >> | >
>| >> | >
>| >> | > --
>| >> | > PHP Development Mailing List <http://www.php.net/>
>| >> | > To unsubscribe, visit: http://www.php.net/unsub.php
>| >> | >
>| >> | >
>| >> | >
>| >> |
>| >>
>| >>
>| >>
>| >
>| >
>| >
>|
>| --
>| <- For Sale! ->
>|
>|
>| --
>| PHP Development Mailing List <http://www.php.net/>
>| To unsubscribe, visit: http://www.php.net/unsub.php
>|
>|
>|
>
>
>

-- 
<- For Sale! ->


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

[PHP-DEV] Build failure with mod_php4.c (PHP_4_3 branch)..

[Jani Taskinen]

The old Apache seems to puke on that stuff you added
some time ago and now merged to the PHP_4_3 branch.

Apache version: IBM HTTP Server 1.3.19.3 (Apache 1.3.20)
 
It propably needs some #ifdefs around it?

--Jani


-- Forwarded message --
Date: 11 Feb 2003 00:40:08 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: #22154 [Com]: fpassthru() fails with files larger than a few
hundered KB

[2003-02-10 18:36:16] [EMAIL PROTECTED]

Can't build snapshot as apache mod...

Here's the error:

/bin/sh /home/joem/php/php4-STABLE-200302102230/libtool --mode=compile
gcc -I/opt/IBMHTTPServer/include -Isapi/apache/
-I/home/joem/php/php4-STABLE-200302102230/sapi/apache/ -DPHP_ATOM_INC
-I/home/joem/php/php4-STABLE-200302102230/include
-I/home/joem/php/php4-STABLE-200302102230/main
-I/home/joem/php/php4-STABLE-200302102230
-I/home/joem/php/php4-STABLE-200302102230/Zend -I/usr/include/libxml2
-I/usr/include/imap -I/home/joem/php/ldap/include
-I/home/joem/php/libmcal -I/usr/local/include
-I/home/joem/php/mysql/include/mysql -I/usr/include/ucd-snmp
-I/home/joem/php/php4-STABLE-200302102230/ext/xml/expat  -DLINUX=22
-DUSE_HSREGEX -DUSE_EXPAT
-I/home/joem/php/php4-STABLE-200302102230/TSRM  -g -Wall  -prefer-pic
-c /home/joem/php/php4-STABLE-200302102230/sapi/apache/mod_php4.c -o
sapi/apache/mod_php4.lo 
gcc -I/opt/IBMHTTPServer/include -Isapi/apache/
-I/home/joem/php/php4-STABLE-200302102230/sapi/apache/ -DPHP_ATOM_INC
-I/home/joem/php/php4-STABLE-200302102230/include
-I/home/joem/php/php4-STABLE-200302102230/main
-I/home/joem/php/php4-STABLE-200302102230
-I/home/joem/php/php4-STABLE-200302102230/Zend -I/usr/include/libxml2
-I/usr/include/imap -I/home/joem/php/ldap/include
-I/home/joem/php/libmcal -I/usr/local/include
-I/home/joem/php/mysql/include/mysql -I/usr/include/ucd-snmp
-I/home/joem/php/php4-STABLE-200302102230/ext/xml/expat -DLINUX=22
-DUSE_HSREGEX -DUSE_EXPAT
-I/home/joem/php/php4-STABLE-200302102230/TSRM -g -Wall -c
/home/joem/php/php4-STABLE-200302102230/sapi/apache/mod_php4.c  -fPIC
-DPIC -o sapi/apache/mod_php4.lo
/home/joem/php/php4-STABLE-200302102230/sapi/apache/mod_php4.c: In
function `sapi_apache_get_fd':
/home/joem/php/php4-STABLE-200302102230/sapi/apache/mod_php4.c:354:
structure has no member named `fd'
make: *** [sapi/apache/mod_php4.lo] Error 1





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

RE: [PHP-DEV] Register Shutdown Function for Apache

[Jani Taskinen]

If you need a define for it, we can add one..?

--Jani


On Mon, 10 Feb 2003, Joseph Tate wrote:

>Well, to me, calling the code that flushes the headers and the output
>buffers twice doesn't kill us.  Unless someone can come up with a better way
>to not call these two functions in main/main.c::php_request_shutdown, the
>patch suffices for me.  MOD_PHP4_H is undefined in main.c, so it's not
>acceptable.
>
>Joseph
>
>> -Original Message-
>> From: Brian Moon [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, February 03, 2003 5:30 PM
>> To: Joseph Tate; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>> Cc: Php-Dev List
>> Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
>>
>>
>> Hmm, there is #define MOD_PHP4_H in sapi/apache/mod_php4.h.  Not real
>> descriptive, but seems to be unique to the Apache sapi.
>>
>> Brian Moon
>> dealnews.com
>>
>>
>> - Original Message -
>> From: "Joseph Tate" <[EMAIL PROTECTED]>
>> To: "Brian Moon" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
>> <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
>> Cc: "Php-Dev List" <[EMAIL PROTECTED]>
>> Sent: Monday, February 03, 2003 3:45 PM
>> Subject: Re: [PHP-DEV] Register Shutdown Function for Apache
>>
>>
>> | Here is an updated patch which copies a few of the methods from
>> | main/main.c::php_request_shutdown to
>> | sapi/apache/sapi_apache.c::apache_php_module_main.  This has
>> flushed both
>> | the headers and output buffers in my two test scripts.  Now I need to
>> figure
>> | out a way to make sure these don't get called in
>> | main/main.c::php_request_shutdown on Apache systems.  Any pointers on
>> this?
>> | Is there a handy #define that I can use if configure is
>> called --with-apxs?
>> |
>> | Joseph
>> |
>> | P.S.  The two test scripts are:
>> |
>> | > | header('Location: http://www.mi-corporation.com');
>> | exit();
>> | ?>
>> |
>> | and
>> |
>> | > | ob_begin();
>> | phpinfo();
>> | ?>
>> |
>> | > -Original Message-
>> | > From: Brian Moon [mailto:[EMAIL PROTECTED]]
>> | > Sent: Tuesday, January 28, 2003 5:50 PM
>> | > To: [EMAIL PROTECTED]; Joseph Tate
>> | > Cc: Php-Dev List; PHP Group
>> | > Subject: Re: [PHP-DEV] Re: Register Shutdown Function for Apache
>> | >
>> | >
>> | > Give me a patch and I will tell you. ;)
>> | >
>> | > Brian Moon
>> | > dealnews.com
>> | >
>> | >
>> | > - Original Message -
>> | > From: "Zeev Suraski" <[EMAIL PROTECTED]>
>> | > To: "Joseph Tate" <[EMAIL PROTECTED]>
>> | > Cc: "Brian Moon" <[EMAIL PROTECTED]>; "Php-Dev List"
>> | > <[EMAIL PROTECTED]>; "PHP Group" <[EMAIL PROTECTED]>
>> | > Sent: Tuesday, January 28, 2003 4:03 PM
>> | > Subject: RE: [PHP-DEV] Re: Register Shutdown Function for Apache
>> | >
>> | >
>> | > | At 19:54 28/01/2003, Joseph Tate wrote:
>> | > | >Then, could we add a sapi_flush()/ob_flush() call at the end of
>> | > | >apache_php_module_main after calling the normal
>> | > register_shutdown_functions?
>> | > |
>> | > | Yeah, something along these lines.
>> | > |
>> | > | >What else might have problems?
>> | > |
>> | > | Might is a powerful word :)
>> | > |
>> | > | Zeev
>> | > |
>> | > |
>> | > |
>> | >
>> | >
>> | > --
>> | > PHP Development Mailing List 
>> | > To unsubscribe, visit: http://www.php.net/unsub.php
>> | >
>> | >
>> | >
>> |
>>
>>
>>
>
>
>

-- 
<- For Sale! ->


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

RE: [PHP-DEV] fix for ext/notes

[Jani Taskinen]

I committed the php_notes.c fixes..but someone who actually
can compile stuff on windows should handle the dsp stuff.

--Jani

p.s. Shouldn't this extension be moved to PECL?


On Thu, 6 Feb 2003, Kai Schröder wrote:

>> Next try with other name.
>
>This version is without indendations (thanks Derick).
>
>Regards, Kai

-- 
<- For Sale! ->


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

Re: [PHP-DEV] PHP4 vs. PECL

[Jani Taskinen]

On Sat, 8 Feb 2003, Kai Schröder wrote:

>some extensions included in the PHP_4_3 branch was moved to PECL (fribidi
>for instance).

Those were only removed from HEAD and not from the PHP_4_3 branch.

--Jani


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

Re: [PHP-DEV] bug #22103

[Jani Taskinen]

On Sat, 8 Feb 2003, Pierre-Alain Joye wrote:

>Hello,
>
>About this bug, I can backport the new functions wroten for the new gd.
>But I do not know if it is allowed to add new functions to the current
>HEAD or 4_3_0. The new functions fix only the filled ellipse/circle
>problem, the new filled_arc cannot be fixed without adding a lot of
>things to the libgd.
>
>Should I go ahead for both 4.3 and head ?

Feel free..

--Jani



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

Re: [PHP-DEV] please apply ext/java fix for sapi/servlet build onUnix

[Jani Taskinen]

Committed.

--Jani


On Thu, 6 Feb 2003, Giuseppe Tanzilli - CSF wrote:

>ciao,
>as from subject,
>please apply this patch to PHP_4_3 branch.
>
>It is needed to complete the fix to build sapi/servlet on Unix
>
>bye
>Giuseppe
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Re: Configure-System on Solaris

[Jani Taskinen]

On Tue, 4 Feb 2003, Melvyn Sopacua wrote:

>At 17:29 4-2-2003, you wrote:
>
>>btw. It seems like that test I added for the broken
>> sed is not working on some systems. Any ideas why?
>
>That's the grep -E part :)
>Just use `egrep' unless any1 knows of a system that doesn't carry egrep?.

egrep is used in PHP 4.3.x..

--Jani



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

Re: [PHP-DEV] Re: Configure-System on Solaris

[Jani Taskinen]

On Tue, 4 Feb 2003, J Smith wrote:

>Jani Taskinen wrote:
>
>> 
>> There should be another version of 'sed' in Solaris which can handle
>> the long lines though. No idea why they have 2 versions.
>
>Never knew that. Is that part of a standard install, or is it bundled in
>some kind of patch, or does it have a different name or something? 

/usr/xpg4/bin/sed

It should be part of standard install too..

--Jani



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

Re: [PHP-DEV] Re: Configure-System on Solaris

[Jani Taskinen]

On Tue, 4 Feb 2003, Sascha Schumann wrote:

>> There should be another version of 'sed' in Solaris which can handle
>> the long lines though. No idea why they have 2 versions.
>
>IIRC that is due to Solaris' BSD heritage.  Solaris 1 (SunOS 4)
>was based on BSD (from the University of California,
>Berkeley, hence ucb) and they had to keep those utilities for
>their customers in SysV-based Solaris 2.

Oh. Well that explains a lot. :)

btw. It seems like that test I added for the broken
sed is not working on some systems. Any ideas why?

--Jani


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

Re: [PHP-DEV] Re: Configure-System on Solaris

[Jani Taskinen]

On Tue, 4 Feb 2003, J Smith wrote:

>Zeev Suraski wrote:
>
>> I don't think we can rely on GNU grep being installed though...
>> 
>
>Well, we pretty much need to rely on GNU sed being installed on Solaris, so
>why not grep, too? The sed problem comes up when doing the final linking
>when building. You usually end up with a collosal libtool line, which makes
>Sun's sed explode, as it can only handle about 4000 characters. (You'll end
>up with sed reporting that the "output line [is] too long".

There should be another version of 'sed' in Solaris which can handle
the long lines though. No idea why they have 2 versions.

--Jani



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

RE: [PHP-DEV] writing test cases

[Jani Taskinen]

On Mon, 3 Feb 2003, Derick Rethans wrote:

>On Mon, 3 Feb 2003, [iso-8859-1] Kai Schröder wrote:
>
>> > that's not true guys, PHP4 is in the PHP_4_3 branch and if you don't
>> > explicitely commit the tests to that branch they won't be there. 
>> > HEAD is PHP5.
>> 
>> Because tests are not in the win32 snaps, I make
>> 
>> cvs -z9 -d :pserver:[EMAIL PROTECTED]:/repository co php4
>> 
>> to checkout the PHP4 branch. Is this wrong?
>
>yes, use:
>
>cvs co -r PHP_4_3 php4
>
>or:
>
>cvs co php5

And don't try to run tests written for HEAD with PHP 4.3.x..

--Jani




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

Re: [PHP-DEV] Question on bug list

[Jani Taskinen]

On Fri, 31 Jan 2003, Marcus Börger wrote:

>I had two questions: One to assign to all NEW messages and one
>feature request to assign to selective bugs...I wanted to avoid reading
>all messages on any bug. Thats overkill...

Get a mail client that can handle threading..

--Jani
   


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

Re: [PHP-DEV] Using IMAP with SSL

[Jani Taskinen]

It wasn't recently, it has been there for quite a long time now. :)
And it does use the same path struct as you have there..
Just pass the directory like this: --with-imap-ssl=/usr and
it will work..

--Jani


On Mon, 27 Jan 2003, Dan Kalowsky wrote:

>Within the cvs HEAD there has been a change made recently to use the 
>--with-imap-ssl tag if the cclient was built with SSL capabilities.
>
>Unfortunately this breaks the build on my end rather drastically as 
>default Darwin builds do not use the //openssl/go here> method, but rather /usr/lib/libssl*.* and 
>/usr/include/openssl/*.h methods.
>
>So this leaves me with the question, does anyone have an idea on how to 
>fix this properly before I start hacking at it?  All responses of 
>'change your OS' nature will be ignored :)
>
> >---<
>Dan Kalowsky"I'll walk a thousand miles just
>http://www.deadmime.org/~dankto slip this skin."
>[EMAIL PROTECTED]- "Streets of Philadelphia",
>[EMAIL PROTECTED]Bruce Springsteen
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] configure broken

[Jani Taskinen]

HEAD only or also with 4.2.3?
And what configure options you used? 

--Jani


On Tue, 28 Jan 2003, Sebastian Bergmann wrote:

>./configure: line 30289: syntax error near unexpected token `fi'
>./configure: line 30289: `fi'
>
>  Here's what my configure looks like arount that line:
>
>30287 if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
>30288   $EGREP "yes" >/dev/null 2>&1; then
>30289
>30290   THIS_LIBS=$LIB
>30291   break
>30292
>30293 else
>30294
>30295 fi
>30296 rm -f conftest*
>30297
>30298
>30299 fi
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Critical Bug #20887

[Jani Taskinen]

On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:

>Hmm... it's natural that when apache is launched at /, it should read 
>/php.ini because of the current implementation shown below.
>
>274 #ifdef INI_CHECK_CWD 
>275 if (strcmp(sapi_module.name, "cli")!=0) {
>276if (*php_ini_search_path) {
>277strcat(php_ini_search_path, paths_separator);  
>278}
>279strcat(php_ini_search_path, ".");
>280 }
>281 #endif

Yeah, but I'm not launching it at /..

--Jani



>Moriyoshi
>
>Jani Taskinen <[EMAIL PROTECTED]> wrote:
>
>> 
>> But unfortunately neither of these fix the bug.
>> If there is php.ini in /, it's still used.
>> 
>> --Jani
>> 
>> 
>> 
>> On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
>> 
>> >+1 for applying this patch.
>> >
>> >and attached is yet another fix as my suggestion.
>> >(a bit dirty, and not tested enough).
>> >
>> >Moriyoshi
>> >
>> >
>> >"Sara Golemon" <[EMAIL PROTECTED]> wrote:
>> >
>> >> I THINK the patch below will fix critical bug #20887, but it's late and
>> >> I've had a long day so I havn't begun to make sure it'll work properly in
>> >> any circumstance, could anyone else have a look and try it out?
>> >> 
>> >> See my note in Bug #20887 for an explanation of what my theory about the
>> >> problem is.
>> >> 
>> >> -Pollita
>> >> 
>> >> Index: main/php_ini.c
>> >> ===
>> >> RCS file: /repository/php4/main/php_ini.c,v
>> >> retrieving revision 1.106
>> >> diff -u -r1.106 php_ini.c
>> >> --- main/php_ini.c  12 Nov 2002 20:56:47 -  1.106
>> >> +++ main/php_ini.c  12 Dec 2002 06:49:50 -
>> >> @@ -298,7 +298,9 @@
>> >> char *separator_location =
>> >> strrchr(binary_location, DEFAULT_SLASH);
>> >> 
>> >> if (separator_location) {
>> >> -   *(separator_location+1) = 0;
>> >> +   separator_location[0] = '\0';
>> >> +   } else {
>> >> +   binary_location[0] = '\0';
>> >> }
>> >> if (*php_ini_search_path) {
>> >> strcat(php_ini_search_path, paths_separator);
>> >> 
>> >> 
>> >> 
>> >> 
>> >> -- 
>> >> PHP Development Mailing List <http://www.php.net/>
>> >> To unsubscribe, visit: http://www.php.net/unsub.php
>> >> 
>> >
>> 
>> -- 
>> <- For Sale! ->
>> 
>> 
>> -- 
>> PHP Development Mailing List <http://www.php.net/>
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Re: #20947 [Opn->Bgs]: imap won't configure or compile

[Jani Taskinen]

On Thu, 12 Dec 2002, Derick Rethans wrote:

>On Thu, 12 Dec 2002, Jani Taskinen wrote:
>
>> On Thu, 12 Dec 2002, Derick Rethans wrote:
>> 
>> >> 
>> >> /configure --with-apxs=/usr/local/apache/bin/apxs
>> >> --with-config-file-path=/etc --with-mysql --with-mcrypt
>> >> --with-openssl=/us
>> >> r/local/ssl --with-imap-ssl=/usr/local/lib
>> >>
>> 
>> Last option, the path..anything wrong in it?
>
>Right, I see that now. But if you just put that in the "quick fix 
>comment" section this (l)user would be happy, and the problem is noted 
>in the bugreport too for further use.

"Give man a fish and he lives a day, teach him how to fish.." :)

Point being: People are too hasty reporting bugs. And too lazy
to search archives, bug database, etc.

--Jani



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

Re: [PHP-DEV] Re: #20947 [Opn->Bgs]: imap won't configure or compile

[Jani Taskinen]

On Thu, 12 Dec 2002, Derick Rethans wrote:

>> 
>> /configure --with-apxs=/usr/local/apache/bin/apxs
>> --with-config-file-path=/etc --with-mysql --with-mcrypt
>> --with-openssl=/us
>> r/local/ssl --with-imap-ssl=/usr/local/lib
>>

Last option, the path..anything wrong in it?

--Jani


>> output:
>> checking for IMAP support... no
>> After running make and make install and restarting apache (DSO module)
>> tried to use imap:
>> Fatal error:  Call to undefined function:  imap_open() in
>> /var/www/htdocs/tickets/imap_create.php on line 11
>> 
>> 2. Tried without "with-imap-ssl", but with "--with-imap":
>> 
>> ./configure --with-apxs=/usr/local/apache/bin/apxs
>> --with-config-file-path=/etc --with-mysql --with-mcrypt
>> --with-openssl=/u
>> sr/local/ssl --with-imap
>> 
>> output:
>> configure: error: This c-client library is built with SSL support.
>> 
>>   Add --with-imap-ssl<=DIR> to your configure line. Check
>> config.log for details.
>> 
>> So, the configure script is finding the c-client libraries.
>> 
>> Output from config.log:
>> 
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:268: the use
>> of `tmpnam' is dangerous, better use `mkstemp'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:281: undefined
>> reference to `RAND_seed'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:286: undefined
>> reference to `SSL_library_init'
>> /usr/local/lib/libc-client.a(osdep.o): In function `ssl_start_work':
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:388: undefined
>> reference to `TLSv1_client_method'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:388: undefined
>> reference to `SSLv23_client_method'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:388: undefined
>> reference to `SSL_CTX_new'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:391: undefined
>> reference to `SSL_CTX_ctrl'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:395: undefined
>> reference to `SSL_CTX_set_verify'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:397: undefined
>> reference to `SSL_CTX_set_default_verify_paths'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:398: undefined
>> reference to `SSL_new'
>> /install/imap-2002a.DEV.SNAP-0212051126/c-client/osdep.c:400: undefined
>> reference to `BIO_new_socket'
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Edit this bug report at http://bugs.php.net/?id=20947&edit=1
>> 
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Critical Bug #20887

[Jani Taskinen]

But unfortunately neither of these fix the bug.
If there is php.ini in /, it's still used.

--Jani



On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:

>+1 for applying this patch.
>
>and attached is yet another fix as my suggestion.
>(a bit dirty, and not tested enough).
>
>Moriyoshi
>
>
>"Sara Golemon" <[EMAIL PROTECTED]> wrote:
>
>> I THINK the patch below will fix critical bug #20887, but it's late and
>> I've had a long day so I havn't begun to make sure it'll work properly in
>> any circumstance, could anyone else have a look and try it out?
>> 
>> See my note in Bug #20887 for an explanation of what my theory about the
>> problem is.
>> 
>> -Pollita
>> 
>> Index: main/php_ini.c
>> ===
>> RCS file: /repository/php4/main/php_ini.c,v
>> retrieving revision 1.106
>> diff -u -r1.106 php_ini.c
>> --- main/php_ini.c  12 Nov 2002 20:56:47 -  1.106
>> +++ main/php_ini.c  12 Dec 2002 06:49:50 -
>> @@ -298,7 +298,9 @@
>> char *separator_location =
>> strrchr(binary_location, DEFAULT_SLASH);
>> 
>> if (separator_location) {
>> -   *(separator_location+1) = 0;
>> +   separator_location[0] = '\0';
>> +   } else {
>> +   binary_location[0] = '\0';
>> }
>> if (*php_ini_search_path) {
>> strcat(php_ini_search_path, paths_separator);
>> 
>> 
>> 
>> 
>> -- 
>> PHP Development Mailing List 
>> To unsubscribe, visit: http://www.php.net/unsub.php
>> 
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] php.exe - php-cgi.exe

[Jani Taskinen]

On Wed, 11 Dec 2002, Edin Kadribasic wrote:

>> So i am -1 on renaming CLI
>> And +1 on keeing CGI as php-cgi and CLI as php
>> 
>> marcus
>
>Just for the record: my vote is the same.

  .o/
  
  --Jani
  


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

Re: [PHP-DEV] 4.3 when?

[Jani Taskinen]

On Mon, 9 Dec 2002, Andi Gutmans wrote:

>At 02:13 PM 12/9/2002 +0200, Jani Taskinen wrote:
>>On Mon, 9 Dec 2002, Andi Gutmans wrote:
>>
>> >Hi,
>> >
>> >I'd like to start working towards a beta of ZE2 but it seems that 4.3 is
>> >still lingering and I'd like to wait until after 4.3.
>> >What's happening with that? Shouldn't we get it out before Christmas?
>>
>> Try checking the "Verified" and "Critical" bugs for e.g. "Scripting 
>> Engine Problem"
>> once and a while..
>
>That's the answer to my question? I don't see any bug there which is a show 
>stopper for 4.3.

Heh..so it's a good reason not to bother fixing/looking into them?
I thought bugs marked as "Critical" were supposed to be fixed before
release? 

--Jani



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

Re: [PHP-DEV] 4.3 when?

[Jani Taskinen]

On Mon, 9 Dec 2002, Andi Gutmans wrote:

>Hi,
>
>I'd like to start working towards a beta of ZE2 but it seems that 4.3 is 
>still lingering and I'd like to wait until after 4.3.
>What's happening with that? Shouldn't we get it out before Christmas?

Try checking the "Verified" and "Critical" bugs for e.g. "Scripting Engine Problem"
once and a while..

--Jani


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

Re: [PHP-DEV] bugs.php.net categories for PECL modules

[Jani Taskinen]

On 9 Dec 2002, Christian Stocker wrote:

>Hi
>
>as PECL is getting more and more attention, it would be nice, if they
>had their own categories in bugs.php.net. There's category "PEAR", but I
>don't think this is the right place. The question for me is just, if
>they should be in a PECL topcategory or just in the appropriate other
>categories (in our case, should imagick be in PECL/imagick or in
>Graphics/imagick?)
>
>What do others think?


It needs it's own bug system. Please don't add anymore 
categories in the existing one, it's full.
 
--Jani



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

Re: [PHP-DEV] php.exe - php-cgi.exe

[Jani Taskinen]

On Mon, 9 Dec 2002, Shane Caraveo wrote:

>
>> 
>> Simply because calling the command line interface should be easy - as easy
>> as calling awk or perl or whatever. Every server api module like cgi must be
>> installed, so the name does not matter there. But having long names for
>> command line utils is a bad idea.
>> 
>> marcus
>> 
>> 
>
>Well, fortunately I never have time for qa, handling bugs, etc. etc. so
>I wont have to deal with the backlash that this name change **WILL**
>cause.  I feel sorry for those who have the time to deal with it, as
>that will be about all they will deal with, rather than handling more
>important bugs and issues.  Basicly, the namechange goes against several

Don't worry, we'll make some quick-resolve for it too.
We didn't get overwhelmed by that register_globals issue either.
(like some people thought we would :)

>years of history in php, tons of documentation, general community
>knowledge, etc., and top it off with the fact that in reality, probably
>less than 1 percent of users use php as a command line language.

It's evolution. :) And we do hope that the amount of people using 
PHP on command line increases. Besides, having the "php-cgi" binary
makes it very clear what it is about. But naming the CLI binary 
"php-cli" definately does not.

I'm actually a bit uncertain why we actually have separate binaries.
(or I've forgot why they were separated..anyone?)
 
--Jani



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

Re: [PHP-DEV] Re: #20755 [Opn->Ver]: exif relocation error)

[Jani Taskinen]

On Tue, 3 Dec 2002, Moriyoshi Koizumi wrote:

>--snip
>> If you compile mbstring as static module, you can workaround this
>> error. It's not very good idea to enable it anyway..
>
>I'm wondering why you referred to enabling mbstring as no good idea
>in this report. I believe the problem has been properly avoided, or am I 
>missing something?

Maybe I just assumed something, but I think this person really 
doesn't even need it. :) That's why I also noted about enabling 
only extensions that he actually needs.

The biggest concern about mbstring for me is that it changes some core
functions behaviour. I haven't followed the development of mbstring 
closely so I might be wrong here..just that one major bug caused by 
that duplication of code (for post vars parsing) gives me creeps. :)

As long as it's separate from core PHP, I will never suggest anybody
to use it.

>> For the mbstring authors: You should decide whether or not to allow
>> external usage of these functions (ie. in other extensions) or disable
>> the building of this extension as shared altogether..
>
>What decision? We actually externalise some functions just for that 
>purpose. Perhaps did you mean integration of mbstring into core part?

Yes. But mbstring is not the only extension having the same problem
when compiled as shared. At least iconv, openssl, pcre and gd also 
have some external parts used outside them. e.g. All the extensions
and core parts using those externalized functions in mbstring must
now put these around the parts using those:

#ifndef COMPILE_DL_MBSTRING
#endif

This is done in some places, but not everywhere, like shown by 
the bug report. 

The same problem is also with PCRE and GD extensions. 
One solution would be to make at least PCRE and MBstring always
static, ie. disallow building them as shared. Or move them
under ext/standard..

With openssl and iconv it's a bit different, the same libraries
are required by other extensions. This problem could be solved by
linking the core PHP always with those, even when compiling openssl
or iconv as shared extensions.

>BTW we are now working on a new mbstring API specification so that other 
>extension authors can use the functions with more convenience and in no 
>more doubt about their usage. If we should treat it in a special way,
>please let us know.

Yeah, keep it simple. :)

--Jani


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /sapi/cgi cgi_main.c

[Jani Taskinen]

On Mon, 2 Dec 2002, Shane Caraveo wrote:

>There are bugs in the bug database that this fixes also, one example: 
>http://bugs.php.net/bug.php?id=19378
>
>There are also bugs marked as bogus that probably were not, one example: 
>http://bugs.php.net/bug.php?id=10075.  (CGI and PATH_INFO aparently is 
>not understood in this instance)

Could you please go through those reports and close them
as fixed..? :)

--Jani



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

Re: [PHP-DEV] Error during buildconf..

[Jani Taskinen]

On Sun, 1 Dec 2002, Shane Caraveo wrote:

>Jani Taskinen wrote:
>> On Mon, 2 Dec 2002, Jani Taskinen wrote:
>> 
>> 
>>>   I get this with PHP_4_3_0 branch (with Linux):
>>>   
>>>/usr/bin/autoheader: Symbol `ssize_t' is not covered by 
>/usr/share/autoconf/acconfig.h ./acconfig.h
>>>   
>>>   And main/php_config.h.in is not created. 
>>>   (this does not happen with HEAD)
>>>
>> 
>> 
>> Forgot to test after noticing this..the build does not work
>> at all now. (of course, as php_config.h.in is missing, php_config.h
>> ends up being an empty file..)
>> 
>
>Well, I can't recreate the problem in either 43 or HEAD.

It's that sapi/cgi/libfcgi/acinlude.m4 that causes it.

--Jani



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

Re: [PHP-DEV] Error during buildconf..

[Jani Taskinen]

On Mon, 2 Dec 2002, Jani Taskinen wrote:

>
>I get this with PHP_4_3_0 branch (with Linux):
>
> /usr/bin/autoheader: Symbol `ssize_t' is not covered by 
>/usr/share/autoconf/acconfig.h ./acconfig.h
>
>And main/php_config.h.in is not created. 
>(this does not happen with HEAD)
>

Forgot to test after noticing this..the build does not work
at all now. (of course, as php_config.h.in is missing, php_config.h
ends up being an empty file..)


--Jani



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

Re: [PHP-DEV] Error during buildconf..

[Jani Taskinen]

On Sun, 1 Dec 2002, Shane Caraveo wrote:

>Is this just starting?  How long since your last configured?  I just 
  
Not sure when this has started, I just happened to notice it now..
(I usually don't pay attention to the output of buildconf :)

>added two new m4 files, but they shouldn't get used unless you 
>--enable-fastcgi, did you do that?

That doesn't matter here, and I doubt it was any of those changes.

--Jani

p.s. And the correct error was about 'ssize_t'..


>Magnus Määttä wrote:
>> On Mon, 2 Dec 2002 04:39:34 +0200 (EET)
>> Jani Taskinen <[EMAIL PROTECTED]> wrote:
>> 
>> 
>>>I get this with PHP_4_3_0 branch (with Linux):
>>>
>>> /usr/bin/autoheader: Symbol `size_t' is not covered by 
>/usr/share/autoconf/acconfig.h ./acconfig.h
>>>
>> 
>> 
>> I get the same result and this too (in both HEAD and 4.3 branch):
>> 
>> /usr/bin/autoheader-2.13: Symbol `uint' is not covered by 
>/usr/share/autoconf/acconfig.h
>> /usr/bin/autoheader-2.13: Symbol `ulong' is not covered by 
>/usr/share/autoconf/acconfig.h
>> 
>> The same problem is on Tru64.
>> 
>> 
>> 
>>>And main/php_config.h.in is not created. 
>>>(this does not happen with HEAD)
>>>
>> 
>> 
>> And not in HEAD either for me.
>> 
>> 
>> 
>>>--Jani
>>>
>>>
>>>-- 
>>>PHP Development Mailing List <http://www.php.net/>
>>>To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>
>> 
>> 
>
>
>
>

-- 
<- For Sale! ->


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

[PHP-DEV] Error during buildconf..

[Jani Taskinen]

I get this with PHP_4_3_0 branch (with Linux):

 /usr/bin/autoheader: Symbol `size_t' is not covered by 
/usr/share/autoconf/acconfig.h ./acconfig.h

And main/php_config.h.in is not created. 
(this does not happen with HEAD)


--Jani


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

Re: [PHP-DEV] PHP 4.3 broken CGI behaviour

[Jani Taskinen]

On Sun, 1 Dec 2002, Shane Caraveo wrote:

>Hello,
>I just commited patches to fix CGI running under Apache.  This also 
>fixes issues with incorrect CGI environment variables that are received 
>under ScriptAlias based CGI or mod_fastcgi.  My previous email 
>describing this is at 
>http://marc.theaimsgroup.com/?l=php-dev&m=103834043816376&w=2
>
>Essentialy, I think that these patches should be put into 4.3, due to 
>the extreme broken behaviour that 4.3 currently has in CGI mode. 
>However, since i'm not involved in release management, I'll leave the 
>decision to do that to those who are.

These are fixes, feel free to do the MFH..

--Jani



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

RE: [PHP-DEV] Redirect on Error (not localisation)

[Jani Taskinen]

On Tue, 26 Nov 2002, John Coggeshall wrote:

>
>Unless told otherwise, I'm already planning on making a few changes and
>committing.

Like I said earlier, forget it. -1 from me too.

--Jani



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

Re: [PHP-DEV] Concrete suggestion re: i18n messages

[Jani Taskinen]

On Tue, 26 Nov 2002, Wez Furlong wrote:

>If I wanted localized error messages, then this would be the way to do
>it.  Perhaps merging this with the php_error_docref might be slightly
>better.
>
>However, I'm personally -1000 on such things; there are many reasons,
>most of them have already been raised here, so I won't repeat them now,
>but the main issue is with the maintainability of such a thing;
>localization is very hard to maintain on a volunteer basis (just look at
>our manual).
>
>For something as important as error messages, it is better to have the
>"definitive" error message in english and then take advantage of the
>hyperlink generated by php_error_docref which will display more detailed
>information in the localized manual.

+ for this. It's already there, so
let's use it and forget this nonsense of adding some extra work
for developers.

--Jani



>--Wez.
>
>On Tue, 26 Nov 2002, Sascha Schumann wrote:
>
>> A possible implementation would look like this:
>>
>> A new ini setting is added.
>>
>> php.error_lang
>>
>> A new function is provided.
>>
>> php_error_ex(int type, const char *err_code, const char *fmt, ...);
>>
>> The function tries to lookup the  key in
>> php-.cat.  If it exists, the value will be
>> used instead of the format .  The control is then passed
>> to php_verror().
>>
>> That sounds like 30-50 additional LOC to me.  No bloat in
>> sight.
>>
>> The program which generates the .cat files (gen-cat) will
>> ensure that the error code is prepended to the format
>> message.  That could be a simple C file with another 50 LOC,
>> parsing input files of the form
>>
>> file: file line | line
>> line: ERROR-CODE MSG
>>
>> Each extension can maintain its own file (e.g. cat.session.nl for
>> the NL version of the session error messages).  During
>> .cat build-time, a single per-language file is generated and
>> fed through gen-cat.  The result can then be used by PHP.
>>
>> There, simple and straight-forward.
>>
>> - Sascha
>>
>> --
>> PHP Development Mailing List 
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
>>
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] [PATCH] Redirect on Error

[Jani Taskinen]

On Tue, 26 Nov 2002, Alexander Wagner wrote:

>But PHP is very popular among people who are _not_ serious. Some become 
>serious. After the got in touch with programming. After they got their first 
>site to work. Removing obstacles is mostly a good thing.
>PHP is very easy to use already. This is just one point where it still can 
>improve.


I'd rather see it getting more "hard" to easy for these newbies..
They tend to do very stupid mistakes and leave all kinds of holes
in it and thus makes PHP look bad for any serious people..

--Jani



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

Re: [PHP-DEV] Oracle < 8.1.7

[Jani Taskinen]

Can't you just check if it exists and add some #ifdef's in the code?

--Jani


On Mon, 25 Nov 2002, Maxim Maletsky wrote:

>
>Guys,
>
>I'm hassling on a quite mysterious and not documented (but pretty useful)
>function for OCI8 called OCIServerRelease() which would return you the
>Oracle Server release integer for compatibility comparisons.
>
>Because there are no official docs anywhere about this function (WTF? google
>only returns 2 pages both of which is Ruby's OCI8 module docs), I was
>unable to track it's BC, although tests for me worked just fine.
>
>So, what I am trying to do instead is to test this OCI call on lower Oracle
>versions. So far it worked smoothly for me on three Oracle machines I
>currently have access to:
>
>* Oracle9i Release 9.0.2.0.1
>* Oracle9i Release 9.0.1.1.1
>* Oracle8i Enterprise Edition Release 8.1.7.3.0
>
>Both with Client 9.
>
>Does anyone have an access to any lower versions of Oracle Servers and
>Oracle Clients to compile and test from CVS? Especially Client. If so,
>please let me know.
>
>Cheers,
>
>--
>Maxim Maletsky
>[EMAIL PROTECTED]
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] [PATCH] Redirect on Error

[Jani Taskinen]

On Tue, 26 Nov 2002, Alexander Wagner wrote:

>On Monday 25 November 2002 23:49, Jani Taskinen wrote:
>> >If you want these people to find this translation, you'd have to put the
>> > url into every error-message.
>> >And provide a way to change the root-url, so it can be downloaded
>>
>> I thought we already have these both..?
>
>By default? Does it lead to a translation of the error-message, or some other 
>description of what the error-message means?

Not for everything.

>Remember. I'm talking about the people that have to be spoon-fed.

Well..to be quite honest: I don't care about such people. 
They're not working with PHP, they just use it for fun.
Every _serious_ developer definately knows enough english..

>Anyway, I'm just dreaming. All those newbies who ask questions like "what does 
>this error mean" or "My code doesn't work. Why?" might be able to answer some 
>of these questions themselves.

Tell them to buy a dictionary..there are good ones in the web too.. :-p

--Jani



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

Re: [PHP-DEV] [PATCH] Redirect on Error

[Jani Taskinen]

On Mon, 25 Nov 2002, Alexander Wagner wrote:

>If you want these people to find this translation, you'd have to put the url 
>into every error-message.
>And provide a way to change the root-url, so it can be downloaded

I thought we already have these both..?

--Jani


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

RE: [PHP-DEV] [PATCH] Redirect on Error

[Jani Taskinen]

On Mon, 25 Nov 2002, John Coggeshall wrote:

>
>>Multi-lingual error codes open's up pandora's box, let's not go 
>>there.
>
>I have to disagree with you here Sterling. Worrying about support for
>non-english errors in php-general, etc is a bad, bad excuse not to
>implement them. The benefits of a completely constant-based error system
>(with human-friendly errors just because we like them) is worth
>consideration and I really feel is a positive addition to PHP. The only
>pandora's box your worried about (at least from the sound of your
>e-mail) was your inbox size ;) Or am I missing something?


Just forget this. I'm not native english speaker, but I REALLY
don't want to see any errors in any other language but english.
(does Perl/Python/etc have multi-lingual errors btw?)

--Jani


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

Re: [PHP-DEV] Fix for bug 19207 (change of cgi behaviour in PHP4.3.0)

[Jani Taskinen]

On Fri, 22 Nov 2002, Edin Kadribasic wrote:

>On Friday 22 November 2002 04:18, Jani Taskinen wrote:
>> I can't remember that discussion..but why do we need
>> yet another ini option? If the current behaviour is incorrect,
>> and you can fix it..why do you even ask here? :)
>
>FYI:
>http://www.phpbuilder.com/mail/php-developer-list/2002092/0238.php
>http://bugs.php.net/bug.php?id=19207
>
>Edin
>
>P.S. I don't like adding ini setting either, but I see no other way of solving 
>the issue.


Ah, I see..well, as long as the current behaviour stays as
the default one, feel free to commit your changes. :)

--Jani



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

Re: [PHP-DEV] Fix for bug 19207 (change of cgi behaviour in PHP4.3.0)

[Jani Taskinen]

On Fri, 22 Nov 2002, Edin Kadribasic wrote:

>Attached is a patch that fixes bug #19207 in accordance with previous 
>discussion on php-dev. It add cgi.rfc2616_headers ini option which is by 
>default set to off and mimics current 4.3.0 behaviour. If its set to on the 
>HTTP status line is sent in accordance to RFC2616 which was default  for PHP 
>4.2.3 and earlier.
>
>Any objections to commiting this fix?

I can't remember that discussion..but why do we need 
yet another ini option? If the current behaviour is incorrect,
and you can fix it..why do you even ask here? :)

--Jani



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

Re: [PHP-DEV] [PATCH] Redirect on Error

[Jani Taskinen]

   What is so hard to understand in word 'FATAL'? 
   If your script doesn't work, what use is it to make it
   show the cryptic 500 error??
   
   I'm -10 for adding anything like this, even if and
   even more then if it's optional.

   Just forget this.
   
   
   --Jani
   

On Thu, 21 Nov 2002, John Coggeshall wrote:

>
>Okay...
>
>Well, even though I've yet to convince Derick and a few others... I did
>see enough interest in this to create a patch. This creates two new
>directives: error_redirect (bool) which turns this on/off, and
>error_redirect_url (string) which is the URL to redirect to upon error.
>In order for these directives to have any effect, the headers (of
>course) must not have been already sent. This means that either output
>buffering must be enabled, or the script never got around to outputting
>anything. This patch will allow users to handle every error PHP
>generates if desired (including E_PARSE, etc).
>
>The URL which is redirected to is passed the following parameters via a
>GET statement:
>
>errno - The error number (i.e. E_PARSE, whatever)
>Errfile - The path/file of the effected file
>Errline - The line which the error occurred
>Errmsg - The message provided describing the error:
>
>If the redirection fails (i.e. because headers had already been sent,
>whatever) the standard PHP error routine is used. 
>
>Disclaimer: This is totally meant to be RFC at this point. It works, but
>Its not very friendly right now with the other error stuff (i.e.
>error_prepend, etc). If I can get a +1 on this concept, I'll clean
>things up before I commit.
>
>John
>
>--- php4/main/main.org.cThu Nov 21 05:43:05 2002
>+++ php4/main/main.cThu Nov 21 05:43:18 2002
>@@ -236,6 +236,8 @@
>STD_PHP_INI_ENTRY("docref_root", "http://www.php.net/";,
>PHP_INI_ALL,   OnUpdateString,  docref_root,
>php_core_globals,   core_globals)
>STD_PHP_INI_ENTRY("docref_ext", "",
>PHP_INI_ALL, OnUpdateString, docref_ext,
>php_core_globals,core_globals)
>STD_PHP_INI_BOOLEAN("html_errors",  "1",
>PHP_INI_ALL, OnUpdateBool,   html_errors,
>php_core_globals,core_globals)
>+   STD_PHP_INI_BOOLEAN("error_redirect",   "0",
>PHP_INI_SYSTEM, OnUpdateBool,   error_redirect,
>php_core_globals,   core_globals)
>
>+STD_PHP_INI_ENTRY("error_redirect_url", NULL,
>PHP_INI_SYSTEM, OnUpdateString,
>error_redirect_url, php_core_globals,core_globals)
>STD_PHP_INI_BOOLEAN("xmlrpc_errors","0",
>PHP_INI_SYSTEM, OnUpdateBool,   xmlrpc_errors,
>php_core_globals,core_globals)
>STD_PHP_INI_ENTRY("xmlrpc_error_number","0",
>PHP_INI_ALL,OnUpdateInt,
>xmlrpc_error_number,php_core_globals,   core_globals)
>STD_PHP_INI_ENTRY("max_input_time", "-1",
>PHP_INI_SYSTEM|PHP_INI_PERDIR,  OnUpdateInt,
>max_input_time,php_core_globals,core_globals)
>@@ -605,7 +607,40 @@
>if (prepend_string) {
>PUTS(prepend_string);
>}
>-   php_printf(error_format, error_type_str, buffer,
>error_filename, error_lineno);
>+   if(PG(error_redirect) && !SG(headers_sent)) {
>+
>+sapi_header_line ctr = {0};
>+char *url_params;
>+
>+int out_url_len, t_header_len;
>+
>+url_params = do_alloca(ERRORURL_BUF_LEN);
>+
>+snprintf(url_params,
>+ERRORURL_BUF_LEN-1,
>+
>"?errno=%d&errfile=%s&errline=%d&errmsg=%s",
>+type,
>+php_url_encode((char
>*)error_filename, strlen(error_filename), NULL),
>+error_lineno,
>+php_url_encode(buffer,
>strlen(buffer), NULL));
>+
>+/* The +10 is to account for "Location:  "
>*/
>+t_header_len =
>strlen(PG(error_redirect_url)) + strlen(url_params) + 10;
>+ctr.line = do_alloca(t_header_len);
>+snprintf(ctr.line,
>t_header_len+9,"Location:  %s%s", PG(error_redirect_url), url_params);
>+
>+ctr.line_len = strlen(ctr.line);
>+
>+sapi_header_op(SAPI_HEADER_REPLACE, &ctr
>TSRMLS_CC);
>+
>+free_alloca(url_params);
>+free_alloca(ctr.line);
>+
>+   } else {
>+
>+php_printf(error_format, error_type_str,
>buffer, error_filename, error_lineno);
>+   }
>+
>

Re: [PHP-DEV] apache_hooks

[Jani Taskinen]

On Tue, 19 Nov 2002, Stanislav Malyshev wrote:

>What is apache_hooks SAPI module? It looks like it produces errors in 
>my build... And no docs there. What's that?

I think those errors should be fixed now. The config.m4 was just borked. 

--Jani



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

Re: [PHP-DEV] Re: #20461 [Opn->Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW

[Jani Taskinen]

On Mon, 18 Nov 2002, Edin Kadribasic wrote:

>On Sun, 17 Nov 2002, Rasmus Lerdorf wrote:
>
>> > > But why do you assume that the documentation was right and the code was
>> > > wrong and not the other way around?
>> >
>> > Because it was working like documented before. (When the documentation
>> > was written). Anyway, not sure what to do with this one...
>> 
>> I don't have the energy to do a cvs check, but I remember adding this
>> restriction years ago (php2 days) and then removing it (by commenting out
>> the check) ages ago as well. I'm not sure PHP4 ever had this check turned
>> on (the commented out check was ported to php4), so the documentation has
>> not reflected reality in a very long time.
>
>I agree that this change is going to break a lot of code. Some of it is my 
>own :)
>
>I suggest that we always populate $PHP_AUTH_USER since that one has no 
>security consequences and the information is awailable elsewhere 
>($_SERVER['REMOTE_USER']). $PHP_AUTH_PW should be set when there are no 
>safe_mode/open_basedir restrctions in effects.
>
>Would this solution be satisfactory to everyone?

No, it would break my scripts. :-p

Use the $_SERVER['REMOTE_USER'] as it's been documented
for ages in the http auth docs..

--Jani



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

Re: [PHP-DEV] [PATH] update to earlier proposed patch for getanyrr()function addition

[Jani Taskinen]

Wouldn't it make sense to move this to it's own 
extension? It would make it easier to maintain and
keep the configure scripts readable.. :)

--Jani


On Sun, 17 Nov 2002, Marcus Börger wrote:

>Function is nice but the function name is not.
>Attached is a second revised patch that fixes the build problems.
>
>marcus
>
>At 00:11 17.11.2002, Pollita wrote:
>>Per corrections suggested by [EMAIL PROTECTED], attached is a revised pacth to
>>ext/standard/dns.c for addition of getanyrr() function.
>>
>>
>>--
>>PHP Development Mailing List 
>>To unsubscribe, visit: http://www.php.net/unsub.php
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] GD 2.0.6 make errors

[Jani Taskinen]

This was actually fixed long time ago in CVS..

--Jani


On Thu, 14 Nov 2002, Marcus Börger wrote:

>No! Exactly the correct list because he told us that current version do not
>build with newest GD version. And the GD maintainers have to do something
>about that :-)
>
>marcus
>
>At 17:55 14.11.2002, Adam Voigt wrote:
>>Wrong list, try php-general or php-install, php-dev is for
>>discussion about the development of PHP not development in PHP.
>>
>>On Thu, 2002-11-14 at 11:51, Clay wrote:
>> > Gcc 3.2
>> > Solaris 9
>> >
>> > 2.0.1 works fine.  Any ideas?  Anyone compile 2.0.6 yet on any platform?
>> >
>> > In file included from gd.c:83:
>> > gd_ctx.c: In function `_php_image_output_ctx':
>> > gd_ctx.c:70: structure has no member named `free'
>> > gd_ctx.c:98: structure has no member named `free'
>> > gd.c: In function `_php_image_type':
>> > gd.c:1014: structure has no member named `free'
>> > gd.c:1017: structure has no member named `free'
>> > gd.c: In function `_php_image_create_from':
>> > gd.c:1209: structure has no member named `free'
>> > make[3]: *** [gd.lo] Error 1
>> > make[2]: *** [all-recursive] Error 1
>> > make[1]: *** [all-recursive] Error 1
>> > make: *** [all-recursive] Error 1
>> >
>> > Any ideas
>> >
>> >
>> >
>> > --
>> > PHP Development Mailing List 
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>>--
>>Adam Voigt ([EMAIL PROTECTED])
>>The Cryptocomm Group
>>My GPG Key: http://64.238.252.49:8080/adam_at_cryptocomm.asc
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Re: php4 / configure.in /main php_version.h

[Jani Taskinen]

On Wed, 13 Nov 2002, Peter Neuman wrote:

>Hello,
>
>"Andrei Zmievski" <[EMAIL PROTECTED]>:
>> andrei Wed Nov 13 14:19:07 2002 EDT
>>
>>   Modified files:
>> /php4 configure.in
>> /php4/main php_version.h
>>   Log:
>>   Change version to 4.4.0-dev.
>
>hm? not 5.0.0-dev? it's time for this...

It's not time.

--Jani



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

Re: [PHP-DEV] mbstring and 4.3.0

[Jani Taskinen]

   
   Oh, I forgot: How many bug reports have we got so
   far for that fuckup with 4.2.3 ??? I _REALLY_ don't want
   to see another wave of those for 4.3.0..
   
   --Jani
   


On Wed, 13 Nov 2002, Marcus Börger wrote:

>At 23:56 12.11.2002, Ilia A. wrote:
>>Since I've gotten involved in this conversation would like to add my opinion
>>to the tally. I too believe that at least at this point, the mbstring
>>extension should not be enabled by default.
>>There are two reasons for this decision:
>>
>>1) Majority of PHP users do not require this functionality. Most PHP programs
>>are developed with non-multibyte languages in mind and mbstring only adds
>>unnecessary overhead. People who need it can easily enable it or ask their
>>ISPs to enable it, if they had done so already.
>
>NO. Most people do not have the choice and ISPs usually take the default.
>If the default is not approriate they do not use it.
>If you read the whole thread you find enough reasons how apps benefit from
>mbstring and what could be easily achieved with languages like german.
>
>
>>2) mbstring extension is a fairly complex piece of code and iirc is the
>>youngest extension of this magnitude that is enabled by default. Although the
>>extension developers are very prompt at fixing bugs, the fact they need to do
>>this fairly frequently, at least to me, implies that the extension is not yet
>>mature enough to be enabled by default. Also, judging by the number of
>>changes in the CVS to the extension, a lot of new functionality was added to
>>the extension recently and has not been tested outside the pre process. Maybe
>>by next PHP release is made, it will be better tested and more stable.
>>
>>Ilia
>
>Ok there are some problems and that is the backside of it: Some of us
>implement new functionality and some merge code from the original development
>tree. In other words: Maybe we should slow down or even stop feature 
>development
>until 4.3 is out After php 4.3 we hope the new implementation can be used.
>
>As long as function overloading isn't used there is no harm from mbstring 
>(disable
>is the default). And some extra bytes shouldn't affect anybody today. If 
>you say
>most apps are not designed to use mbstring then it's nice that all those 
>could try
>mbstring which would like to. So we can get feedback. As long as it isn't 
>default
>there will be none or only little feedback.
>
>The stability is very high and we have many *.phpt tests to help us find 
>failures
>and make it even more stable.
>
>marcus
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] mbstring and 4.3.0

[Jani Taskinen]

Since when have we started to use users as guinea-pigs
for testing EXPERIMENTAL extensions without them even
really knowing about it?!!

You can't FORCE anybody to use it. 99% of apps out there
DO NO NEED IT..get it?? (they've managed without it very long time..)

--Jani



On Wed, 13 Nov 2002, Marcus Börger wrote:

>At 23:56 12.11.2002, Ilia A. wrote:
>>Since I've gotten involved in this conversation would like to add my opinion
>>to the tally. I too believe that at least at this point, the mbstring
>>extension should not be enabled by default.
>>There are two reasons for this decision:
>>
>>1) Majority of PHP users do not require this functionality. Most PHP programs
>>are developed with non-multibyte languages in mind and mbstring only adds
>>unnecessary overhead. People who need it can easily enable it or ask their
>>ISPs to enable it, if they had done so already.
>
>NO. Most people do not have the choice and ISPs usually take the default.
>If the default is not approriate they do not use it.
>If you read the whole thread you find enough reasons how apps benefit from
>mbstring and what could be easily achieved with languages like german.
>
>
>>2) mbstring extension is a fairly complex piece of code and iirc is the
>>youngest extension of this magnitude that is enabled by default. Although the
>>extension developers are very prompt at fixing bugs, the fact they need to do
>>this fairly frequently, at least to me, implies that the extension is not yet
>>mature enough to be enabled by default. Also, judging by the number of
>>changes in the CVS to the extension, a lot of new functionality was added to
>>the extension recently and has not been tested outside the pre process. Maybe
>>by next PHP release is made, it will be better tested and more stable.
>>
>>Ilia
>
>Ok there are some problems and that is the backside of it: Some of us
>implement new functionality and some merge code from the original development
>tree. In other words: Maybe we should slow down or even stop feature 
>development
>until 4.3 is out After php 4.3 we hope the new implementation can be used.
>
>As long as function overloading isn't used there is no harm from mbstring 
>(disable
>is the default). And some extra bytes shouldn't affect anybody today. If 
>you say
>most apps are not designed to use mbstring then it's nice that all those 
>could try
>mbstring which would like to. So we can get feedback. As long as it isn't 
>default
>there will be none or only little feedback.
>
>The stability is very high and we have many *.phpt tests to help us find 
>failures
>and make it even more stable.
>
>marcus
>
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/snmp CREDITS php_snmp.hsnmp.c

[Jani Taskinen]

Maybe it would be good idea to do something like
LDAP extension does? ie. have something similar to ldap_set_option()
to set the protocol version to be used? And have same
functions and thus not pollute the function namespace anymore?

iirc, the snmp command line tools have an option to select
which protocol version to use?

--Jani


On Tue, 12 Nov 2002, Harrie Hazewinkel wrote:

>
>
>--On Tuesday, November 12, 2002 10:42 PM +0100 Derick Rethans 
><[EMAIL PROTECTED]> wrote:
>
>> On Tue, 12 Nov 2002, Harrie Hazewinkel wrote:
>>
>>> >> These function names don't follow the PHP standards, I think we should
>>> >> definitely come up with better names.
>>> >
>>> > I agree. what's wrong with snmp_get, snmp_walk, and so on?
>>>
>>> I believe it is neccessary to have the 'v3' in the name. It makes very
>>> clear to people that it is for snmpv3 and not any opther snmp version.
>>>
>>> SNMPv3 is the protocol version that has security support and is known
>>> as under SNMPv3 by many people.
>>
>> But what use does it have in it's name? We don't have PGsqlV6 and
>> pgsqlv7_, or mysqlv3_ and mysqlv4_ (or take the gd functions).
>
>Again I believe there is a difference between a package version number
>and this protocol. I do not believe that snmp_get is an improvement over
>snmpv3get for instance.
>
>Although, I admit I have been thinking of using the used example snmp_get,
>but then I need to add a version number as parameter. This would allow
>as well the existing snmpget (for SNMPv1) to be combined with snmpv3get
>(for SNMPv3). However, I have kept it simple for the moment and attempted
>to make it as easy as possible to upgrade scripts to SNMPv3.
>And on top of it, also providing a quick and well understood recognition
>of it.
>
>Also SNMPv3 is a full standard and that version number is not likely
>(and hopefully) about to change.
>
>>
>>>
>>> Anyway, where would be the function name guide lines on the website.
>>> I cannot find it and a pointer would be appreciated.
>>
>> See the CODING_STANDARDS file in the root of the php4/ CVS module.
>
>THanks, I will check it out.
>
>>
>> Derick
>>
>> --
>>
>> -
>> --  Derick Rethans
>> http://derickrethans.nl/   JDI Media Solutions
>> --[ if you hold a unix shell to your ear, do you hear the c?
>> ]-
>>
>>
>
>
>
>Harrie
>
>Internet Management Consulting
>mailto: [EMAIL PROTECTED]   http://www.lisanza.net/
>
>Author of MOD-SNMP, enabling SNMP management the Apache HTTP server
>
>

-- 
<- For Sale! ->


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

Re: [PHP-DEV] mbstring and 4.3.0

[Jani Taskinen]

On Tue, 12 Nov 2002, Ilia A. wrote:

>Since I've gotten involved in this conversation would like to add my opinion 
>to the tally. I too believe that at least at this point, the mbstring 
>extension should not be enabled by default.
>There are two reasons for this decision:
>
>1) Majority of PHP users do not require this functionality. Most PHP programs 
>are developed with non-multibyte languages in mind and mbstring only adds 
>unnecessary overhead. People who need it can easily enable it or ask their 
>ISPs to enable it, if they had done so already.
>
>2) mbstring extension is a fairly complex piece of code and iirc is the 
>youngest extension of this magnitude that is enabled by default. Although the 
>extension developers are very prompt at fixing bugs, the fact they need to do 
>this fairly frequently, at least to me, implies that the extension is not yet 
>mature enough to be enabled by default. Also, judging by the number of 
>changes in the CVS to the extension, a lot of new functionality was added to 
>the extension recently and has not been tested outside the pre process. Maybe 
>by next PHP release is made, it will be better tested and more stable.


I must (still) agree. +1 for making it disabled for now..
(people who need it, already know to use --enable-mbstring with 4.2.3)


--Jani



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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/curl config.m4

[Jani Taskinen]

On Sat, 9 Nov 2002, Sterling Hughes wrote:

>> On Sat, 9 Nov 2002, Sterling Hughes wrote:
>> 
>> >> 
>> >> There is no such release of Curl yet. This makes testing
>> >> the RCs quite a hassle now so either you revert those changes
>> >> or get the curl folks to release this 7.10.2. 
>> >> 
>> >> --Jani
>> >>
>> >
>> >7.10.2-pre4 is currently out, it should be released quite soon.
>> 
>> But it's not 7.10.2 release. Revert the changes.
>> Or I will.
>>
>
>err... no.
>
>7.10.2 will be out long before PHP 4.3.  We haven't even had the first
>RC for PHP, and its a lot longer before PHP releases to come out.  If
>you want to test it for QA purposes, you can easily install one of the
>prereleases.  7.10.1 might also work, not sure

 You're now missing the point here. I'm NOT doing QA for Curl.
 I'm not going to install ANY curl pre-release here.
 
 You can (if you wouldn't be so lazy) add some ifdef's around
 the new stuff instead of everytime requiring people to update curl!!
 
 
 --Jani
 


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

Re: [PHP-DEV] ext/sybase_ct commit?

[Jani Taskinen]

On 8 Nov 2002, Timm Friebe wrote:

>On Thu, 2002-11-07 at 14:46, Andrei Zmievski wrote:
>> On Sat, 02 Nov 2002, Timm Friebe wrote:
>> > Round 2 - fight:-)
>> > 
>> > OK, I guess now I'm ready for committing my changes. I got PHP compiled
>> > and tested out the new functionality of my ext/sybase_ct changes against
>> > CVS from today.
>> > 
>> > Just to make sure I'm getting it all right: This is what I'd put in the
>> > commit message
>[...]
>> Can you compress this down to a couple of entries?
>
>Sorry, I committed it before you wrote your e-mail. I don't quite
>understand why this should be shorter, though. This sort of was a
>mega-patch... or is it generally better so write stuff like 

Andrei meant the NEWS entry I guess..which is just fine.
You just didn't add it. :)

>  Added new functions: sybase_unbuffered_query(), sybase_fetch_assoc(),
>  sybase_set_message_handler(), see docs (Timm)
>
>I personally think I'd rather like to see a somewhat verbose Changelog.
>If this isn't what is wanted, I'll try and keep it shorter for future
>commits.

Again, entries that go to ChangeLog only can be as long as you want
them to be. NEWS entries are different issue. But the one 
you had there is fine. splitting that to seperate entries would
be very hard to find/read.

--Jani



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

Re: [PHP-DEV] mbstring and 4.3.0

[Jani Taskinen]

On Thu, 7 Nov 2002, Derick Rethans wrote:

>On Thu, 7 Nov 2002, Marcus Boerger wrote:
>
>> To make php be easier usable in non US-ASCII (127chars) environments
>> especially those requiring UCS-2, UTF-8 or other any character mapping
>> other than iso-8859-1 or -15 we should more likly try to integrate mbstring
>> fully in php. As long as we cannot or want not make it a core component
>> such as ext/standard we should enable it by default.
>
>If people want it they can use --enable-mbstring. I see no reason why it 
>should be enabled by default as long as it's not fully integrated in the 
>core.

Zeev could give some figures about how many PHP users there are in those 
countries that really need this? :)

Anyway, I'm +1 for making it disabled by default.
The people who really need it already need to use --enable-mbstring
since that's how it was in 4.2.3 anyway.

--Jani



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

Re: [PHP-DEV] shtool update to 1.6.2?

[Jani Taskinen]

On Wed, 6 Nov 2002, Marcus Boerger wrote:

>Will we update shtool from 1.5.4 (our current version) to 1.6.2 (actual 
>version)?

I don't see any problems with that. But do add that 'path'
option/module/whatever into it when you create it.

--Jani



>I just tried it and it seems to work. But i would like to here other 
>meanings before
>commiting.
>
>marcus
>
>  ChangeLog
>  Changes between 1.6.1 and 1.6.2 (12-Jul-2002 to 02-Nov-2002):
>*) Map "shtool install -d  [...]" internally to "shtool mkdir
>
>   -f -p -m 755  [...]" in order to support the BSD-style
>   "install -d" variant.
>   [Ralf S. Engelschall, Alan Eldridge <[EMAIL PROTECTED]>]
>*) Add -o|--owner and -g|--group options to "shtool mkdir".
>   [Ralf S. Engelschall]
>*) Fixed 'shtool scpp -f ...'. The arguments to option -f
>   were not evaluated correctly.
>   [Ralf S. Engelschall]
>*) Support bold font on 'cygwin' terminals.
>   [Marcus Boerger <[EMAIL PROTECTED]>]
>*) Try the terminal 'init' sequence before 'reset' for bold mode
>   restoring in order to make sure the terminal is not cleared.
>   Additionally, fallback to a consistent no-bold mode.
>   [Mirko Liss <[EMAIL PROTECTED]>]
>  Changes between 1.6.0 and 1.6.1 (01-Feb-2002 to 12-Jul-2002):
>*) Removed not-existing --min-size option from the usage
>   of "shtool rotate". The name is just --size.
>   [Thomas Linden <[EMAIL PROTECTED]>]
>*) Port to POSIX 1003.1-2001 (SUSv3) standard:
>   sh.echo, sh.version: "head -1" -> "sed -e 'q'"
>   sh.path: "sort -u | tail -1" -> "sort -r -u | sed -e q"
>   sh.subst: diff -u1 -> diff -U1
>   [Paul Eggert <[EMAIL PROTECTED]>]
>*) Fixed various typos in shtool.pod.
>   [Ralf S. Engelschall, Liones <[EMAIL PROTECTED]>]
>  Changes between 1.5.4 and 1.6.0 (14-Jun-2001 to 01-Feb-2002):
>*) Upgraded to GNU Autoconf 2.52 environment.
>   [Ralf S. Engelschall]
>*) Fixed contained RPM specification (shtool.spec)
>   [Ralf S. Engelschall]
>*) Added new command `shtool rotate [-v|--verbose] [-t|--trace]
>   [-f|--force] [-n|--num-files ] [-s|--min-size ]
>   [-c|--copy] [-r|--remove] [-a|--archive-dir ] [-z|--compress
>   [:]] [-b|--background] [-d|--delay] [-p|--pad ]
>   [-o|--owner ] [-g|--group ] [-m|--mode ]
>   [-M|--migrate ] [-P|--prolog ] [-E|--epilog ]
>   [ ...]'. This is a sophisticated command for rotating
>   logfiles of daemons.
>   [Ralf S. Engelschall]
>*) Added GNU long-option support (`--').
>   [Ralf S. Engelschall]
>*) Cleaned up temporary file handling in `shtool path'.
>   [Ralf S. Engelschall]
>*) Added NEWS file to source tree to comply to GNU standards.
>   [Ralf S. Engelschall]
>*) Add new `shtool subst [-v] [-t] [-n] [-s] [-i] [-b]
>   [-e] [-f] [] [...]' command. This
>   is a useful wrapper around sed(1).
>   [Ralf S. Engelschall]
>
>
>Diff:
>
>cvs -z3 -q diff shtool (in directory S:\php4-HEAD\build\)
>Index: shtool
>===
>RCS file: /repository/php4/build/shtool,v
>retrieving revision 1.3
>diff -u -r1.3 shtool
>--- shtool  7 Mar 2002 14:17:56 -   1.3
>+++ shtool  6 Nov 2002 13:57:36 -
>@@ -1,13 +1,13 @@
>  #!/bin/sh
>  ##
>  ##  GNU shtool -- The GNU Portable Shell Tool
>-##  Copyright (c) 1994-2001 Ralf S. Engelschall <[EMAIL PROTECTED]>
>+##  Copyright (c) 1994-2002 Ralf S. Engelschall <[EMAIL PROTECTED]>
>  ##
>  ##  See http://www.gnu.org/software/shtool/ for more information.
>  ##  See ftp://ftp.gnu.org/gnu/shtool/ for latest version.
>  ##
>-##  Version:  1.5.4 (14-Jun-2001)
>-##  Contents: 3/17 available modules
>+##  Version:  1.6.2 (02-Nov-2002)
>+##  Contents: 3/19 available modules
>  ##
>
>  ##
>@@ -50,7 +50,9 @@
>  ##mkln   Make link with calculation of relative paths
>  ##mkshadow   Make a shadow tree through symbolic links
>  ##fixpermFix file permissions inside a source tree
>+##rotate Logfile rotation
>  ##tarballRoll distribution tarballs
>+##subst  Apply sed(1) substitution operations
>  ##guessosSimple operating system guesser
>  ##arxExtended archive command
>  ##sloSeparate linker options by library class
>@@ -65,8 +67,8 @@
>  exit 1
>  fi
>  if [ ".$1" = ".-h" -o ".$1" = ".--help" ]; then
>-echo "This is GNU shtool, version 1.5.4 (14-Jun-2001)"
>-echo "Copyright (c) 1994-2001 Ralf S. Engelschall <[EMAIL PROTECTED]>"
>+echo "This is GNU shtool, version 1.6.2 (02-Nov-2002)"
>+echo "Copyright (c) 1994-2002 Ralf S. Engelschall <[EMAIL PROTECTED]>"
>  echo "Report bugs to <[EMAIL PROTECTED]>"
>  echo ''
>  echo "Usage: shtool [] [ [] 
>[]]"
>@@ -78,38 +80,63 @@
>  echo '  -r, --recreate  recreate this shtool script via shtoolize'
>  echo ''
>  echo 'Available  [] []:'
>-echo '  echo [-n] [-e

Re: [PHP-DEV] ZE2 & configure

[Jani Taskinen]

Some people don't bother doing MFZE1...

--Jani


On Fri, 1 Nov 2002, Marcus Boerger wrote:

>The build system complains that LIBZEND_DLSYM_CHECK
>is not available. Should this be provided in Zend/Zend.m4?
>
>marcus
>
>cvs -z3 -q diff Zend\Zend.m4 (in directory S:\php4-HEAD\)
>Index: Zend/Zend.m4
>===
>RCS file: /repository/ZendEngine2/Zend.m4,v
>retrieving revision 1.35
>diff -u -r1.35 Zend.m4
>--- Zend/Zend.m423 Aug 2002 22:11:10 -  1.35
>+++ Zend/Zend.m41 Nov 2002 20:17:36 -
>@@ -230,3 +230,6 @@
>
>  ])
>
>+AC_DEFUN(LIBZEND_DLSYM_CHECK,[
>+
>+])
>
>

-- 
<- For Sale! ->


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