Re: [PHP-DEV] mbstring

[derick]

On Mon, 2 Sep 2002, Marcus Börger wrote:

> AND exif is disliked by the developers on this list so why do we care now?

Markus, that makes no sense. Just because some ppl don't want it exif 
enabled by default doesn't make us 'dislike' exif, it doesn't make us 
(atleast not me) like you less.

Derick

---
 Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
 Frequent ranting: http://www.derickrethans.nl/
---
 PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

RE: [PHP-DEV] mbstring

[James Cox]

Derick pretty much said it for me... but more explicitly,

mbstring isn't stable enough to be default.

-- james

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 02, 2002 6:41 AM
> To: Masaki Fujimoto
> Cc: James Cox; Wez Furlong; Php-Dev
> Subject: Re: [PHP-DEV] mbstring
>
>
> On Mon, 2 Sep 2002, Masaki Fujimoto wrote:
>
> > Hi,
> >
> > let me vote not to remove mbstring (as a default one).
>
> I'd vote for setting it off by default _for now_, and enable it after
> 4.3. has branched, so we have a kick ass i18n solution in PHP5 replacing
> all code it duplicates.
>
> > yes, I can understand the thought that singlebyte users seem mbstirng
> > module is somehow 'extra' one.
> >
> > but please understand that this module is indispensable for multibyte
> > users (at least), and AFAIK there are growing numbers of multibyte users
> > of PHP. we japanese, korean and chinese have to handle 3 (or more) types
> > of encoding (+ UNICODE), and we cannot even count number characters (not
> > bytes) w/out mbstring.
> >
> > besides, I (we?) always make best effort that multibyte features do not
> > harm any other ones, and if it causes bugs, we (Yasuo, Rui or I) will
> > fix it ASAP (maybe:).
>
> Too bad that you can't predict anything.
>
> >
> > of course we can --enable-mbstring even if msbstirg is disabled by
> > default, but please remember that not all the users can always exec
> > 'configure' and edit php.ini. (use dl() ? hmm...)
>
> Every respectable sysadm in eastern countries installing PHP should be
> aware fo this and enable mbstring for his users.
>
> >
> > finally, it is true that mbstring is not the 'golden bullet':), but it
> > would be far better if we have some kind of bullets, isn't it ?
>
> Derick
>
> --
> -
>  Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
>  Frequent ranting: http://www.derickrethans.nl/
> --
> -
>  PHP: Scripting the Web - [EMAIL PROTECTED]
> All your branches are belong to me!
> SRM: Script Running Machine - www.vl-srm.net
> --
> -
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


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

RE: [PHP-DEV] mbstring

[James Cox]

> > So I want to 'disable' it by default. If you want encoding,
> just enable it. But you're right, i've never needed to create a
> truely globalized/localized app. (and from general principles, if
> you feel you need to localize any more than your ui/strings.)
> >
>
> That's not what I read, perhaps you can just double clarify this -- you
> do not at all want to remove mbstring from PHP (and move it say, to
> pear)...
>
> If this is correct, than I'm +1, otherwise I'm -1.  Mbstring is very
> important when it comes to creating i18n applications.  Also, you seem
> to forget that PHP is not only used in England, but other areas where it
> is _quite_ important, and _quite_ necessary.
>

Erm, i'm quite aware of it's global presense.. but you got it right... i
don't care about if it exists as an extension -- actually, yes i do, it
should be a big bonus for us once it's stable -- i just don't think it
should be enabled by default. This seems to cause end-users (and downstream
developers like RedHat) huge issues. Let's not enable it by default now, and
when it's more stable, (say, PHP5 time) we can re-enable it. Who knows, it
might serve as a good extra carrot. :)

 -- James


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

Re: [PHP-DEV] Re: mbstring

[derick]

On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:

> [EMAIL PROTECTED] wrote:
> > 
> > No, not really. It was noted by more than one person that it breaks 
> > some simple things in PHP, affecting the bahavior of scripts that are 
> > already out there. Until it is totally stable (which you yourself it is 
> > not yet) it should not be enabled by default. How, after 4.3 is branched 
> 
> What problem?

For example the bug with the request variables, which might be fixed in 
CVS now, but it isn't fixed in any release.

> As far as I know, there is no serious problem that is not
> addressed yet. If there is problem, it should be easy one to
> fix. Let me know we'll fix it.
> 
> The main thing has been changed in development version is
> how mbfilter works. New filter is streamable and easier to
> extend, while current one is not. Current behavior will not
> be changed at all.

You mean the thing on sourceforge here as "development version" ?

> In addition, there are few modules depends on mbstring already
> and mbstring does not depend on external lib at all. There
> is no reason to wait.

AFAIK only exif does, and as that one is not enabled by default it 
should be no problem. It's easy to check in the config.m4 file of exif 
if mbstring is enabled too.

> 
> BTW, Derick, could you add mbstring category to bug db?
> (AFAIK, there is no category for it)

It's already there, under "Languages/Translation".

Derick

---
 Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
 Frequent ranting: http://www.derickrethans.nl/
---
 PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

Re: [PHP-DEV] mbstring

[derick]

On Mon, 2 Sep 2002, Masaki Fujimoto wrote:

> Hi,
> 
> let me vote not to remove mbstring (as a default one).

I'd vote for setting it off by default _for now_, and enable it after 
4.3. has branched, so we have a kick ass i18n solution in PHP5 replacing 
all code it duplicates.

> yes, I can understand the thought that singlebyte users seem mbstirng
> module is somehow 'extra' one.
> 
> but please understand that this module is indispensable for multibyte
> users (at least), and AFAIK there are growing numbers of multibyte users
> of PHP. we japanese, korean and chinese have to handle 3 (or more) types
> of encoding (+ UNICODE), and we cannot even count number characters (not
> bytes) w/out mbstring.
> 
> besides, I (we?) always make best effort that multibyte features do not
> harm any other ones, and if it causes bugs, we (Yasuo, Rui or I) will
> fix it ASAP (maybe:).

Too bad that you can't predict anything. 

> 
> of course we can --enable-mbstring even if msbstirg is disabled by
> default, but please remember that not all the users can always exec
> 'configure' and edit php.ini. (use dl() ? hmm...)

Every respectable sysadm in eastern countries installing PHP should be 
aware fo this and enable mbstring for his users. 

> 
> finally, it is true that mbstring is not the 'golden bullet':), but it
> would be far better if we have some kind of bullets, isn't it ?

Derick

---
 Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
 Frequent ranting: http://www.derickrethans.nl/
---
 PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

Re: [PHP-DEV] mbstring

[derick]

On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:

> James Cox wrote:
> > 
> > mbstring isn't a "gold" module which should be enabled by default.
> 
> If we should reduce number of modules built by default, 1st
> module should be MySQL. Removing MySQL does not cause any
> technical problems at all.

Yeah, this is the easiest way to piss of users. 

> 
> > 
> > That is, it's still -- as i see it -- just a bit more than experimental. mbstring 
>work is being done on sourceforge! 
> 
> I hope you're not insisting all work must be done in php.net.
> We're also aming make PHP/Zend fully i18n aware and sf.jp is
> convenient for us.
> 
> > 
> > So I want to 'disable' it by default. If you want encoding, just enable it. But 
>you're right, i've never needed to create a truely globalized/localized app. (and 
>from general principles, if you feel you need to localize any more than your 
>ui/strings.)
> > 
> 
> Is --disable-something is too hard to get used to?
> 
> This is not only policy issue, but also a technical issue
> as I mentioned. You're better to provide solution for it,
> if you strongly insist.

It is in this case, mbstring changed behavior of things. I really think 
mbstring should be default _some_ time, but just not right now. And as I 
said before, I'd rather see it _replace_ code then duplicate code. 

Derick

---
 Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
 Frequent ranting: http://www.derickrethans.nl/
---
 PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

Re: [PHP-DEV] mbstring

[derick]

On Sun, 1 Sep 2002, Shane Caraveo wrote:

> Jim Winstead wrote:
> > it's too bad we don't have an implementation of a complete programming
> > language laying around.
> > 
> > jim
> 
> Yeah, sure would be usefull, then we could just get rid of ini, and use 
> the language...

Too much interesting things to do! :)

Derick

---
 Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
 Frequent ranting: http://www.derickrethans.nl/
---
 PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

[PHP-DEV] ZE2: print_r()/var_dump() and private/protected

[Sebastian Bergmann]

  [I post this to php-dev@ since my mail to engine2@ didn't make it.]
  [Is engine2@ down?]

  It'd ease debugging of applications if print_r() and var_dump() would
  show the proper name of private and protected members:

test = 'test';
  }
}

$test = new Test;
print_r($test);
var_dump($test);
?>

  Output:

test Object
(
[] => test
)

object(test)(1) {
  [""]=>
  string(4) "test"
}

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

Re: [PHP-DEV] mbstring

[Shane Caraveo]

Jim Winstead wrote:
> Yasuo Ohgaki <[EMAIL PROTECTED]> wrote:
> 
>>Marcus B?rger wrote:
>>
>>>We already had some discussion on some IF statements in ini
>>>files already. I guess we might call to another mail thread here
>>>and hope we find a volunteer. I will not invent any work here since
>>>that would be totally useless.
>>
>>I think having a IF in php.ini is good idea.
> 
> 
> it's too bad we don't have an implementation of a complete programming
> language laying around.
> 
> jim

Yeah, sure would be usefull, then we could just get rid of ini, and use 
the language...

Shane



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

Re: [PHP-DEV] ISAPI Crash Debugging Notes

[Andi Gutmans]

At 05:11 PM 9/1/2002 -0700, Michael Sisolak wrote:
>Andi,
>
>I download the alpha2 version of the php-4.3.0-dev-zend2 release.
>Unfortunatley out-of-the-box I got an "Invalid access to memory
>location." error returned when I try to view I page.  I was able to
>track it down to something with the browscap processing - something in
>ini_parse() is causing a memory access violation, but I get lost in all
>the lex code trying to figure out exactly what is going on.  I disabled
>my browscap entry and was able to continue with the testing.

That's strange. I know browsecap isn't really supposed to work (I commented 
out lots of code to get Engine 2 to work) but it shouldn't crash. It 
doesn't crash for me. Are you actually calling it? Can you try not loading it?


>It does appear that the issue I'm seeing with the first thread getting
>the GLOBAL_FUNCTION_TABLE as it's own local copy is fixed in Zend2:
>
>[1340] the startup thread is 1996
>[1340] copying the GLOBAL_FUNCTION_TABLE from 20933432
>[1340] in HttpExtensionProc thread 1996, CG(function table) is 21138360
>[1340] copying the GLOBAL_FUNCTION_TABLE from 20933432
>[1340] in HttpExtensionProc thread 532, CG(function table) is 22055840
>[1340] in HttpExtensionProc thread 1996, CG(function table) is 21138360
>
>The initial thread does now get it's own copy of the
>GLOBAL_FUNCTION_TABLE.  Since it will be a while before Zend2 is
>production quality do you think it would be possible to port what makes
>this work in Zend2 back to 4.2.x?  The changes in zend.c seem fairly
>straight forward, but there may be interactions with other changes I'm
>not seeing.

This code is quite complex as you have probably noticed. I moved some stuff 
around there for Engine 2 but it's not very easy to port these changes back 
to Engine 1 especially as I'm not sure I actually fixed any bugs. Bugs 
weren't the reason for me shifting it around. If you can figure out what 
changes in Engine 2 actually make the difference then we can look at them 
but it might mean lots of work for you.

Andi


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

Re: [PHP-DEV] mbstring

[Jim Winstead]

Yasuo Ohgaki <[EMAIL PROTECTED]> wrote:
> Marcus B?rger wrote:
>> We already had some discussion on some IF statements in ini
>> files already. I guess we might call to another mail thread here
>> and hope we find a volunteer. I will not invent any work here since
>> that would be totally useless.
> 
> I think having a IF in php.ini is good idea.

it's too bad we don't have an implementation of a complete programming
language laying around.

jim

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

Re: [PHP-DEV] mbstring

[Masaki Fujimoto]

Hi,

let me vote not to remove mbstring (as a default one).

