Hi, Jani Taskinen <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Dec 2002, Moriyoshi Koizumi wrote: > > >--snip > >> If you compile mbstring as static module, you can workaround this > >> error. It's not very good idea to enable it anyway.. > > > >I'm wondering why you referred to enabling mbstring as no good idea > >in this report. I believe the problem has been properly avoided, or am I > >missing something? > > Maybe I just assumed something, but I think this person really > doesn't even need it. :) That's why I also noted about enabling > only extensions that he actually needs. > > The biggest concern about mbstring for me is that it changes some core > functions behaviour. I haven't followed the development of mbstring > closely so I might be wrong here..just that one major bug caused by > that duplication of code (for post vars parsing) gives me creeps. :) > > As long as it's separate from core PHP, I will never suggest anybody > to use it. > I could understand the reason of your severe glance at the module, but please, please stop blaming mbstring for the reported bugs which you might suppose don't appear to be fixed in a moment :P Most of them are totally irrelevant. BTW that most infamous bug was caused by a carelessness rather than the duplication of codes. > >> For the mbstring authors: You should decide whether or not to allow > >> external usage of these functions (ie. in other extensions) or disable > >> the building of this extension as shared altogether.. > > > >What decision? We actually externalise some functions just for that > >purpose. Perhaps did you mean integration of mbstring into core part? > > Yes. But mbstring is not the only extension having the same problem > when compiled as shared. At least iconv, openssl, pcre and gd also > have some external parts used outside them. e.g. All the extensions > and core parts using those externalized functions in mbstring must > now put these around the parts using those: > > #ifndef COMPILE_DL_MBSTRING > #endif > > This is done in some places, but not everywhere, like shown by > the bug report. > > The same problem is also with PCRE and GD extensions. > One solution would be to make at least PCRE and MBstring always > static, ie. disallow building them as shared. Or move them > under ext/standard.. > > With openssl and iconv it's a bit different, the same libraries > are required by other extensions. This problem could be solved by > linking the core PHP always with those, even when compiling openssl > or iconv as shared extensions. I see the issue around the shared extensions too. We definitely need more clever dynamic loading mechanism as Yasuo mentioned. I don't think mbstring needs to be built static as long as it exists as an extension. > >BTW we are now working on a new mbstring API specification so that other > >extension authors can use the functions with more convenience and in no > >more doubt about their usage. If we should treat it in a special way, > >please let us know. > > Yeah, keep it simple. :) Okay, it's not always prone to be complicated :) Moriyoshi > --Jani > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
