Both 4.3 and Head still have a problem with mbstring not being
default
under win32. Exif module can be compiled but not loaded because it
uses a function from mbstring. Exif tests for HAVE_MBSTRING and
COMPILE_DL_MBSTRING. The question is why HAVE_MBSTRING is
defined but COMPILE_DL_MBSTRING
At 13:17 16.12.2002, Edin Kadribasic wrote:
Both 4.3 and Head still have a problem with mbstring not being
default
under win32. Exif module can be compiled but not loaded because it
uses a function from mbstring. Exif tests for HAVE_MBSTRING and
COMPILE_DL_MBSTRING. The question is why
At 09:14 AM 11/13/2002 -0500, Andrei Zmievski wrote:
On Wed, 13 Nov 2002, Melvyn Sopacua wrote:
FWIW:
* If this is ever going to make core as a part of PHP's i18n efforts, you
are going to have to deal with the 'unseen' at some point. You are not
going to identify them, by testing it
On Fri, 15 Nov 2002, Andi Gutmans wrote:
It's not that I think enabling it is such a bad idea but as we're going for
PHP 5 right after PHP 4.3 anyway I don't think it's too bad to wait for
that. I'm sure lots of people will test PHP 5 RC's so there'll be lots of
testing (long sentence but I
At 11:14 PM 11/14/2002 -0500, Andrei Zmievski wrote:
On Fri, 15 Nov 2002, Andi Gutmans wrote:
It's not that I think enabling it is such a bad idea but as we're going
for
PHP 5 right after PHP 4.3 anyway I don't think it's too bad to wait for
that. I'm sure lots of people will test PHP 5 RC's
Derick Rethans wrote:
On Wed, 13 Nov 2002, Yasuo Ohgaki wrote:
Jani Taskinen wrote:
Oh, I forgot: How many bug reports have we got so
far for that fuckup with 4.2.3 ??? I _REALLY_ don't want
to see another wave of those for 4.3.0..
Do you mean array input handling bug?
It's not
For me it was the wide stream of bugreports coming in; can't speak
for
the others though.
If the stream of bug reports was the criteria the whole of PHP
should be considered highly experimental :)
Edin
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
On 11/13/02, Derick Rethans [EMAIL PROTECTED] wrote:
On Wed, 13 Nov 2002, Marcus Börger wrote:
At 04:11 13.11.2002, Jani Taskinen wrote:
Since when have we started to use users as guinea-pigs
for testing EXPERIMENTAL extensions without them even
really knowing about
At 10:53 13.11.2002, Wez Furlong wrote:
On 11/13/02, Derick Rethans [EMAIL PROTECTED] wrote:
On Wed, 13 Nov 2002, Marcus Börger wrote:
At 04:11 13.11.2002, Jani Taskinen wrote:
Since when have we started to use users as guinea-pigs
for testing EXPERIMENTAL extensions without
At 10:53 13-11-2002, Wez Furlong wrote:
On 11/13/02, Derick Rethans [EMAIL PROTECTED] wrote:
On Wed, 13 Nov 2002, Marcus Börger wrote:
At 04:11 13.11.2002, Jani Taskinen wrote:
Since when have we started to use users as guinea-pigs
for testing EXPERIMENTAL extensions without
On Wed, 13 Nov 2002, Melvyn Sopacua wrote:
FWIW:
* If this is ever going to make core as a part of PHP's i18n efforts, you
are going to have to deal with the 'unseen' at some point. You are not
going to identify them, by testing it within a select group. For this
reason, the userbase is
Andrei Zmievski [EMAIL PROTECTED] wrote:
On Wed, 13 Nov 2002, Melvyn Sopacua wrote:
FWIW:
* If this is ever going to make core as a part of PHP's i18n efforts, you
are going to have to deal with the 'unseen' at some point. You are not
going to identify them, by testing it within a
At 15:14 13-11-2002, Andrei Zmievski wrote:
On Wed, 13 Nov 2002, Melvyn Sopacua wrote:
FWIW:
* If this is ever going to make core as a part of PHP's i18n efforts, you
are going to have to deal with the 'unseen' at some point. You are not
going to identify them, by testing it within a
On November 13, 2002 07:50 am, Melvyn Sopacua wrote:
FWIW:
* If this is ever going to make core as a part of PHP's i18n efforts, you
are going to have to deal with the 'unseen' at some point. You are not
going to identify them, by testing it within a select group. For this
reason,
At 15:14 13-11-2002, Andrei Zmievski wrote:
On Wed, 13 Nov 2002, Melvyn Sopacua wrote:
FWIW:
* If this is ever going to make core as a part of PHP's i18n efforts, you
are going to have to deal with the 'unseen' at some point. You are not
going to identify them, by testing it within a
Andrei Zmievski wrote:
Explain to me please why --enable-mbstring is not enough.
Obviously, --enable-mbstring is not enough.
There are several reasons including crashes without
mbstring.
If one think it's not stable (while real users do not
think its unstable), --enable mbstring should be
On November 7, 2002 10:04 am, Andrei Zmievski wrote:
At the PHP Conference in Germany several of us have discussed the
current state of mbstring and there was a proposal to not have it
enabled by default for 4.3.0 release. It seems that the extension
attempts to do magic stuff by overloading
Hi,
Thanks for the report.
Although I found a bug in the overloading code, I wonder why the mail()
function entry was not found on RINIT. Any insights?
Moriyoshi
Ilia A. [EMAIL PROTECTED] wrote:
On November 7, 2002 10:04 am, Andrei Zmievski wrote:
At the PHP Conference in Germany several
On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote:
Hi,
Thanks for the report.
Although I found a bug in the overloading code, I wonder why the mail()
function entry was not found on RINIT. Any insights?
It seems the mail() function is not avaliable on that system because sendmail
was
Oops, why didn't I notice such a trivial thing before asking a braindead
question... Anyway I bet the problem should be gone by my patch that was
just commited.
Moriyoshi
Ilia A. [EMAIL PROTECTED] wrote:
On November 12, 2002 04:58 pm, Moriyoshi Koizumi wrote:
Hi,
Thanks for the report.
Since I've gotten involved in this conversation would like to add my opinion
to the tally. I too believe that at least at this point, the mbstring
extension should not be enabled by default.
There are two reasons for this decision:
1) Majority of PHP users do not require this functionality.
I've just tried the latest CVS, it still crashes, the backtrace is same as
before.
Ilia
On November 12, 2002 05:21 pm, Moriyoshi Koizumi wrote:
Oops, why didn't I notice such a trivial thing before asking a braindead
question... Anyway I bet the problem should be gone by my patch that was
On Tue, 12 Nov 2002, Ilia A. wrote:
Since I've gotten involved in this conversation would like to add my opinion
to the tally. I too believe that at least at this point, the mbstring
extension should not be enabled by default.
There are two reasons for this decision:
1) Majority of PHP users
Moriyoshi Koizumi wrote:
Hi,
Thanks for the report.
Although I found a bug in the overloading code, I wonder why the mail()
function entry was not found on RINIT. Any insights?
If sendmail binary cannot be found at configure time, mail() may not
be compiled in PHP under UNIX like OS :(
IMO,
Jani Taskinen writes:
I must (still) agree. +1 for making it disabled for now..
(people who need it, already know to use
--enable-mbstring with 4.2.3)
Exactly.
It should remain off by default until it's solid.
Regards
Mike Robinson
--
PHP Development Mailing List
Mike Robinson wrote:
Jani Taskinen writes:
I must (still) agree. +1 for making it disabled for now..
(people who need it, already know to use
--enable-mbstring with 4.2.3)
Exactly.
It should remain off by default until it's solid.
Guys, please comment when you use it actually.
i.e.
At 23:56 12.11.2002, Ilia A. wrote:
Since I've gotten involved in this conversation would like to add my opinion
to the tally. I too believe that at least at this point, the mbstring
extension should not be enabled by default.
There are two reasons for this decision:
1) Majority of PHP users do
Since when have we started to use users as guinea-pigs
for testing EXPERIMENTAL extensions without them even
really knowing about it?!!
You can't FORCE anybody to use it. 99% of apps out there
DO NO NEED IT..get it?? (they've managed without it very long time..)
Oh, I forgot: How many bug reports have we got so
far for that fuckup with 4.2.3 ??? I _REALLY_ don't want
to see another wave of those for 4.3.0..
--Jani
On Wed, 13 Nov 2002, Marcus Börger wrote:
At 23:56 12.11.2002, Ilia A. wrote:
Since I've gotten involved in this
At 04:11 13.11.2002, Jani Taskinen wrote:
Since when have we started to use users as guinea-pigs
for testing EXPERIMENTAL extensions without them even
really knowing about it?!!
mbstring is not EXPERIMENTAL and i said let them try it. That
does not mean test it. We think it works .
On November 12, 2002 09:42 pm, Marcus Börger wrote:
At 23:56 12.11.2002, Ilia A. wrote:
Since I've gotten involved in this conversation would like to add my
opinion to the tally. I too believe that at least at this point, the
mbstring extension should not be enabled by default.
There are
Jani Taskinen wrote:
Oh, I forgot: How many bug reports have we got so
far for that fuckup with 4.2.3 ??? I _REALLY_ don't want
to see another wave of those for 4.3.0..
Do you mean array input handling bug?
It's not mbstring developers' fault.
--
Yasuo Ohgaki
On Wed, 13 Nov
On Tue, 12 Nov 2002, Ilia A. wrote:
mbstring has many dedicated developers whom are doing excellent maintaining
and upgrading this extension. Which at the moment makes mbstring very much a
work in progress, there is hardly a day without at least one or two CVS
commits to it. Since this is a
Andrei Zmievski wrote:
I very much agree and am extremly reluctant to have mbstring enabled by
default, even though it is a very promising extension.
I can change my mind only if someone writes smart module loader that
detects module dependency. Otherwise, it's just confusing.
i.e. undefined
Hmm, there might be no much need to fix this bug as it is not
enabled by default... If the script still sefaults with my patch, I can no
longer determine theplace at which it goes wrong just with your backtrace precisely,
as it is apparently a double-free bug.
Moriyoshi
Ilia A. [EMAIL
On November 13, 2002 12:28 am, Moriyoshi Koizumi wrote:
Hmm, there might be no much need to fix this bug as it is not
enabled by default... If the script still sefaults with my patch, I can no
longer determine theplace at which it goes wrong just with your backtrace
precisely, as it is
On Wed, 13 Nov 2002, Marcus Börger wrote:
At 04:11 13.11.2002, Jani Taskinen wrote:
Since when have we started to use users as guinea-pigs
for testing EXPERIMENTAL extensions without them even
really knowing about it?!!
mbstring is not EXPERIMENTAL and i said let them try
On Wed, 13 Nov 2002, Yasuo Ohgaki wrote:
Jani Taskinen wrote:
Oh, I forgot: How many bug reports have we got so
far for that fuckup with 4.2.3 ??? I _REALLY_ don't want
to see another wave of those for 4.3.0..
Do you mean array input handling bug?
It's not mbstring
--snip
uhm, I don't think it works stable enough.
I think the decision making went right, and I've got no more objection to
that point. but I wonder how this could be certified as a stable module
that is not widely used by the core developers?
Moriyoshi
Derick
--
On Wed, 13 Nov 2002, Moriyoshi Koizumi wrote:
--snip
uhm, I don't think it works stable enough.
I think the decision making went right, and I've got no more objection to
that point. but I wonder how this could be certified as a stable module
that is not widely used by the core
Historically, I have been against mbstring being enabled by default.
My feelings towards anything being enabled by default, unless it is
considered core functionality, is pretty negative though.
The reasoning to consider a extension as a part of core, is prone
to be obscure. It's
--snip
but the mysql extension isn't invasive of other parts of the language, and
can be safely disabled. I do not believe mbstring can be safely disabled,
and i do not think that you have the transparent stuff disabled by default.
Right, I'm sure those two cases are different. I just wanted
I see the known-good codeset conversion implementation as a *very* good
reason to have mbstring enabled by default.
(Just look at all the problems with iconv and recode on different systems
out there).
I agree that the magic features for lazy programmers (function overloading
and transparent
I think Wez got a point here. Disabling mbstring can make many unhappy.
--
Maxim Maletsky
[EMAIL PROTECTED]
Wez Furlong [EMAIL PROTECTED] wrote... :
I see the known-good codeset conversion implementation as a *very* good
reason to have mbstring enabled by default.
(Just look at all the
I completely agree with Wez.
mbstring has very foundamental functionalities for multibyte users.
Multibyte users can 'not' build any useful application without mbstring.
We must understand there are so many users who are using multibyte
character encoding.
multibyte string functions for
To make php be easier usable in non US-ASCII (127chars) environments
especially those requiring UCS-2, UTF-8 or other any character mapping
other than iso-8859-1 or -15 we should more likly try to integrate mbstring
fully in php. As long as we cannot or want not make it a core component
such as
On Thu, 7 Nov 2002, Marcus Boerger wrote:
To make php be easier usable in non US-ASCII (127chars) environments
especially those requiring UCS-2, UTF-8 or other any character mapping
other than iso-8859-1 or -15 we should more likly try to integrate mbstring
fully in php. As long as we cannot
On Thu, 7 Nov 2002, Marcus Boerger wrote:
To make php be easier usable in non US-ASCII (127chars) environments
especially those requiring UCS-2, UTF-8 or other any character mapping
other than iso-8859-1 or -15 we should more likly try to
integrate mbstring
fully in php. As long as
I agree with you that the codeset conversion functions should be there
by default (iconv and recode seem to have patchy/variable support on
different platforms; mbstring is reliable since we know exactly what is
supported in there).
I've been using the conversion functions of mbstring in
On Thu, 7 Nov 2002, Derick Rethans wrote:
On Thu, 7 Nov 2002, Marcus Boerger wrote:
To make php be easier usable in non US-ASCII (127chars) environments
especially those requiring UCS-2, UTF-8 or other any character mapping
other than iso-8859-1 or -15 we should more likly try to integrate
Hi,
Now the transparent encoding conversion is disabled by default, and so is
the function overloading. And the extension is not likely to cause any harm
to other tests; recently some test failures related to output handlers were
reported in fact, but the problem have been properly avoided.
It's interesting to me that this topic is brought up again and again
about once every 3 or 4 months. The same points are rehashed each
time, and the same result is reached, nothing is changed about
mbstring. I believe this is partially because developers ask questions
about mbstring, and
Hi,
AFAIK, php_stat() and tsrm_virtual_cwd() related problems under multibyte
win32 environment were already fixed by Rui. But the bugs are still active
under some unix operating systems that accept Shift_JIS as its locale
charset/encoding if you specify it, as EUC-JP is most suitable to use
Hi Erica,
Personally, I would roll my own tarball/package based on the now fixed code
in the 4.2 branch of CVS. However, as I mentioned in your original
PR, there is a bug that affects file_exists on some systems; AFAIK,
this has yet to be resolved which I why I suggested that you ask here,
and
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
Wez Furlong wrote:
Having been using it to handle more than 105,000 email messages over
the last 18 months *in production*, I have to disagree.
*SNIP*
Now, the mbstr-enc-trans might have had some stability issues, but as
I've been saying, it is NOT enabled by default, and lets print a
AFAIK, there is no serious bug in mbstring.
If there is serious problem, let us know so that it can be
addressed.
Then start with removing double url decoding of the input...
and then fix the mad separator counter ...
Stefan
--
PHP Development Mailing List http://www.php.net/
To
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
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.
On 09/01/02, James Cox [EMAIL PROTECTED] wrote:
mbstring isn't a gold module which should be enabled by default.
But there was a discussion and it was agreed to enable it by default!
That is, it's still -- as i see it -- just a bit more than experimental.
mbstring work is being done on
At 05:15 02/09/2002, Yasuo Ohgaki wrote:
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
At 03:41 02/09/2002, Brian France wrote:
I know this is ugly, but what about making the extensions handle it
themselves?
It's actually not ugly at all. Letting the modules handle it themselves is
the Right Way, because only they know what they need. The only question is
whether we need to
Having been using it to handle more than 105,000 email messages over
the last 18 months *in production*, I have to disagree.
I have to say that I'm appalled that most of the people making these
I completely agree comments have probably never even tried to use
mbstring; most certainly haven't
I do agree with Wez (not 'completely agree', though ;)
FWIW, mbstring was/is indeed enabled by default under Windows, and I think
that at this stage this is not a good idea. There was at least one serious
crash in the code that was introduced by the changes, into both the
mbstring version
Wez,
lets loose the crap here. I am happy to see mbstring in PHP! I have used it too, when
I needed multibyte support.
But you see, it's not really all that solid. It needs more work (hence this apparent
development outside of php.net). All I am saying is that we should disable it by
default
At 13:19 02/09/2002, James Cox wrote:
As I see it, PHP was designed with speed and simplicity in mind.
It was indeed..
Having the burden of a large number of extra modules compiled in by
default doesn't help, and deviates from this path.
Not really. Speed-wise, adding modules has a
At 13:19 02/09/2002, James Cox wrote:
As I see it, PHP was designed with speed and simplicity in mind.
It was indeed..
Having the burden of a large number of extra modules compiled in by
default doesn't help, and deviates from this path.
Not really. Speed-wise, adding modules has a
On 09/02/02, James Cox [EMAIL PROTECTED] wrote:
But you see, it's not really all that solid. It needs more work (hence this
apparent development outside of php.net).
But it *is* VERY stable in the default configuration.
All I am saying is that we should
disable it by default in current
But it *is* VERY stable in the default configuration.
All I am saying is that we should
disable it by default in current releases. For PHP5, we should
have proper
mbstring support that should probably also be transparent; by
that I mean I
see no reason for it not to be as standard
Wez,
lets loose the crap here. I am happy to see mbstring in PHP! I have
used it too, when I needed multibyte support.
James,
Let's stay consistent here. Your opinion changes more than Microsoft's .NET
strategy... In your original message you stated that you wanted to
remove
As I see it, PHP was designed with speed and simplicity in
mind. Having the
burden of a large number of extra modules compiled in by default doesn't
help, and deviates from this path.
No, you can always disable those extensions. The default extensions were
*voted* in for a reason.
On Mon, 2 Sep 2002, James Cox wrote:
JC Still, I think it makes more sense to enable, not disable. What extensions are
enabled by default anyhow? I am not aware of a list. Perhaps that's why i get odd
errors when working with php, because there are extensions i didn't expect built in.
On Mon, 2 Sep 2002, James Cox wrote:
JC Still, I think it makes more sense to enable, not disable.
What extensions are enabled by default anyhow? I am not aware of
a list. Perhaps that's why i get odd errors when working with
php, because there are extensions i didn't expect built in.
On Mon, 2 Sep 2002, James Cox wrote:
JC On Mon, 2 Sep 2002, James Cox wrote:
JC
JC JC Still, I think it makes more sense to enable, not disable.
JC What extensions are enabled by default anyhow? I am not aware of
JC a list. Perhaps that's why i get odd errors when working with
JC php,
On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:
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.
I'll agree to that as well. +1 on removing --with-mysql as a default.
Although realize I'm also +1 on
At 22:52 02/09/2002, Dan Kalowsky wrote:
On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:
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.
I'll agree to that as well. +1 on removing --with-mysql as a
At 22:52 02/09/2002, Dan Kalowsky wrote:
On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:
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.
I'll agree to that as well. +1 on removing
At 23:21 02/09/2002, James Cox wrote:
Nice to see you argue that one so eloquently...
I have in the past, numerous times. I don't think I or anybody else should
have to repeat themselves like broken records, you can look it up in the
archives.
Zeev
--
PHP Development Mailing List
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Monday 02 September 2002 04:16 pm, Zeev Suraski wrote:
At 22:52 02/09/2002, Dan Kalowsky wrote:
On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:
If we should reduce number of modules built by default, 1st
module should be MySQL. Removing MySQL does
-Original Message-
From: Dan Kalowsky [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 02, 2002 9:53 PM
To: Yasuo Ohgaki
Cc: PHP Development Mailing list
Subject: Re: [PHP-DEV] mbstring
On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:
If we should reduce number of modules built
On Tue, Sep 03, 2002 at 06:06:29AM +0200, Sebastian Nohn wrote :
Well... What about an _optional_ curses based, linux-kernel-like make
menuconfig?
+--+
| - Extensions |
| [x] mySQL
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
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
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 http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
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!
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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 ) ==
1 - 100 of 114 matches
Mail list logo