yes, I can understand the thought that singlebyte users seem mbstirng
module is somehow 'extra' one.

but please understand that this module is indispensable for multibyte
users (at least), and AFAIK there are growing numbers of multibyte users
of PHP. we japanese, korean and chinese have to handle 3 (or more) types
of encoding (+ UNICODE), and we cannot even count number characters (not
bytes) w/out mbstring.

besides, I (we?) always make best effort that multibyte features do not
harm any other ones, and if it causes bugs, we (Yasuo, Rui or I) will
fix it ASAP (maybe:).

of course we can --enable-mbstring even if msbstirg is disabled by
default, but please remember that not all the users can always exec
'configure' and edit php.ini. (use dl() ? hmm...)

finally, it is true that mbstring is not the 'golden bullet':), but it
would be far better if we have some kind of bullets, isn't it ?

Masaki Fujimoto
<[EMAIL PROTECTED]>

On Sun, 1 Sep 2002 21:29:11 +0100
"James Cox" <[EMAIL PROTECTED]> wrote:

> 
> > > I vote to remove mbstring as a default module.
> > 
> > I guess you have never tried to create a truely globalized/localized
> > application then?
> > 
> > I'm -1 on removing it, because PHP needs a consistent charset encoding
> > API that is portable across platforms. iconv and recode are "no good"
> > because their supported charsets vary from system to system and version
> > to version; some libraries actually have broken encoding tables
> > 
> 
> Wez, let me rephrase:
> 
> mbstring isn't a "gold" module which should be enabled by default.
> 
> That is, it's still -- as i see it -- just a bit more than experimental. mbstring 
>work is being done on sourceforge! 
> 
> So I want to 'disable' it by default. If you want encoding, just enable it. But 
>you're right, i've never needed to create a truely globalized/localized app. (and 
>from general principles, if you feel you need to localize any more than your 
>ui/strings.)
> 
>  -- james
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] mbstring

[Yasuo Ohgaki]

Marcus Börger wrote:
> At 01:24 02.09.2002, you wrote:
> 
>> Brian France wrote:
>>
>>> I know there are things the exif needs from mbstring and there is no 
>>> way to have exif link against mbstring or require it.  But couldn't 
>>> exif check to see if mbstring is loaded (or built in) and if not 
>>> print a warning that some of its functionality may not work correctly 
>>> unless mbstring is loaded (or built in)?
>>
>>
>> It's not a good idea.
>>
>> What we need is smart ini parser and module loader that understand
>> module dependecy and proper loading order.
> 
> 
> We already had some discussion on some IF statements in ini
> files already. I guess we might call to another mail thread here
> and hope we find a volunteer. I will not invent any work here since
> that would be totally useless.
> 

I think having a IF in php.ini is good idea.

--
Yasuo Ohgaki


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

Re: [PHP-DEV] mbstring

[Yasuo Ohgaki]

James Cox wrote:
> 
> mbstring isn't a "gold" module which should be enabled by default.

If we should reduce number of modules built by default, 1st
module should be MySQL. Removing MySQL does not cause any
technical problems at all.

> 
> That is, it's still -- as i see it -- just a bit more than experimental. mbstring 
>work is being done on sourceforge! 

I hope you're not insisting all work must be done in php.net.
We're also aming make PHP/Zend fully i18n aware and sf.jp is
convenient for us.

> 
> So I want to 'disable' it by default. If you want encoding, just enable it. But 
>you're right, i've never needed to create a truely globalized/localized app. (and 
>from general principles, if you feel you need to localize any more than your 
>ui/strings.)
> 

Is --disable-something is too hard to get used to?

This is not only policy issue, but also a technical issue
as I mentioned. You're better to provide solution for it,
if you strongly insist.

If you find problem mbsting, let us know.
Problem should be easy to fix, since the code is
_very_ stable. New streamable filter will not break
any thing, also.

--
Yasuo Ohgaki



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

Re: [PHP-DEV] mbstring

[Yasuo Ohgaki]

Forgot to mention this.
This will not solve module loading order issues.

Not only checks if modules needed in there, but also
we should be able to load module in order.

To achive this, we need to change module loading code
which is written in the engine.

--
Yasuo Ohgaki

Yasuo Ohgaki wrote:
> We should have generic code for this. IMHO.
> 
> -- 
> Yasuo Ohgaki
> 
> Brian France wrote:
> 
>> I know this is ugly, but what about making the extensions handle it 
>> themselves?
>>
>> Your example of session_pgsql:
>>
>> In the extension init code:
>>
>> ext_enabled = 1;
>>
>> if ( dlsym( NULL, "psql_module_entry" ) == NULL &&
>>  dlsym( NULL, "_psql_module_entry" ) == NULL )
>> {
>> // print some warning about needing the pgsql extension
>> // or pgsql should be loaded before this one in the php.ini
>> ext_enabled = 0;
>> }
>>
>> if ( dlsym( NULL, "session_module_entry" ) == NULL &&
>>  dlsym( NULL, "_session_module_entry" ) == NULL )
>> {
>> // print some warning about needing the session extension
>> // or session should be loaded before this one in the php.ini
>> ext_enabled = 0;
>> }
>>
>> The second call with a underscore is to handle Openbsd and old version 
>> of FreeBSD, I think a.out things.  I am sure this can be handled 
>> differently, but you get the point.
>>
>> Cheers,
>>
>> Brian
>>
>> At 9:19 AM +0900 9/2/02, Yasuo Ohgaki wrote:
>>
>>> We know current module loader is not smart :)
>>>
>>> As number of modules increases, number of module depends on another 
>>> increases. Examples are mbstirng/mailparse/exif, 
>>> session/msession/session_pgsql and bunch of session save handler
>>> modules out there, session_pgsql depends of session and pgsql module,
>>> etc.
>>>
>>> (Loading sessoin save handler as module does not work at all, since
>>> current module loader isn't take into module dependency at all)
>>>
>>> I would like to see smart module loader and/or ini parser that can
>>> address this issue. PHP crashes easily w/o it.
>>>
>>> IF statemnet is better than now, but it's not good enough.
>>> I don't think this carefully, but here is my idea.
>>>
>>> Add following member so that get_module() retrive
>>>  loading weight (we need this so that we can control sub module
>>>  loading order)
>>>  list modules depend on
>>> Check if module required is there, raise E_WARNING
>>>  if module cannot be loaded.
>>> Sort modules so that modules are loaded w/o problem.
>>> Load modules.
>>>
>>> This is easy to implement, isn't it?
>>> We may better to have smart ini parser, but it may not be
>>> required strictly for this purpose.
>>>
>>> I don't have plan to write this, since I need to modify
>>> engine code. I hope Andi or Zeev like this idea for PHP5 :)
>>>
>>> BTW, I'm +1 for having IF statement in php.ini.
>>>
>>> -- 
>>> Yasuo Ohgaki
>>
>>
>>
>>
>>
> 
> 
> 



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

Re: [PHP-DEV] mbstring

[Yasuo Ohgaki]

We should have generic code for this. IMHO.

--
Yasuo Ohgaki

Brian France wrote:
> I know this is ugly, but what about making the extensions handle it 
> themselves?
> 
> Your example of session_pgsql:
> 
> In the extension init code:
> 
> ext_enabled = 1;
> 
> if ( dlsym( NULL, "psql_module_entry" ) == NULL &&
>  dlsym( NULL, "_psql_module_entry" ) == NULL )
> {
> // print some warning about needing the pgsql extension
> // or pgsql should be loaded before this one in the php.ini
> ext_enabled = 0;
> }
> 
> if ( dlsym( NULL, "session_module_entry" ) == NULL &&
>  dlsym( NULL, "_session_module_entry" ) == NULL )
> {
> // print some warning about needing the session extension
> // or session should be loaded before this one in the php.ini
> ext_enabled = 0;
> }
> 
> The second call with a underscore is to handle Openbsd and old version 
> of FreeBSD, I think a.out things.  I am sure this can be handled 
> differently, but you get the point.
> 
> Cheers,
> 
> Brian
> 
> At 9:19 AM +0900 9/2/02, Yasuo Ohgaki wrote:
> 
>> We know current module loader is not smart :)
>>
>> As number of modules increases, number of module depends on another 
>> increases. Examples are mbstirng/mailparse/exif, 
>> session/msession/session_pgsql and bunch of session save handler
>> modules out there, session_pgsql depends of session and pgsql module,
>> etc.
>>
>> (Loading sessoin save handler as module does not work at all, since
>> current module loader isn't take into module dependency at all)
>>
>> I would like to see smart module loader and/or ini parser that can
>> address this issue. PHP crashes easily w/o it.
>>
>> IF statemnet is better than now, but it's not good enough.
>> I don't think this carefully, but here is my idea.
>>
>> Add following member so that get_module() retrive
>>  loading weight (we need this so that we can control sub module
>>  loading order)
>>  list modules depend on
>> Check if module required is there, raise E_WARNING
>>  if module cannot be loaded.
>> Sort modules so that modules are loaded w/o problem.
>> Load modules.
>>
>> This is easy to implement, isn't it?
>> We may better to have smart ini parser, but it may not be
>> required strictly for this purpose.
>>
>> I don't have plan to write this, since I need to modify
>> engine code. I hope Andi or Zeev like this idea for PHP5 :)
>>
>> BTW, I'm +1 for having IF statement in php.ini.
>>
>> -- 
>> Yasuo Ohgaki
> 
> 
> 
> 




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

Re: [PHP-DEV] mbstring

[Brian France]

At 9:25 AM +0900 9/2/02, Yasuo Ohgaki wrote:
>As all of us know, PHP crashes easily when module is loaded
>improperly.

Has anybody tracked down why this is?

This could have been the problem, but is fixed now:

http://bugs.php.net/?id=17643

(I think this link is right, bugs is down right now)

Brian





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

Re: [PHP-DEV] mbstring

[Brian France]

I know this is ugly, but what about making the extensions handle it themselves?

Your example of session_pgsql:

In the extension init code:

ext_enabled = 1;

if ( dlsym( NULL, "psql_module_entry" ) == NULL &&
  dlsym( NULL, "_psql_module_entry" ) == NULL )
{
 // print some warning about needing the pgsql extension
 // or pgsql should be loaded before this one in the php.ini
 ext_enabled = 0;
}

if ( dlsym( NULL, "session_module_entry" ) == NULL &&
  dlsym( NULL, "_session_module_entry" ) == NULL )
{
 // print some warning about needing the session extension
 // or session should be loaded before this one in the php.ini
 ext_enabled = 0;
}

The second call with a underscore is to handle Openbsd and old 
version of FreeBSD, I think a.out things.  I am sure this can be 
handled differently, but you get the point.

Cheers,

Brian

At 9:19 AM +0900 9/2/02, Yasuo Ohgaki wrote:
>We know current module loader is not smart :)
>
>As number of modules increases, number of module depends on another 
>increases. Examples are mbstirng/mailparse/exif, 
>session/msession/session_pgsql and bunch of session save handler
>modules out there, session_pgsql depends of session and pgsql module,
>etc.
>
>(Loading sessoin save handler as module does not work at all, since
>current module loader isn't take into module dependency at all)
>
>I would like to see smart module loader and/or ini parser that can
>address this issue. PHP crashes easily w/o it.
>
>IF statemnet is better than now, but it's not good enough.
>I don't think this carefully, but here is my idea.
>
>Add following member so that get_module() retrive
>  loading weight (we need this so that we can control sub module
>  loading order)
>  list modules depend on
>Check if module required is there, raise E_WARNING
>  if module cannot be loaded.
>Sort modules so that modules are loaded w/o problem.
>Load modules.
>
>This is easy to implement, isn't it?
>We may better to have smart ini parser, but it may not be
>required strictly for this purpose.
>
>I don't have plan to write this, since I need to modify
>engine code. I hope Andi or Zeev like this idea for PHP5 :)
>
>BTW, I'm +1 for having IF statement in php.ini.
>
>--
>Yasuo Ohgaki


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

Re: [PHP-DEV] mbstring

[Yasuo Ohgaki]

As all of us know, PHP crashes easily when module is loaded
improperly.

This is what we should fix.
As I mentioned in personal mail, it's not difficult to fix
at module loader level.

--
Yasuo Ohgaki


Marcus Börger wrote:
> At 01:24 02.09.2002, Yasuo Ohgaki wrote:
> 
>> Brian France wrote:
>>
>>> I know there are things the exif needs from mbstring and there is no 
>>> way to have exif link against mbstring or require it.  But couldn't 
>>> exif check to see if mbstring is loaded (or built in) and if not 
>>> print a warning that some of its functionality may not work correctly 
>>> unless mbstring is loaded (or built in)?
>>
>>
>> It's not a good idea.
>>
>> What we need is smart ini parser and module loader that understand
>> module dependecy and proper loading order.
> 
> 
> 
> PLEASE charme down on exif/mbstring liaison.
> 
> ext/exif is by now the most capable implemetnation available freely (with
> the restriction that it can only read things) so i guess i can invent some
> workaround. Or the users who really like that liaison can enable both
> modules. For me the only reason to depend on both is the combination
> of ACDSee and php. More will follow but i hope until then mbstring/I18n
> is fully integrated in php5.0.
> 
> So my vote is +1 for having I18n support for php by mbstring being default.
> 
> AND exif has no affect. It works whether or not mbstring is there. Just
> some tags might cause some problems (WinXP specific and one more).
> AND exif is disliked by the developers on this list so why do we care now?
> 
> 
> 




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

Re: [PHP-DEV] ISAPI Crash Debugging Notes

[Michael Sisolak]

Andi,

I download the alpha2 version of the php-4.3.0-dev-zend2 release. 
Unfortunatley out-of-the-box I got an "Invalid access to memory
location." error returned when I try to view I page.  I was able to
track it down to something with the browscap processing - something in
ini_parse() is causing a memory access violation, but I get lost in all
the lex code trying to figure out exactly what is going on.  I disabled
my browscap entry and was able to continue with the testing.

It does appear that the issue I'm seeing with the first thread getting
the GLOBAL_FUNCTION_TABLE as it's own local copy is fixed in Zend2:

[1340] the startup thread is 1996
[1340] copying the GLOBAL_FUNCTION_TABLE from 20933432
[1340] in HttpExtensionProc thread 1996, CG(function table) is 21138360
[1340] copying the GLOBAL_FUNCTION_TABLE from 20933432
[1340] in HttpExtensionProc thread 532, CG(function table) is 22055840
[1340] in HttpExtensionProc thread 1996, CG(function table) is 21138360

The initial thread does now get it's own copy of the
GLOBAL_FUNCTION_TABLE.  Since it will be a while before Zend2 is
production quality do you think it would be possible to port what makes
this work in Zend2 back to 4.2.x?  The changes in zend.c seem fairly
straight forward, but there may be interactions with other changes I'm
not seeing.

Michael Sisolak
[EMAIL PROTECTED]

__
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

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

Re: [PHP-DEV] Segfault in ob_*() callback

[Yasuo Ohgaki]

This is known issue for a long time.

Sebastian Bergmann wrote:
> Marcus Börger wrote:
> 
>>The problem here again is that in ob handlers no ob_xxx() function can
>>be called.
> 
*SNIP*
> 
>   It'd be okay IMHO to prohibit ob_*() calls inside a handler.
> 

There are functions like this. i.e. array_filter, etc
As these function accesses internal data structure outside
of engine's control, thus it may crash PHP.

I added warning to array functions, but I might
forget to mentioned this in ob functions page.

--
Yasuo Ohgaki


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

Re: [PHP-DEV] mbstring

[Marcus Börger]

At 01:24 02.09.2002, you wrote:
>Brian France wrote:
>>I know there are things the exif needs from mbstring and there is no way 
>>to have exif link against mbstring or require it.  But couldn't exif 
>>check to see if mbstring is loaded (or built in) and if not print a 
>>warning that some of its functionality may not work correctly unless 
>>mbstring is loaded (or built in)?
>
>It's not a good idea.
>
>What we need is smart ini parser and module loader that understand
>module dependecy and proper loading order.

We already had some discussion on some IF statements in ini
files already. I guess we might call to another mail thread here
and hope we find a volunteer. I will not invent any work here since
that would be totally useless.


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS

[Yasuo Ohgaki]

Sebastian Bergmann wrote:
> Marcus Börger wrote:
> 
>>AND please: we had an agreement that discussion
>>has to take place on this mailinglist and not at efnet
> 
> 
>   Well, it was also agreed upon to discuss the addition of new .ini
>   entries or enabling of new extensions by default, no?
> 
>   Whether or not you like, a good amount of discussion takes place on
>   the mentioned IRC channel.
> 

Speaking not knowing the issue here.

There are too many developers not on IRC obviously. If someone
would like to change someone's work or change/add/remove important
behavior, it should be posted on php-dev and discussed.

This is mentioned here sevral times at least...

Except simple bugfix patch, if there is maintainer and/or author
is known, patch should be sent to maintainer and/or author. IMHO.

--
Yasuo Ohgaki


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

Re: [PHP-DEV] mbstring

[Marcus Börger]

At 01:24 02.09.2002, Yasuo Ohgaki wrote:
>Brian France wrote:
>>I know there are things the exif needs from mbstring and there is no way 
>>to have exif link against mbstring or require it.  But couldn't exif 
>>check to see if mbstring is loaded (or built in) and if not print a 
>>warning that some of its functionality may not work correctly unless 
>>mbstring is loaded (or built in)?
>
>It's not a good idea.
>
>What we need is smart ini parser and module loader that understand
>module dependecy and proper loading order.


PLEASE charme down on exif/mbstring liaison.

ext/exif is by now the most capable implemetnation available freely (with
the restriction that it can only read things) so i guess i can invent some
workaround. Or the users who really like that liaison can enable both
modules. For me the only reason to depend on both is the combination
of ACDSee and php. More will follow but i hope until then mbstring/I18n
is fully integrated in php5.0.

So my vote is +1 for having I18n support for php by mbstring being default.

AND exif has no affect. It works whether or not mbstring is there. Just
some tags might cause some problems (WinXP specific and one more).
AND exif is disliked by the developers on this list so why do we care now?


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

Re: [PHP-DEV] Re: mbstring

[Yasuo Ohgaki]

[EMAIL PROTECTED] wrote:
> On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:
> 
> 
>>James Cox wrote:
>>
>>>Phil Copeland @ redhat pointed me at this bug:
>>>But mbstring really isn't a core module, and very few people will require
>>>kr/zh/ru style encoding.
>>>
>>>I vote to remove mbstring as a default module.
>>
>>-1 of course.
>>
>>Are you out of mind?
> 
> 
> No, not really. It was noted by more than one person that it breaks 
> some simple things in PHP, affecting the bahavior of scripts that are 
> already out there. Until it is totally stable (which you yourself it is 
> not yet) it should not be enabled by default. How, after 4.3 is branched 

What problem?

As far as I know, there is no serious problem that is not
addressed yet. If there is problem, it should be easy one to
fix. Let me know we'll fix it.

The main thing has been changed in development version is
how mbfilter works. New filter is streamable and easier to
extend, while current one is not. Current behavior will not
be changed at all.

In addition, there are few modules depends on mbstring already
and mbstring does not depend on external lib at all. There
is no reason to wait.

BTW, Derick, could you add mbstring category to bug db?
(AFAIK, there is no category for it)

--
Yasuo Ohgaki




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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-distphp.ini-recommended /main main.c output.c php_globals.h php_output.h

[Sterling Hughes]

> Marcus Börger wrote:
> > AND please: we had an agreement that discussion
> > has to take place on this mailinglist and not at efnet
> 
>   Well, it was also agreed upon to discuss the addition of new .ini
>   entries or enabling of new extensions by default, no?
> 
>   Whether or not you like, a good amount of discussion takes place on
>   the mentioned IRC channel.
> 
That's not the point, before decisions that require developer
discussion are made, the discussion should take place on php-dev@,
as on #php.bugs you only have a small subset of php developers.

-Sterling


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

[PHP-DEV] HAVE_GD_STRINGFTEX

[Melvyn Sopacua]

Hi,

The following in ext/gd/gd.c confuses me.

line 332, in function PHP_MINFO_FUNCTIONS:
#ifdef ENABLE_GD_TTF
php_info_print_table_row(2, "FreeType Support", "enabled");
#if HAVE_LIBFREETYPE
php_info_print_table_row(2, "FreeType Linkage", "with freetype");
#elif HAVE_LIBTTF
php_info_print_table_row(2, "FreeType Linkage", "with TTF library");
#else
php_info_print_table_row(2, "FreeType Linkage", "with unknown library");
#endif

So: you see 'freetype support enabled'.
Then - line 2654:
/* {{{ proto array imageftbbox(int size, int angle, string font_file, string text[, 
array extrainfo])
   Give the bounding box of a text using fonts via freetype2 */
PHP_FUNCTION(imageftbbox)
{
#if HAVE_LIBGD20 && HAVE_LIBFREETYPE && HAVE_GD_STRINGFTEX
php_imagettftext_common(INTERNAL_FUNCTION_PARAM_PASSTHRU, TTFTEXT_BBOX, 1);
#else
php_error(E_WARNING, "%s(): No FreeType 2 support in this PHP build", 
get_active_function_name(TSRMLS_C));
RETURN_FALSE;
#endif
}
/* }}} */

Why the `&& HAVE_GD_STRINGFTEX' and where does it come from? I'm using gd 2.0.1 and 
there's no `gdImageStringFTEx' in gdft.c. So I guess this is from a later version.

Looking at the name of the function, I guess this is used for the __optional__ 'extra' 
array, so why is this extension:
1) Claiming to support freetype
2) and subsequently disabeling all relevant functions
3) for an optional argument?

This applies to both 4.2.2 and 4.2.3.

Thanx,

Melvyn


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

Re: [PHP-DEV] mbstring

[Yasuo Ohgaki]

Brian France wrote:
> I know there are things the exif needs from mbstring and there is no way 
> to have exif link against mbstring or require it.  But couldn't exif 
> check to see if mbstring is loaded (or built in) and if not print a 
> warning that some of its functionality may not work correctly unless 
> mbstring is loaded (or built in)?

It's not a good idea.

What we need is smart ini parser and module loader that understand
module dependecy and proper loading order.

--
Yasuo Ohgaki


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

Re: [PHP-DEV] segfault on adding empty heredoc to string

[Zeev Suraski]

Mark them as critical and they'll get some attention :)

Is this bug new to the latest CVS or does it occur with 4.2?
At 01:10 02/09/2002, Jani Taskinen wrote:
>
> Crashes with latest CVS HEAD here too:
>
>0x828b505 in _zval_dtor (zvalue=0xbfffd540, __zend_filename=0x8376000 
>"/usr/src/web/php/php4/Zend/zend_operators.c",
> __zend_lineno=1057) at /usr/src/web/php/php4/Zend/zend_variables.c:43
>43  CHECK_ZVAL_STRING_REL(zvalue);
>(gdb) bt
>#0  0x828b505 in _zval_dtor (zvalue=0xbfffd540,
> __zend_filename=0x8376000 
> "/usr/src/web/php/php4/Zend/zend_operators.c", __zend_lineno=1057)
> at /usr/src/web/php/php4/Zend/zend_variables.c:43
>#1  0x8288e23 in concat_function (result=0x84fc4cc, op1=0x84fc4cc, 
>op2=0xbfffd540)
> at /usr/src/web/php/php4/Zend/zend_operators.c:1057
>#2  0x829d9f0 in execute (op_array=0x84fcd74) at 
>/usr/src/web/php/php4/Zend/zend_execute.c:1174
>#3  0x828d564 in zend_execute_scripts (type=8, retval=0x0, file_count=3) 
>at /usr/src/web/php/php4/Zend/zend.c:814
>#4  0x82541e1 in php_execute_script (primary_file=0xb95c) at 
>/usr/src/web/php/php4/main/main.c:1524
>#5  0x82a69b7 in main (argc=2, argv=0xb9c4) at 
>/usr/src/web/php/php4/sapi/cli/php_cli.c:683
>#6  0x410e39cb in __libc_start_main (main=0x82a5dfc , argc=2, 
>argv=0xb9c4, init=0x8088bb8 <_init>,
> fini=0x831c8b4 <_fini>, rtld_fini=0x4000aea0 <_dl_fini>, 
> stack_end=0xb9bc)
> at ../sysdeps/generic/libc-start.c:92
>
>
> p.s. There are dozens of bugs like this in the bug database too..
>  iirc, this one is also reported there too. Feel free to submit
>  patch to fix this, nobody looks in the "Scripting Engine.." 
> category,
>  so I won't expect these to be fixed really soon.
>
>
>--
>
>On Sun, 1 Sep 2002, Lukas Schroeder wrote:
>
> >hi,
> >
> >i can crash my php here by using these lines:
> >
> > >
> >$a = '';
> >$a .= << >EOF;
> >
> >?>
> >
> >can anyone second this?
> >
> >
> >regards,
> >  -lukas
> >
> >
> >#0  0x403218b5 in _zval_dtor (zvalue=0xbfffe214, __zend_filename=0x4038dc80
> >"/home/azzit/src/cvs/php4/php4/Zend/zend_operators.c", 
> __zend_lineno=1057)
> >at /home/azzit/src/cvs/php4/php4/Zend/zend_variables.c:43
> >#1  0x4031f15f in concat_function (result=0x8296a0c, op1=0x8296a0c,
> >op2=0xbfffe214) at 
> /home/azzit/src/cvs/php4/php4/Zend/zend_operators.c:1057
> >#2  0x40333fc0 in execute (op_array=0x829674c)
> >at /home/azzit/src/cvs/php4/php4/Zend/zend_execute.c:1165
> >#3  0x403239e4 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
> >at /home/azzit/src/cvs/php4/php4/Zend/zend.c:810
> >
> >
> >
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] mbstring

[Sterling Hughes]

> 
> > > I vote to remove mbstring as a default module.
> > 
> > I guess you have never tried to create a truely globalized/localized
> > application then?
> > 
> > I'm -1 on removing it, because PHP needs a consistent charset encoding
> > API that is portable across platforms. iconv and recode are "no good"
> > because their supported charsets vary from system to system and version
> > to version; some libraries actually have broken encoding tables
> > 
> 
> Wez, let me rephrase:
> 
> mbstring isn't a "gold" module which should be enabled by default.
> 
> That is, it's still -- as i see it -- just a bit more than experimental. mbstring 
>work is being done on sourceforge! 
> 
> So I want to 'disable' it by default. If you want encoding, just enable it. But 
>you're right, i've never needed to create a truely globalized/localized app. (and 
>from general principles, if you feel you need to localize any more than your 
>ui/strings.)
>

That's not what I read, perhaps you can just double clarify this -- you
do not at all want to remove mbstring from PHP (and move it say, to
pear)...

If this is correct, than I'm +1, otherwise I'm -1.  Mbstring is very
important when it comes to creating i18n applications.  Also, you seem
to forget that PHP is not only used in England, but other areas where it
is _quite_ important, and _quite_ necessary.

-Sterling

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

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

Re: [PHP-DEV] Re: mbstring

[derick]

On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:

> James Cox wrote:
> > Phil Copeland @ redhat pointed me at this bug:
> > But mbstring really isn't a core module, and very few people will require
> > kr/zh/ru style encoding.
> > 
> > I vote to remove mbstring as a default module.
> 
> -1 of course.
> 
> Are you out of mind?

No, not really. It was noted by more than one person that it breaks 
some simple things in PHP, affecting the bahavior of scripts that are 
already out there. Until it is totally stable (which you yourself it is 
not yet) it should not be enabled by default. How, after 4.3 is branched 
you were going to merge the mbstring dev thing on sourceforge into PHP 
CVS and then we can enabled it by default for PHP 5. This will get a lot 
of good testing, and then IMO the mbstring module should be integrated 
even more and replacing the things in PHP that mbstring now "changes".

Derick

---
 Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
 Frequent ranting: http://www.derickrethans.nl/
---
 PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

[PHP-DEV] Re: mbstring

[Yasuo Ohgaki]

James Cox wrote:
> Phil Copeland @ redhat pointed me at this bug:
> But mbstring really isn't a core module, and very few people will require
> kr/zh/ru style encoding.
> 
> I vote to remove mbstring as a default module.

-1 of course.

Are you out of mind?
Tell other languages developers support multibyte
strings, it's not a core feature.

And read discussion why we have it as a default.
If you don't like it, remove it by yourself.

--
Yasuo Ohgaki


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

Re: [PHP-DEV] segfault on adding empty heredoc to string

[Jani Taskinen]

  
Crashes with latest CVS HEAD here too:

0x828b505 in _zval_dtor (zvalue=0xbfffd540, __zend_filename=0x8376000 
"/usr/src/web/php/php4/Zend/zend_operators.c", 
__zend_lineno=1057) at /usr/src/web/php/php4/Zend/zend_variables.c:43
43  CHECK_ZVAL_STRING_REL(zvalue);
(gdb) bt
#0  0x828b505 in _zval_dtor (zvalue=0xbfffd540, 
__zend_filename=0x8376000 "/usr/src/web/php/php4/Zend/zend_operators.c", 
__zend_lineno=1057)
at /usr/src/web/php/php4/Zend/zend_variables.c:43
#1  0x8288e23 in concat_function (result=0x84fc4cc, op1=0x84fc4cc, op2=0xbfffd540)
at /usr/src/web/php/php4/Zend/zend_operators.c:1057
#2  0x829d9f0 in execute (op_array=0x84fcd74) at 
/usr/src/web/php/php4/Zend/zend_execute.c:1174
#3  0x828d564 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at 
/usr/src/web/php/php4/Zend/zend.c:814
#4  0x82541e1 in php_execute_script (primary_file=0xb95c) at 
/usr/src/web/php/php4/main/main.c:1524
#5  0x82a69b7 in main (argc=2, argv=0xb9c4) at 
/usr/src/web/php/php4/sapi/cli/php_cli.c:683
#6  0x410e39cb in __libc_start_main (main=0x82a5dfc , argc=2, argv=0xb9c4, 
init=0x8088bb8 <_init>, 
fini=0x831c8b4 <_fini>, rtld_fini=0x4000aea0 <_dl_fini>, stack_end=0xb9bc)
at ../sysdeps/generic/libc-start.c:92


p.s. There are dozens of bugs like this in the bug database too..
 iirc, this one is also reported there too. Feel free to submit
 patch to fix this, nobody looks in the "Scripting Engine.." category,
 so I won't expect these to be fixed really soon.


-- 

On Sun, 1 Sep 2002, Lukas Schroeder wrote:

>hi,
>
>i can crash my php here by using these lines:
>
>
>$a = '';
>$a .= <
>?>
>
>can anyone second this?
>
>
>regards,
>  -lukas
>
>
>#0  0x403218b5 in _zval_dtor (zvalue=0xbfffe214, __zend_filename=0x4038dc80
>"/home/azzit/src/cvs/php4/php4/Zend/zend_operators.c", __zend_lineno=1057)
>at /home/azzit/src/cvs/php4/php4/Zend/zend_variables.c:43
>#1  0x4031f15f in concat_function (result=0x8296a0c, op1=0x8296a0c, 
>op2=0xbfffe214) at /home/azzit/src/cvs/php4/php4/Zend/zend_operators.c:1057
>#2  0x40333fc0 in execute (op_array=0x829674c)
>at /home/azzit/src/cvs/php4/php4/Zend/zend_execute.c:1165
>#3  0x403239e4 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
>at /home/azzit/src/cvs/php4/php4/Zend/zend.c:810
>
>
>


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

[PHP-DEV] Re: mbstring

[Yasuo Ohgaki]

James Cox wrote:
> Phil Copeland @ redhat pointed me at this bug:
> 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72752

Check with latest CVS before posting.
I fixed this bug weeks ago.

--
Yasuo Ohgaki


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

RE: [PHP-DEV] mbstring

[James Cox]

> > I vote to remove mbstring as a default module.
> 
> I guess you have never tried to create a truely globalized/localized
> application then?
> 
> I'm -1 on removing it, because PHP needs a consistent charset encoding
> API that is portable across platforms. iconv and recode are "no good"
> because their supported charsets vary from system to system and version
> to version; some libraries actually have broken encoding tables
> 

Wez, let me rephrase:

mbstring isn't a "gold" module which should be enabled by default.

That is, it's still -- as i see it -- just a bit more than experimental. mbstring work 
is being done on sourceforge! 

So I want to 'disable' it by default. If you want encoding, just enable it. But you're 
right, i've never needed to create a truely globalized/localized app. (and from 
general principles, if you feel you need to localize any more than your 
ui/strings.)

 -- james


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

Re: [PHP-DEV] mbstring

[Wez Furlong]

On 01/09/02, "James Cox" <[EMAIL PROTECTED]> wrote:
> The other he mentions is mbstring seems to cause problems. I have
> experienced this too.

Umm, dont enable the transparent encoding support then.
I don't, and I've had no problems.

> But mbstring really isn't a core module, and very few people will require
> kr/zh/ru style encoding.

But what about all the other encodings (not just charsets)?

> I vote to remove mbstring as a default module.

I guess you have never tried to create a truely globalized/localized
application then?

I'm -1 on removing it, because PHP needs a consistent charset encoding
API that is portable across platforms. iconv and recode are "no good"
because their supported charsets vary from system to system and version
to version; some libraries actually have broken encoding tables

Enabling mbstring by default was a very good move (tm).
But enabling the transparent encoding support option just because it's
there is not a very good move.  Just because people enable stuff they
don't understand is not a good reason to disable this module.

Actually, I'm -2 on removing it; -1 because PHP scripts can use it, and
and additional -1 because PHP extensions that need to play with encodings
can (and do) also use this portable API.

--Wez.


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

Re: [PHP-DEV] Re: Antispam system

[derick]

On Sun, 1 Sep 2002, CHAILLAN Nicolas wrote:

> It seems that the DNS is down, thats not only the hoster. I'm sure that it
> doesn't exist anymore.

[derick@kossu derick]$ dig master.php.net | grep synacor
master.php.net. 21575   IN  CNAME   synacor1.php.net.
synacor1.php.net.   16374   IN  A   208.210.50.162

It's in the DNS just fine.

Derick

> 
> --
> Merci de nous avoir choisi. - Thanks you for your choice.
> Nicos - CHAILLAN Nicolas
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> www.GroupAKT.com - Hébergement Group.
> www.WorldAKT.com - Hébergement de sites Internet
> "Chaillan Nicolas" <[EMAIL PROTECTED]> a écrit dans le message de news:
> [EMAIL PROTECTED]
> > Hello, many people that try to send me a mail are stopped by the antispam
> > system, they should answer to the message so I can get the mail, this is
> > fine, but many people don't understand it and just dont do it, is there a
> > way to deactivate it?
> >
> > --
> > Merci de nous avoir choisi. - Thanks you for your choice.
> > Nicos - CHAILLAN Nicolas
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > www.GroupAKT.com - Hébergement Group.
> > www.WorldAKT.com - Hébergement de sites Internet
> >
> >
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

---
 Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
 Frequent ranting: http://www.derickrethans.nl/
---
 PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

[PHP-DEV] Re: Antispam system

[CHAILLAN Nicolas]

It seems that the DNS is down, thats not only the hoster. I'm sure that it
doesn't exist anymore.

--
Merci de nous avoir choisi. - Thanks you for your choice.
Nicos - CHAILLAN Nicolas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
www.GroupAKT.com - Hébergement Group.
www.WorldAKT.com - Hébergement de sites Internet
"Chaillan Nicolas" <[EMAIL PROTECTED]> a écrit dans le message de news:
[EMAIL PROTECTED]
> Hello, many people that try to send me a mail are stopped by the antispam
> system, they should answer to the message so I can get the mail, this is
> fine, but many people don't understand it and just dont do it, is there a
> way to deactivate it?
>
> --
> Merci de nous avoir choisi. - Thanks you for your choice.
> Nicos - CHAILLAN Nicolas
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> www.GroupAKT.com - Hébergement Group.
> www.WorldAKT.com - Hébergement de sites Internet
>
>



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

Re: [PHP-DEV] Antispam system

[CHAILLAN Nicolas]

Thanks, btw are you sure that it will work? :-)

--
Merci de nous avoir choisi. - Thanks you for your choice.
Nicos - CHAILLAN Nicolas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
www.GroupAKT.com - Hébergement Group.
www.WorldAKT.com - Hébergement de sites Internet
"Sander Roobol" <[EMAIL PROTECTED]> a écrit dans le message de news:
[EMAIL PROTECTED]
> See http://master.php.net/manage/users.php (when it's up again)
>
> Sander
>
> On Sun, Sep 01, 2002 at 08:28:46PM +0200, CHAILLAN Nicolas wrote:
> > Hello, many people that try to send me a mail are stopped by the
antispam
> > system, they should answer to the message so I can get the mail, this is
> > fine, but many people don't understand it and just dont do it, is there
a
> > way to deactivate it?
> >
> > --
> > Merci de nous avoir choisi. - Thanks you for your choice.
> > Nicos - CHAILLAN Nicolas
> > [EMAIL PROTECTED]
> > [EMAIL PROTECTED]
> > www.GroupAKT.com - Hébergement Group.
> > www.WorldAKT.com - Hébergement de sites Internet
> >
> >
> >
> > --
> > PHP Development Mailing List 
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >



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

Re: [PHP-DEV] adding persistent toggle to zend_stack implementation

[Andi Gutmans]

I think this is fine.

Andi

At 11:32 AM 8/27/2002 -0400, George Schlossnagle wrote:
>Hi,
>
>I'd like to use the zend_stack stuff for stacked handlers in the new 
>apache_hooks sapi stuff, but right now, it emalloc's everything, which is 
>unacceptable for my usage.  I could write my own stack implementation just 
>for the sapi stuf, but thats seems less productive than making zend_stack 
>more universally useable.
>
>I've added a persistent attribute to the struct so that it behaves more 
>like zend_hash, added a zend_stack_init_ex which allows setting of this 
>flag, and #define'd zend_stack_init to do a non-persistent 
>zend_stack_init_ex.  Patches are attached.
>
>If this is somehow undesireable, please let me know and I will just 
>reimplement stacks for sapi.
>
>George
>
>
>
>
>Index: Zend/zend_stack.c
>===
>RCS file: /repository/Zend/zend_stack.c,v
>retrieving revision 1.11
>diff -u -3 -r1.11 zend_stack.c
>--- Zend/zend_stack.c   6 Jan 2002 15:21:09 -   1.11
>+++ Zend/zend_stack.c   27 Aug 2002 15:15:37 -
>@@ -21,10 +21,11 @@
>  #include "zend.h"
>  #include "zend_stack.h"
>
>-ZEND_API int zend_stack_init(zend_stack *stack)
>+ZEND_API int zend_stack_init_ex(zend_stack *stack, int persistent)
>  {
> stack->top = 0;
>-   stack->elements = (void **) emalloc(sizeof(void **) * 
>STACK_BLOCK_SIZE);
>+stack->persistent = persistent;
>+   stack->elements = (void **) pemalloc(sizeof(void **) * 
>STACK_BLOCK_SIZE,  persistent);
> if (!stack->elements) {
> return FAILURE;
> } else {
>@@ -36,13 +37,13 @@
>  ZEND_API int zend_stack_push(zend_stack *stack, void *element, int size)
>  {
> if (stack->top >= stack->max) { /* we need to allocate 
> more memory */
>-   stack->elements = (void **) erealloc(stack->elements,
>-  (sizeof(void **) * (stack->max += 
>STACK_BLOCK_SIZE)));
>+   stack->elements = (void **) perealloc(stack->elements,
>+  (sizeof(void **) * (stack->max += 
>STACK_BLOCK_SIZE)), stack->persistent);
> if (!stack->elements) {
> return FAILURE;
> }
> }
>-   stack->elements[stack->top] = (void *) emalloc(size);
>+   stack->elements[stack->top] = (void *) pemalloc(size, 
>stack->persistent);
> memcpy(stack->elements[stack->top], element, size);
> return stack->top++;
>  }
>@@ -63,7 +64,7 @@
>  ZEND_API int zend_stack_del_top(zend_stack *stack)
>  {
> if (stack->top > 0) {
>-   efree(stack->elements[--stack->top]);
>+   pefree(stack->elements[--stack->top], stack->persistent);
> }
> return SUCCESS;
>  }
>@@ -96,11 +97,11 @@
> register int i;
>
> for (i = 0; i < stack->top; i++) {
>-   efree(stack->elements[i]);
>+   pefree(stack->elements[i], stack->persistent);
> }
>
> if (stack->elements) {
>-   efree(stack->elements);
>+   pefree(stack->elements, stack->persistent);
> }
> return SUCCESS;
>  }
>Index: Zend/zend_stack.h
>===
>RCS file: /repository/Zend/zend_stack.h,v
>retrieving revision 1.13
>diff -u -3 -r1.13 zend_stack.h
>--- Zend/zend_stack.h   6 Jan 2002 15:21:09 -   1.13
>+++ Zend/zend_stack.h   27 Aug 2002 15:15:37 -
>@@ -22,14 +22,14 @@
>  #define ZEND_STACK_H
>
>  typedef struct _zend_stack {
>-   int top, max;
>+   int top, max, persistent;
> void **elements;
>  } zend_stack;
>
>
>  #define STACK_BLOCK_SIZE 64
>-
>-ZEND_API int zend_stack_init(zend_stack *stack);
>+#define zend_stack_init(a) zend_stack_init_ex(a, 0);
>+ZEND_API int zend_stack_init_ex(zend_stack *stack, int persistent);
>  ZEND_API int zend_stack_push(zend_stack *stack, void *element, int size);
>  ZEND_API int zend_stack_top(zend_stack *stack, void **element);
>  ZEND_API int zend_stack_del_top(zend_stack *stack);
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] ISAPI Crash Debugging Notes

[Andi Gutmans]

Any chance you can setup and Engine 2 build and see if this problem persists?

Andi

At 06:42 AM 8/27/2002 -0700, Michael Sisolak wrote:

>--- Zeev Suraski <[EMAIL PROTECTED]> wrote:
> > At 09:53 27/08/2002, Michael Sisolak wrote:
> > > > >i've been doing some debugging of the crashes when running php
> > under
> > > > >the isapi sapi.  is anybody else currently looking at this?  if
> > you
> > > > >are let's talk - here are my notes so far.
> > > >
> > > > first off, can you try using
> > > > http://www.php.net/~zeev/php-4.2.3rc1.tar.gz
> > > > and see if you experience the same problems?  i've made some
> > > > thread-safety related fixes there, even though none should lead
> > > > to a hard crash...
> > >
> > >zeev,
> > >
> > >i believe that i may have tracked down a major isapi filter
> > >thread-safety hole.  if i understand  what zend_startup() is doing
> > >correctly, it assumes that the thread that it runs under will not
> > also
> > >be used to serve http requests.
> >
> > No, the startup thread can be used as a regular HTTP thread, nothing
> > in the
> > code should prevent that.
> > The globals code in the startup sequence is very tricky, but it
> > should work.
>
>This is a sample of the debug output that I'm seeing (this is PHP 4.2.1
>running under Windows 2000 Professional, single CPU):
>
>[1948] the startup thread is 1956
>[1948] GLOBAL_FUNCTION_TABLE is 4226120
>[1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120
>[1948] in HttpExtensionProc thread 1520, CG(function_table) is 18834536
>[1948] in HttpExtensionProc thread 920, CG(function_table) is 18838912
>[1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120
>[1948] in HttpExtensionProc thread 1256, CG(function_table) is 19250808
>[1948] in HttpExtensionProc thread 920, CG(function_table) is 18838912
>[1948] in HttpExtensionProc thread 1956, CG(function_table) is 4226120
>
>Notice that the initial thread (1956) appears to continue to use
>GLOBAL_FUNCTION_TABLE as it's own CG(function_table).  I'm reporting
>the GLOBAL_FUNCTION_TABLE value from within zend_startup() - is there
>some point later in the code that makes it okay that this is the same
>value that I get for a CG(function_table) later?
>
> > Either way - starting threads from an ISAPI filter/extension is
> > completely
> > forbidden (or at least strongly discouraged) so even if there is some
> > bug
> > in there, starting our own thread is not an option.
>
>I don't believe that this is true.  In this sample on MSDN:
>
>http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q197728
>
>their code for GetExtensionVersion calls AfxBeginThread.  Also in this
>document:
>
>http://msdn.microsoft.com/library/en-us/vccore/html/vcconatlserverandcom.asp
>
>point 1 recommends "Create your own thread in GetExtensionVersion on
>which you can initialize COM..."
>
> > Can you give me the data I mentioned in the previous letter?
>
>This is PHP 4.2.1 running under Windows 2000 Professional (SP3) on a
>single CPU system.  I can't really send the code as I'm currently
>testing with a large application that I have been running under CGI.
>I'll see if I can come up with a simpler example that causes the crash,
>but the debug output above would be the same either way.  Please let me
>know if there is anything else I can provide to help in tracking this
>down.
>
>
>Michael Sisolak
>[EMAIL PROTECTED]
>
>
>__
>Do You Yahoo!?
>Yahoo! Finance - Get real-time stock quotes
>http://finance.yahoo.com
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] Possible leak in zend_llist ?

[Andi Gutmans]

Hey,

I think you're right. Someone changed this code a while ago and might have 
introduced this problem (or it was like this before).
I commited a fix and hope it doesn't break anything :)
If anyone uses llist's please make sure it's OK.

Andi

At 07:30 AM 8/27/2002 -0400, l0t3k wrote:
>hi,
>  im reviewing the source code of zend_llist.c and it appears there may be an
>inconsistency in the way deletions are handled which may cause leaks.
>   in particular the macro DEL_LLIST_ELEMENT only releases memory for a node
>if a destructor is specified for the zend_llist, whereas memory is always
>allocated for the node when an insert is performed.
>this macro is used only in zend_llist_apply_with_del and
>zend_llist_del_element. note that
>no other code in the file assumes that the destructor function is
>responsible for the deallocation of the _node_
>
>compare DEL_LLIST_ELEMENT (snippet)
>
>if ((l)->dtor) {\
> (l)->dtor((current)->data);\
> pefree((current), (l)->persistent);\
>}\
>
>with zend_llist_destroy
>
>   if (l->dtor) {
>l->dtor(current->data);
>   }
>   pefree(current, l->persistent);
>
>
>l0t3k
>
>
>
>--
>PHP Development Mailing List 
>To unsubscribe, visit: http://www.php.net/unsub.php


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

Re: [PHP-DEV] mbstring

[Marcus Börger]

At 11:49 01.09.2002, James Cox wrote:
>Phil Copeland @ redhat pointed me at this bug:
>
>https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72752
>
>Seems that there are a number of issues (i'm going to verify & patch his
>fixes right now).
>
>The other he mentions is mbstring seems to cause problems. I have
>experienced this too.
>
>Guys, i don't want to be mean or sound racist or anything else you throw at
>me.
>
>But mbstring really isn't a core module, and very few people will require
>kr/zh/ru style encoding.
>
>I vote to remove mbstring as a default module.
>
>And for those who say that i could just disable it -- well, the converse is
>true. Let us STOP burdening default builds with crap that is unlikely to be
>used.
>
>

The problem with removing mbstring as a default module would be its upcoming
integration into Zend engine for full I18n of php. So i would prefer making 
it a
module that does not harm anything. In other words it must not change anything
until some character conversion is really needed.

I see the reasons for making it a non default module but i also think it 
will become
a core module. The remaining question is: Do we want full I18n for php?

marcus


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

RE: [PHP-DEV] mbstring

[Marcus Börger]

At 20:57 01.09.2002, Brian France wrote:
>At 8:47 PM +0200 9/1/02, Marcus Börger wrote:
>>At 20:38 01.09.2002, Brian France wrote:
>>>At 6:29 PM +0100 9/1/02, James Cox wrote:
Where is your patch?
>>>
>>>The patch basically renames php_treat_data to php_treat_data_default,
>>>creates a function pointer called php_treat_data that is defaulted to
>>>php_treat_data_default, removes all mbstrings references in php_main.h
>>>and makes mbstring.c change the php_treat_data to mbstr_treat_data in
>>>the INIT function and restores its value in SHUTDOWN.
>>>
>>>This allows us to only load the mbstrings extension on the machines that 
>>>need it, which is a very small percentage of our over all server count.
>>>
>>>This patch is based off of the 4.2.2 release and there have been changes 
>>>in CVS to the exif extension that may need mbstring to be static because 
>>>it is expecting mbstr_treat_data to be handling the php_treat_data stuff.
>>
>>exif uses mbstring since 4.3 so 4.2.3 would be no problem
>
>Which means that my fix would fix it for 4.2.x releases and then it breaks 
>again in 4.3. Break, I mean mbstring can not be built as a shared extension.

I meant you do not have to care about exif in 4.2.3 and it does not break 
thinks in 4.3 since
availability is checked. The only thing is that there is be a lack in 
documentation for the case
that mbstring is a shared module.


>I know there are things the exif needs from mbstring and there is no way 
>to have exif link against mbstring or require it.  But couldn't exif check 
>to see if mbstring is loaded (or built in) and if not print a warning that 
>some of its functionality may not work correctly unless mbstring is loaded 
>(or built in)?

I think we could, especially since 4.3 features are not sipulated yet.

marcus


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

Re: [PHP-DEV] segfault on adding empty heredoc to string

[Timm Friebe]

On Sun, 2002-09-01 at 19:50, Lukas Schroeder wrote:
> hi,
> 
> i can crash my php here by using these lines:

Nope, works fine:
---
thekid@friebes:~ > cat | php -q

thekid@friebes:~ > php -v 
4.2.1
thekid@friebes:~ > uname -a
FreeBSD friebes.net 4.6-STABLE FreeBSD 4.6-STABLE #4: Mon Aug 26
23:06:34 CEST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC 
i386
---
friebe@php3:~ > cat | php -q

friebe@php3:~ > php -v 
4.2.1
friebe@php3:~ > uname -a
Linux php3.de 2.4.18 #1 Sat Apr 20 16:15:17 CEST 2002 i686 unknown
(SuSE 7.2)
---
cgi@heuer1:~ > cat | php4 -q

cgi@heuer1:~ > php4 -v
4.1.2
cgi@heuer1:~ > uname -a
Linux heuer1 2.2.20 #1 SMP Mon Nov 5 14:36:30 CET 2001 i686 unknown
(Debian)
---

-- 
Timm


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

RE: [PHP-DEV] mbstring

[Brian France]

At 8:47 PM +0200 9/1/02, Marcus Börger wrote:
>At 20:38 01.09.2002, Brian France wrote:
>>At 6:29 PM +0100 9/1/02, James Cox wrote:
>>>Where is your patch?
>>
>>The patch basically renames php_treat_data to php_treat_data_default,
>>creates a function pointer called php_treat_data that is defaulted to
>>php_treat_data_default, removes all mbstrings references in php_main.h
>>and makes mbstring.c change the php_treat_data to mbstr_treat_data in
>>the INIT function and restores its value in SHUTDOWN.
>>
>>This allows us to only load the mbstrings extension on the machines
>>that need it, which is a very small percentage of our over all
>>server count.
>>
>>This patch is based off of the 4.2.2 release and there have been
>>changes in CVS to the exif extension that may need mbstring to be
>>static because it is expecting mbstr_treat_data to be handling the
>>php_treat_data stuff.
>
>exif uses mbstring since 4.3 so 4.2.3 would be no problem

Which means that my fix would fix it for 4.2.x releases and then it
breaks again in 4.3. Break, I mean mbstring can not be built as a
shared extension.

I know there are things the exif needs from mbstring and there is no
way to have exif link against mbstring or require it.  But couldn't
exif check to see if mbstring is loaded (or built in) and if not
print a warning that some of its functionality may not work correctly
unless mbstring is loaded (or built in)?

Thanks,

Brian

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

RE: [PHP-DEV] mbstring

[Marcus Börger]

At 20:38 01.09.2002, Brian France wrote:
>At 6:29 PM +0100 9/1/02, James Cox wrote:
>>Where is your patch?
>
>The patch basically renames php_treat_data to php_treat_data_default,
>creates a function pointer called php_treat_data that is defaulted to
>php_treat_data_default, removes all mbstrings references in php_main.h
>and makes mbstring.c change the php_treat_data to mbstr_treat_data in
>the INIT function and restores its value in SHUTDOWN.
>
>This allows us to only load the mbstrings extension on the machines that 
>need it, which is a very small percentage of our over all server count.
>
>This patch is based off of the 4.2.2 release and there have been changes 
>in CVS to the exif extension that may need mbstring to be static because 
>it is expecting mbstr_treat_data to be handling the php_treat_data stuff.

exif uses mbstring since 4.3 so 4.2.3 would be no problem

(...)


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

Re: [PHP-DEV] Antispam system

[Sander Roobol]

See http://master.php.net/manage/users.php (when it's up again)

Sander

On Sun, Sep 01, 2002 at 08:28:46PM +0200, CHAILLAN Nicolas wrote:
> Hello, many people that try to send me a mail are stopped by the antispam
> system, they should answer to the message so I can get the mail, this is
> fine, but many people don't understand it and just dont do it, is there a
> way to deactivate it?
> 
> --
> Merci de nous avoir choisi. - Thanks you for your choice.
> Nicos - CHAILLAN Nicolas
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> www.GroupAKT.com - Hébergement Group.
> www.WorldAKT.com - Hébergement de sites Internet
> 
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

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

RE: [PHP-DEV] mbstring

[Brian France]

At 6:29 PM +0100 9/1/02, James Cox wrote:
>Where is your patch?

The patch basically renames php_treat_data to php_treat_data_default,
creates a function pointer called php_treat_data that is defaulted to
php_treat_data_default, removes all mbstrings references in php_main.h
and makes mbstring.c change the php_treat_data to mbstr_treat_data in
the INIT function and restores its value in SHUTDOWN.

This allows us to only load the mbstrings extension on the machines 
that need it, which is a very small percentage of our over all server 
count.

This patch is based off of the 4.2.2 release and there have been 
changes in CVS to the exif extension that may need mbstring to be 
static because it is expecting mbstr_treat_data to be handling the 
php_treat_data stuff.

There was also talk about moving the changing mbstr_treat_data to be 
the default handler since there was so much duplicate code in 
mbstring.

Thanks,

Brian

--

diff -rc php-4.2.2/ext/mbstring/mbstring.c php-4.2.2/ext/mbstring/mbstring.c
*** php-4.2.2/ext/mbstring/mbstring.c   Wed Apr 24 02:46:23 2002
--- php-4.2.2/ext/mbstring/mbstring.c   Mon Jun 10 14:10:58 2002
***
*** 93,98 
--- 93,100 
{ MULTIPART_CONTENT_TYPE, 
sizeof(MULTIPART_CONTENT_TYPE)-1,   NULL, 
rfc1867_post_handler },
{ NULL, 0, NULL, NULL }
   };
+
+ void mbstr_treat_data(int arg, char *str, zval* destArray TSRMLS_DC);
   #endif

   static struct mb_overload_def mb_ovld[] = {
***
*** 529,534 
--- 531,538 
   #if defined(MBSTR_ENC_TRANS)
sapi_unregister_post_entry(mbstr_post_entries);
sapi_register_post_entries(mbstr_post_entries);
+
+ php_treat_data = mbstr_treat_data;
   #endif

REGISTER_LONG_CONSTANT("MB_OVERLOAD_MAIL", MB_OVERLOAD_MAIL, 
CONST_CS | CONST_PERSISTENT);
***
*** 552,557 
--- 556,565 

   #if HAVE_MBREGEX
zend_hash_destroy(&MBSTRG(ht_rc));
+ #endif
+
+ #if defined(MBSTR_ENC_TRANS)
+ php_treat_data = php_treat_data_default;
   #endif

return SUCCESS;
diff -rc php-4.2.2/main/php_main.h php-4.2.2/main/php_main.h
*** php-4.2.2/main/php_main.h   Mon Mar  4 10:46:55 2002
--- php-4.2.2/main/php_main.h   Mon Jun 10 14:09:59 2002
***
*** 53,60 
   extern int php_init_environ(void);
   extern int php_shutdown_environ(void);

- #if defined(MBSTR_ENC_TRANS)
- #define php_treat_data mbstr_treat_data
- #endif
-
   #endif
--- 53,56 
diff -rc php-4.2.2/main/php_variables.c php-4.2.2/main/php_variables.c
*** php-4.2.2/main/php_variables.c  Tue Dec 11 07:31:05 2001
--- php-4.2.2/main/php_variables.c  Mon Jun 10 14:09:59 2002
***
*** 28,33 
--- 28,34 

   #include "zend_globals.h"

+ void *(*php_treat_data)(int arg, char *str, zval* destArray 
TSRMLS_DC) = php_treat_data_default;

   PHPAPI void php_register_variable(char *var, char *strval, zval 
*track_vars_array TSRMLS_DC)
   {
***
*** 215,221 
   }


! void php_treat_data(int arg, char *str, zval* destArray TSRMLS_DC)
   {
char *res = NULL, *var, *val, *separator=NULL;
const char *c_var;
--- 216,222 
   }


! void php_treat_data_default(int arg, char *str, zval* destArray TSRMLS_DC)
   {
char *res = NULL, *var, *val, *separator=NULL;
const char *c_var;
diff -rc php-4.2.2/main/php_variables.h php-4.2.2/main/php_variables.h
*** php-4.2.2/main/php_variables.h  Tue Dec 11 07:31:05 2001
--- php-4.2.2/main/php_variables.h  Mon Jun 10 14:09:59 2002
***
*** 30,36 
   #define PARSE_COOKIE 2
   #define PARSE_STRING 3

! void php_treat_data(int arg, char *str, zval* destArray TSRMLS_DC);
   PHPAPI void php_import_environment_variables(zval *array_ptr TSRMLS_DC);
   PHPAPI void php_register_variable(char *var, char *val, pval 
*track_vars_array TSRMLS_DC);
   /* binary-safe version */
--- 30,39 
   #define PARSE_COOKIE 2
   #define PARSE_STRING 3

! extern void *(*php_treat_data)(int arg, char *str, zval* destArray 
TSRMLS_DC);
!
! void php_treat_data_default(int arg, char *str, zval* destArray TSRMLS_DC);
!
   PHPAPI void php_import_environment_variables(zval *array_ptr TSRMLS_DC);
   PHPAPI void php_register_variable(char *var, char *val, pval 
*track_vars_array TSRMLS_DC);
   /* binary-safe version */

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

[PHP-DEV] Antispam system

[CHAILLAN Nicolas]

Hello, many people that try to send me a mail are stopped by the antispam
system, they should answer to the message so I can get the mail, this is
fine, but many people don't understand it and just dont do it, is there a
way to deactivate it?

--
Merci de nous avoir choisi. - Thanks you for your choice.
Nicos - CHAILLAN Nicolas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
www.GroupAKT.com - Hébergement Group.
www.WorldAKT.com - Hébergement de sites Internet



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

RE: [PHP-DEV] segfault on adding empty heredoc to string

[Mike Robinson]

No problems with 4.2.2 as apache-1.3.26 dso on RH-7.2

Regards
Mike Robinson


-Original Message-
From: Lukas Schroeder [mailto:[EMAIL PROTECTED]] 
Sent: Sunday, September 01, 2002 1:50 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] segfault on adding empty heredoc to string


hi,

i can crash my php here by using these lines:



can anyone second this?


regards,
  -lukas


#0  0x403218b5 in _zval_dtor (zvalue=0xbfffe214,
__zend_filename=0x4038dc80
"/home/azzit/src/cvs/php4/php4/Zend/zend_operators.c",
__zend_lineno=1057)
at /home/azzit/src/cvs/php4/php4/Zend/zend_variables.c:43
#1  0x4031f15f in concat_function (result=0x8296a0c, op1=0x8296a0c, 
op2=0xbfffe214) at
/home/azzit/src/cvs/php4/php4/Zend/zend_operators.c:1057
#2  0x40333fc0 in execute (op_array=0x829674c)
at /home/azzit/src/cvs/php4/php4/Zend/zend_execute.c:1165
#3  0x403239e4 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/azzit/src/cvs/php4/php4/Zend/zend.c:810


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


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

Re: [PHP-DEV] segfault on adding empty heredoc to string

[Andrey Hristov]

No problems on win32 , php-430-dev cli.ZE2.

Best regards
Andrey Hristov


- Original Message -
From: "Lukas Schroeder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 01, 2002 8:50 PM
Subject: [PHP-DEV] segfault on adding empty heredoc to string


> hi,
>
> i can crash my php here by using these lines:
>
> 
> $a = '';
> $a .= << EOF;
>
> ?>
>
> can anyone second this?
>
>
> regards,
>   -lukas
>
>
> #0  0x403218b5 in _zval_dtor (zvalue=0xbfffe214,
__zend_filename=0x4038dc80
> "/home/azzit/src/cvs/php4/php4/Zend/zend_operators.c",
__zend_lineno=1057)
> at /home/azzit/src/cvs/php4/php4/Zend/zend_variables.c:43
> #1  0x4031f15f in concat_function (result=0x8296a0c, op1=0x8296a0c,
> op2=0xbfffe214) at
/home/azzit/src/cvs/php4/php4/Zend/zend_operators.c:1057
> #2  0x40333fc0 in execute (op_array=0x829674c)
> at /home/azzit/src/cvs/php4/php4/Zend/zend_execute.c:1165
> #3  0x403239e4 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
> at /home/azzit/src/cvs/php4/php4/Zend/zend.c:810
>
>
> --
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
>


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

Re: [PHP-DEV] segfault on adding empty heredoc to string

[derick]

Hey,

I can reproduce this crash:

Program received signal SIGSEGV, Segmentation fault.
0x081f8ddf in _zval_dtor (zvalue=0xbfffd3f0, __zend_filename=0x8272220 
"/dat/dev/php/php-4.3.0dev/Zend/zend_operators.c", 
__zend_lineno=1057) at 
/dat/dev/php/php-4.3.0dev/Zend/zend_variables.c:43
43  CHECK_ZVAL_STRING_REL(zvalue);
(gdb) bt
#0  0x081f8ddf in _zval_dtor (zvalue=0xbfffd3f0, 
__zend_filename=0x8272220 
"/dat/dev/php/php-4.3.0dev/Zend/zend_operators.c", 
__zend_lineno=1057) at 
/dat/dev/php/php-4.3.0dev/Zend/zend_variables.c:43
#1  0x081f6ccd in concat_function (result=0x8328f9c, op1=0x8328f9c, 
op2=0xbfffd3f0) at /dat/dev/php/php-4.3.0dev/Zend/zend_operators.c:1057
#2  0x08207d4c in execute (op_array=0x8324ab4) at 
/dat/dev/php/php-4.3.0dev/Zend/zend_execute.c:1174
#3  0x40019bcc in xdebug_execute () from 
/dat/dev/php/xdebug/modules/xdebug.so
#4  0x081fa67e in zend_execute_scripts (type=8, retval=0x0, 
file_count=3) at /dat/dev/php/php-4.3.0dev/Zend/zend.c:813
#5  0x081cc4ea in php_execute_script (primary_file=0xb920) at 
/dat/dev/php/php-4.3.0dev/main/main.c:1524
#6  0x08214164 in main (argc=1, argv=0xb9c4) at 
/dat/dev/php/php-4.3.0dev/sapi/cli/php_cli.c:683
#7  0x40520306 in __libc_start_main (main=0x82138bc , argc=1, 
ubp_av=0xb9c4, init=0x8078b84 <_init>, fini=0x8214820 <_fini>, 
rtld_fini=0x4000d2dc <_dl_fini>, stack_end=0xb9bc) at 
../sysdeps/generic/libc-start.c:129


Derick

On Sun, 1 Sep 2002, Lukas Schroeder wrote:

> hi,
> 
> i can crash my php here by using these lines:
> 
>  
> $a = '';
> $a .= << EOF;
> 
> ?>
> 
> can anyone second this?
> 
> 
> regards,
>   -lukas
> 
> 
> #0  0x403218b5 in _zval_dtor (zvalue=0xbfffe214, __zend_filename=0x4038dc80
> "/home/azzit/src/cvs/php4/php4/Zend/zend_operators.c", __zend_lineno=1057)
> at /home/azzit/src/cvs/php4/php4/Zend/zend_variables.c:43
> #1  0x4031f15f in concat_function (result=0x8296a0c, op1=0x8296a0c, 
> op2=0xbfffe214) at /home/azzit/src/cvs/php4/php4/Zend/zend_operators.c:1057
> #2  0x40333fc0 in execute (op_array=0x829674c)
> at /home/azzit/src/cvs/php4/php4/Zend/zend_execute.c:1165
> #3  0x403239e4 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
> at /home/azzit/src/cvs/php4/php4/Zend/zend.c:810
> 
> 
> -- 
> PHP Development Mailing List 
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

---
 Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
 Frequent ranting: http://www.derickrethans.nl/
---
 PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

[PHP-DEV] segfault on adding empty heredoc to string

[Lukas Schroeder]

hi,

i can crash my php here by using these lines:



can anyone second this?


regards,
  -lukas


#0  0x403218b5 in _zval_dtor (zvalue=0xbfffe214, __zend_filename=0x4038dc80
"/home/azzit/src/cvs/php4/php4/Zend/zend_operators.c", __zend_lineno=1057)
at /home/azzit/src/cvs/php4/php4/Zend/zend_variables.c:43
#1  0x4031f15f in concat_function (result=0x8296a0c, op1=0x8296a0c, 
op2=0xbfffe214) at /home/azzit/src/cvs/php4/php4/Zend/zend_operators.c:1057
#2  0x40333fc0 in execute (op_array=0x829674c)
at /home/azzit/src/cvs/php4/php4/Zend/zend_execute.c:1165
#3  0x403239e4 in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /home/azzit/src/cvs/php4/php4/Zend/zend.c:810


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

RE: [PHP-DEV] mbstring

[James Cox]

 
> I do have one request, when the time comes to remove it from the 
> default also change the PHP core code so that it can be built as a 
> shared extension and loaded on the fly.  Currently it can only be 
> compiled into PHP statically and building it as .so means hacking the 
> PHP source and the mbstring module (which I have already done with a 
> small patch).
> 
Where is your patch?

 -- james

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

Re: [PHP-DEV] Segfault in ob_*() callback

[Marcus Börger]

At 18:02 01.09.2002, Sebastian Bergmann wrote:
>Marcus Börger wrote:
> > The problem here again is that in ob handlers no ob_xxx() function can
> > be called.
>
>   FYI: I know that I shouldn't do that, but I tried
>
>  class Test {
>   function Test() {
> ob_start(array($this, 'transform'));
>   }
>
>   function transform($buffer) {
> ob_end_clean();
> return $buffer;
>   }
> }
>
> $test = new Test;
> ?>
>
>   out of curiosity, while trying to get Cache_Lite working with
>   XML_Transformer.
>
>   It'd be okay IMHO to prohibit ob_*() calls inside a handler.

Perhaps ob_clean() and ob_flush() should be exceptions to this.


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

Re: [PHP-DEV] Segfault in ob_*() callback

[Sebastian Bergmann]

Marcus Börger wrote:
> The problem here again is that in ob handlers no ob_xxx() function can
> be called.

  FYI: I know that I shouldn't do that, but I tried



  out of curiosity, while trying to get Cache_Lite working with
  XML_Transformer.

  It'd be okay IMHO to prohibit ob_*() calls inside a handler.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

Re: [PHP-DEV] Segfault in ob_*() callback

[Marcus Börger]

At 17:10 01.09.2002, Zeev Suraski wrote:
>At 17:51 01/09/2002, Marcus Börger wrote:
>>At 15:25 01.09.2002, Zeev Suraski wrote:
>>>At 16:10 01/09/2002, Marcus Börger wrote:
The problem is that in function
PHPAPI void php_end_ob_buffer(zend_bool send_buffer, zend_bool 
just_flush TSRMLS_DC)

the user function is called wether or not send_buffer is zero. (Zero 
means flush
here and means the function must not be called, as far as i can tell by 
now).
>>>
>>>It should be called either way.
>>
>>My first thoughts were that there is no need to call the user functions when
>>cleaning the output. So could you explain why?
>
>I actually mixed it up with just_flush.

After reading again: It seems i mixed it up myself in first answer.


>   You may be right about send_buffer, even though it's debatable.  You 
> may want to perform some processing even if the buffer gets canceled, but 
> I guess that wouldn't be good programming.
>However, either way, this should not be causing any problems if the 
>handler and buffering layer are coded properly.  Calling the handler 
>should not cause a crash regardless of whether the buffer ends up getting 
>sent or not.

I checked it and what happens is that the call to user function of cause 
calls the user function again which then
calls php_end_ob_buffer. The problem here again is that in ob handlers no 
ob_xxx() function can be called.

Since i also agree that relying on a handler beeing called upon cleaning is 
no good idea i suggest we disable
calling the user function and such for that case. Could you please check - 
i am looking for other the problems
in the output code and havin problems with all the versions since some of 
my patches were removed.


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

Re: [PHP-DEV] mbstring

[Brian France]

At 10:49 AM +0100 9/1/02, James Cox wrote:
>I vote to remove mbstring as a default module.

I completely agree!

I do have one request, when the time comes to remove it from the 
default also change the PHP core code so that it can be built as a 
shared extension and loaded on the fly.  Currently it can only be 
compiled into PHP statically and building it as .so means hacking the 
PHP source and the mbstring module (which I have already done with a 
small patch).

Just my 2 cents.

Thanks,

Brian

BTW, sorry if this has been already done in the CVS tree and I didn't catch it.

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

Re: [PHP-DEV] Segfault in ob_*() callback

[Zeev Suraski]

At 17:51 01/09/2002, Marcus Börger wrote:
>At 15:25 01.09.2002, Zeev Suraski wrote:
>>At 16:10 01/09/2002, Marcus Börger wrote:
>>>The problem is that in function
>>>PHPAPI void php_end_ob_buffer(zend_bool send_buffer, zend_bool 
>>>just_flush TSRMLS_DC)
>>>
>>>the user function is called wether or not send_buffer is zero. (Zero 
>>>means flush
>>>here and means the function must not be called, as far as i can tell by 
>>>now).
>>
>>It should be called either way.
>
>My first thoughts were that there is no need to call the user functions when
>cleaning the output. So could you explain why?

I actually mixed it up with just_flush.  You may be right about 
send_buffer, even though it's debatable.  You may want to perform some 
processing even if the buffer gets canceled, but I guess that wouldn't be 
good programming.
However, either way, this should not be causing any problems if the handler 
and buffering layer are coded properly.  Calling the handler should not 
cause a crash regardless of whether the buffer ends up getting sent or not.

Zeev

Zeev


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

Re: [PHP-DEV] Segfault in ob_*() callback

[Marcus Börger]

At 15:25 01.09.2002, Zeev Suraski wrote:
>At 16:10 01/09/2002, Marcus Börger wrote:
>>The problem is that in function
>>PHPAPI void php_end_ob_buffer(zend_bool send_buffer, zend_bool just_flush 
>>TSRMLS_DC)
>>
>>the user function is called wether or not send_buffer is zero. (Zero 
>>means flush
>>here and means the function must not be called, as far as i can tell by now).
>
>It should be called either way.

My first thoughts were that there is no need to call the user functions when
cleaning the output. So could you explain why?

marcus


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

Re: [PHP-DEV] mbstring

[Dan Kalowsky]

On Sun, 1 Sep 2002, James Cox wrote:

> I vote to remove mbstring as a default module.

+1000

> And for those who say that i could just disable it -- well, the converse is
> true. Let us STOP burdening default builds with crap that is unlikely to be
> used.

Another voice of reason!  Welcome!

>---<
Dan Kalowsky"A little less conversation,
http://www.deadmime.org/~danka little more action."
[EMAIL PROTECTED]- "A Little Less Conversation",
[EMAIL PROTECTED]Elvis Presley


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

RE: [PHP-DEV] mbstring

[Mike Robinson]

 James Cox wrote:

> I vote to remove mbstring as a default module.

+1

> Let us STOP burdening default builds with crap that is unlikely
> to be used.

Amen.

Regards
Mike Robinson


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

Re: [PHP-DEV] Segfault in ob_*() callback

[Zeev Suraski]

At 16:10 01/09/2002, Marcus Börger wrote:
>The problem is that in function
>PHPAPI void php_end_ob_buffer(zend_bool send_buffer, zend_bool just_flush 
>TSRMLS_DC)
>
>the user function is called wether or not send_buffer is zero. (Zero means 
>flush
>here and means the function must not be called, as far as i can tell by now).

It should be called either way.

Zeev


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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-distphp.ini-recommended /main main.c output.c php_globals.h php_output.h

[Sebastian Bergmann]

Marcus Börger wrote:
> AND please: we had an agreement that discussion
> has to take place on this mailinglist and not at efnet

  Well, it was also agreed upon to discuss the addition of new .ini
  entries or enabling of new extensions by default, no?

  Whether or not you like, a good amount of discussion takes place on
  the mentioned IRC channel.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-distphp.ini-recommended /main main.c output.c php_globals.h php_output.h

[Sebastian Bergmann]

Marcus Börger wrote:
> Until now the only thing you were able to deliver is a
> script that is also broken for 4.2.3.

  You're mixing issues here.

  In recent days I discovered 3 problems with ob_*() functionality:

1.) Dumping of a text instead of writing it to a file.

This one is fixed by reverting double_buffering.

2.) error_log() sends wrong headers, when used in an output buffer.

Derick investigated this one, found the cause, but no fix.

3.) A segfault, that exists in the PHP 4.2 branch as well as in HEAD.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

Re: [PHP-DEV] Segfault in ob_*() callback

[Marcus Börger]

At 15:06 01.09.2002, Sebastian Bergmann wrote:
>Marcus Börger wrote:
> > Ever tried this in earlier version of PHP? I guess not!
>
>   I tested it with PHP 4.2.3-RC1, and it's broken there, too.
>
>   I did not claim that you broke this one, Marcus, so why the harsh
>   tone?


Because you reverted some of the work that took me two weeks
to develop and another week to test and some more days to test
some comments.

And your test has nothing to with the problem.

The problem is that in function
PHPAPI void php_end_ob_buffer(zend_bool send_buffer, zend_bool just_flush 
TSRMLS_DC)

the user function is called wether or not send_buffer is zero. (Zero means 
flush
here and means the function must not be called, as far as i can tell by now).

marcus


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

Re: [PHP-DEV] Reverting ob_*() changes

[Sebastian Bergmann]

Marcus Börger wrote:
> Read other mail threads on this - i am not going to comment every
> single thread concerning the same things

  I read the other mails / threads carefully.

  It's not my idea alone that this commit broke something.
  Consensus was reached on #php.bugs to revert this for now.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-dist php.ini-recommended /main main.c output.c php_globals.h php_output.h

[Marcus Börger]

At 14:56 01.09.2002, Sebastian Bergmann wrote:
>"Thies C. Arntzen" wrote:
> > why?
>
>   Because it's broken.

Until now the only thing you were able to deliver is a
script that is also broken for 4.2.3. Since the code of
output-buffering is not capable to do what you did in
that script...

marcus

AND please: we had an agreement that discussion
has to take place on this mailinglist and not at efnet


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

Re: [PHP-DEV] Segfault in ob_*() callback

[Sebastian Bergmann]

Marcus Börger wrote:
> Ever tried this in earlier version of PHP? I guess not!

  I tested it with PHP 4.2.3-RC1, and it's broken there, too.

  I did not claim that you broke this one, Marcus, so why the harsh
  tone?

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-dist php.ini-recommended /main main.c output.c php_globals.h php_output.h

[Marcus Börger]

At 13:37 01.09.2002, Sebastian Bergmann wrote:
>Sebastian Bergmann wrote:
> > sebastian   Sun Sep  1 07:33:19 2002 EDT
> >
> >   Modified files:
> > /php4   NEWS php.ini-dist php.ini-recommended
> > /php4/main  main.c output.c php_globals.h php_output.h
> >   Log:
> >   Per discussion on #php.bugs (+1 from at least Derick and Jani),
> >   revert double_buffering.
>
>   This fixes the issue I mentioned where a variable was dumped to stdout
>   instead of beeing written to a file.
>
>   It does not fix the error_log() issue. It does not fix the segfault I
>   mentioned in ob_*() under certain circumstances.


So where is the need? You simply stripped out some functions of
your choice. Especially some related to NEWS entries and ini settings
so i guess your aim was to remove exactly those...


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

Re: [PHP-DEV] Reverting ob_*() changes

[Marcus Börger]

At 14:40 31.08.2002, Sebastian Bergmann wrote:
>   In recent days there was a lot of discussion on reverting Marcus'
>   changes to the output buffering on #php.bugs.
>
>   I'm not sure if
>
> http://www.sebastian-bergmann.de/stuff/revert
>
>   does this properly, so I don't want to commit it myself.
>
>   Marcus, please review this patch, revert it yourself -- or, better yet,
>   fix your code.


Read other mail threads on this - i am not going to comment every single
thread concerning the same things


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

Re: [PHP-DEV] Segfault in ob_*() callback

[Marcus Börger]

At 10:10 31.08.2002, Sebastian Bergmann wrote:
>   Reproducing script:
>
>  class Test {
>   function Test() {
> ob_start(array($this, 'transform'));
>   }
>
>   function transform($buffer) {
> ob_end_clean();
> return $buffer;
>   }
> }
>
> $test = new Test;
> ?>
>
>   Stacktrace:
>
> http://www.sebastian-bergmann.de/stuff/stacktrace.txt


Ever tried this in earlier version of PHP? I guess not!

This is one of the thinks i yet not started to work on.
Here is the gdb output from PHP 4.2.3

(gdb) file /usr/src/PHP_4_2_3/php
Reading symbols from /usr/src/PHP_4_2_3/php...done.
(gdb) set args /var/www/html/php/ext/ob-clean.php
(gdb) run
Starting program: /usr/src/PHP_4_2_3/php /var/www/html/php/ext/ob-clean.php

Program received signal SIGSEGV, Segmentation fault.
0x081746bc in zend_fetch_var_address (opline=0x8230a3c, Ts=0xbf800040, type=1)
 at ./zend_execute.c:529
529 zval *varname = get_zval_ptr(&opline->op1, Ts, &free_op1, 
BP_VAR_R);
(gdb)



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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-dist php.ini-recommended /main main.c output.c php_globals.h php_output.h

[Sebastian Bergmann]

"Thies C. Arntzen" wrote:
> why?

  Because it's broken.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

[PHP-DEV] Re: Clone fonction of ftp_quit

[CHAILLAN Nicolas]

Ewps, I just saw that it already exists, sorry.

--
Merci de nous avoir choisi. - Thanks you for your choice.
Nicos - CHAILLAN Nicolas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
www.GroupAKT.com - Hébergement Group.
www.WorldAKT.com - Hébergement de sites Internet
"Chaillan Nicolas" <[EMAIL PROTECTED]> a écrit dans le message de news:
[EMAIL PROTECTED]
> Why not renaming it to ftp_close so it can be like fclose, mysql_close...
> that would be more generic than quit.
>
> Objections? Ideas?
>
> --
> Merci de nous avoir choisi. - Thanks you for your choice.
> Nicos - CHAILLAN Nicolas
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> www.GroupAKT.com - Hébergement Group.
> www.WorldAKT.com - Hébergement de sites Internet
>
>



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

[PHP-DEV] Clone fonction of ftp_quit

[CHAILLAN Nicolas]

Why not renaming it to ftp_close so it can be like fclose, mysql_close...
that would be more generic than quit.

Objections? Ideas?

--
Merci de nous avoir choisi. - Thanks you for your choice.
Nicos - CHAILLAN Nicolas
[EMAIL PROTECTED]
[EMAIL PROTECTED]
www.GroupAKT.com - Hébergement Group.
www.WorldAKT.com - Hébergement de sites Internet



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

[PHP-DEV] Re: mbstring

[CHAILLAN Nicolas]

"James Cox" <[EMAIL PROTECTED]> a écrit dans le message de news:
[EMAIL PROTECTED]
> Phil Copeland @ redhat pointed me at this bug:
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72752
>
> Seems that there are a number of issues (i'm going to verify & patch his
> fixes right now).
>
> The other he mentions is mbstring seems to cause problems. I have
> experienced this too.
>
> Guys, i don't want to be mean or sound racist or anything else you throw
at
> me.
>
> But mbstring really isn't a core module, and very few people will require
> kr/zh/ru style encoding.
>
> I vote to remove mbstring as a default module.

+1

>
> And for those who say that i could just disable it -- well, the converse
is
> true. Let us STOP burdening default builds with crap that is unlikely to
be
> used.

Right.

>
>  -- james
> --
> James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
> Was I helpful?
http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/
>



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

[PHP-DEV] Re: [PHP-CVS] cvs: php4 / NEWS php.ini-dist php.ini-recommended /main main.c output.c php_globals.h php_output.h

[Sebastian Bergmann]

Sebastian Bergmann wrote:
> sebastian   Sun Sep  1 07:33:19 2002 EDT
>
>   Modified files:
> /php4   NEWS php.ini-dist php.ini-recommended
> /php4/main  main.c output.c php_globals.h php_output.h
>   Log:
>   Per discussion on #php.bugs (+1 from at least Derick and Jani),
>   revert double_buffering.

  This fixes the issue I mentioned where a variable was dumped to stdout
  instead of beeing written to a file.

  It does not fix the error_log() issue. It does not fix the segfault I
  mentioned in ob_*() under certain circumstances.

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

Re: [PHP-DEV] mbstring

[Sebastian Bergmann]

James Cox wrote:
> I vote to remove mbstring as a default module.

  +1

-- 
  Sebastian Bergmann
  http://sebastian-bergmann.de/ http://phpOpenTracker.de/

  Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/

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

Re: [PHP-DEV] mbstring

[derick]

On Sun, 1 Sep 2002, James Cox wrote:

> The other he mentions is mbstring seems to cause problems. I have
> experienced this too.
> 
> Guys, i don't want to be mean or sound racist or anything else you throw at
> me.
> 
> But mbstring really isn't a core module, and very few people will require
> kr/zh/ru style encoding.
> 
> I vote to remove mbstring as a default module.

+1
 
> And for those who say that i could just disable it -- well, the converse is
> true. Let us STOP burdening default builds with crap that is unlikely to be
> used.

+1

Derick

---
 Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
 Frequent ranting: http://www.derickrethans.nl/
---
 PHP: Scripting the Web - [EMAIL PROTECTED]
All your branches are belong to me!
SRM: Script Running Machine - www.vl-srm.net
---


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

[PHP-DEV] mbstring

[James Cox]

Phil Copeland @ redhat pointed me at this bug:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72752

Seems that there are a number of issues (i'm going to verify & patch his
fixes right now).

The other he mentions is mbstring seems to cause problems. I have
experienced this too.

Guys, i don't want to be mean or sound racist or anything else you throw at
me.

But mbstring really isn't a core module, and very few people will require
kr/zh/ru style encoding.

I vote to remove mbstring as a default module.

And for those who say that i could just disable it -- well, the converse is
true. Let us STOP burdening default builds with crap that is unlikely to be
used.

 -- james
--
James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/


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

[PHP-DEV] I'm Back

[James Cox]

For those who may be interested, I am back from my trip to California, and
am going through mails.


 --James

--
James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/


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