even in its win32 port.
Thanks,
Moriyoshi Koizumi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
it
expects some unnecessary trailing \0 characters.
Regards,
Moriyoshi Koizumi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Hello again,
I forgot to attach them.
Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
Hi,
This humble patch fixes the minor bug #16069 transliteration failure.
I think I'm supposed to do CC'ing it to the maintainers, but I don't know
who is responsible for iconv module because none of them
this will work.
Moriyoshi Koizumi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
(Forgot CCing)
Hi,
I've implemented a DNS resolver with fsockopen udp (and no special
tricks used).
It seems to work but for occasional infinite polling.
if interested, please visit sourceforge site http://phpresolver.sf.net/
FYI,
Moriyoshi Koizumi
Torsten Schlabach [EMAIL PROTECTED
with
php (and lots of packages out there) in general. Anyway these are not
directly relevant to --mbstr-enc-trans.
Excuse me if this is wrong, I'm rather new to mbstring :)
Moriyoshi Koizumi
Wez Furlong [EMAIL PROTECTED] wrote:
Hi Erica,
Personally, I would roll my own tarball/package
there?
Regards,
--
Moriyoshi Koizumi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Oh sorry I was slightly unconscious of what I did...
Thanks to Rasmus for the quick fix!
Moriyoshi Koizumi
Sebastian Bergmann [EMAIL PROTECTED] wrote:
c:\home\php\php4\ext\mbstring\php_mbregex.c(228): warning C4003:
Not enough parameters for macro 'RETVAL_STRING'
c:\home\php\php4
of commonly
accepted specification for the encoding(not about url-encoding) used in
url-embedded (namely I mean GET method) queries.
Regards,
Moriyoshi Koizumi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
of
mbstring.internal_encoding, rather than iso-8859-1, when the charset
parameter is not specified.
And although it is not fully confirmed, this patch is also expected to fix
the phpinfo() displaying problem in multibyte environments.
Any comments are welcome.
Moriyoshi Koizumi
Index: html.c
calls
php_escape_html_entities() with no charset information specified. Without
the patch, every character is treated as ISO-8859-1 even if a fetched
character is actually a mere first byte of a multibyte character.
Moriyoshi Koizumi
--
PHP Development Mailing List http://www.php.net
.
Moriyoshi Koizumi
Wez Furlong [EMAIL PROTECTED] wrote:
Search the archives for the discussion.
phpinfo could determine the charset as your patch does at the start,
and then pass the info in php_escape_html_entities.
Seems easy to me.
--Wez.
On 10/16/02, Moriyoshi Koizumi [EMAIL PROTECTED
Hello Wez,
IMO the current behaviour of mb_convert_case() with MB_CASE_TITLE looks
a bit strange as per Unicode specification.
--snip-- (cited from http://www.unicode.org/unicode/reports/tr21/)
S3. toTitlecase(X)
For each character C, find the preceding character B.
ignore any intervening
.
On Thu, 24 Oct 2002, Moriyoshi Koizumi wrote:
Hello Wez,
IMO the current behaviour of mb_convert_case() with MB_CASE_TITLE looks
a bit strange as per Unicode specification.
--snip-- (cited from http://www.unicode.org/unicode/reports/tr21/)
S3. toTitlecase(X)
For each character
This is not for me, it's the general idea that the test suite works
whatever stupid ini settings a user made. If tests fail because of this,
or the test suite doesn't work we need to fix the tests and the suite.
That's the intention behind it all.
This is not always the case... Some
That's what the --INI-- section in the test files are for. You can hard
code ini settings for your test there.
Okay, I'd just like to see how you think about it. Then, no problem :)
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit:
useful.
(ucdata is used by the openldap project).
--Wez.
On Thu, 24 Oct 2002, Moriyoshi Koizumi wrote:
Hi,
AFAIK, UCDATA itself only offers character conversion facilities, not
string conversion ones. Is it our job to discuss how to implement those
string conversion functions
resending...
Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
I've made a revised patch. I don't see there's no more BC problem around
it. Please review it.
PS: I finally ended my search without a hit on such a discussion: Could
you give me a pointer where that discussion took place
in UTF-8 and the image is
rendered by IE5.5 . Note that the font used to render the Japanese
characters are not Arial Unicode MS but MS PGothic. Hope it helps.
Moriyoshi Koizumi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
-dev, php-cvs and
php-i18n.
Moriyoshi Koizumi
Wez Furlong [EMAIL PROTECTED] wrote:
On 10/17/02, Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
Yep, as far as I read the archives, I haven't found any discussions on the
charset related backwards problems. So I wrote *exactly* about this
issue
. But we shouldn't rely on the automatic encoding detection too
much.
Moriyoshi Koizumi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
I missed the point... BTW that seems to have been fixed now.
Moriyoshi
Melvyn Sopacua [EMAIL PROTECTED] wrote:
At 04:04 10/22/2002 +0900, Moriyoshi Koizumi wrote:
./buildconf needed
?
[EMAIL PROTECTED] ~/cvs/php4
$ history
[...]
513 export MAKE=gmake
514 ./buildconf
./buildconf needed
Moriyoshi
Melvyn Sopacua [EMAIL PROTECTED] wrote:
Hi,
Current CVS doesn't compile for me, cause longopts isn't protected
with an #ifdef HAVE_GETOPT_LONG and an alternate approach.
/home/msopacua/cvs/php4/ext/standard/basic_functions.c: In function
`zif_getopt':
The only advantage putting everything in phpt is
is we can take a look at whole thing in one file.
Don't we have multiple windows or buffers? It's too
little advantage compare to have 2 files.
First I looked at your style, I think it was somewhat cool,
because then I wasn't able to run a
dependant) when we have default_charset ini setting.
It just sounds more logical to me to use SG(default_charset) for the
default charset of htmlentities(). Your thoughts?
Edin
- Original Message -
From: Moriyoshi Koizumi [EMAIL PROTECTED]
To: Wez Furlong [EMAIL PROTECTED]
Cc: [EMAIL
+1
Moriyoshi
Derick Rethans [EMAIL PROTECTED] wrote:
Hello,
to make easier maintenance and checking possible I would suggest to name
our tests more appropriate:
Class: Name: Example:
Tests for bugs bugbugid.phptbug17123.phpt
Hi,
Can I see the log (bug16069.out) and the output of phpinfo() generated by
the cli binary he built?
I guess ICONV library identification was failed since FreeBSD version was
also installed, and then preferred to libiconv by configure.
Anyway I cannot confirm it now as I have no
Hi,
I think the test case /tests/strings/003.phpt should be placed in
/ext/standard/tests/strings and renamed as htmlentities.phpt .
Are there any objections?
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
I've simplified the test code, and I still have got a strange result
with ZE2.
--
?php
function foo() {
static $value;
if (!isset($value)) {
$value = rand(0,100);
}
==
At 21:51 30.10.2002, Moriyoshi Koizumi wrote:
I've simplified the test code, and I still have got a strange result
with ZE2.
--
?php
function foo() {
static $value
Just FYI: Recently I found that the result of following code differs by
ereg_replace() and preg_replace().
?php
$str = abcde;
var_dump(ereg_replace(, a, $str));
var_dump(preg_replace(//, a, $str));
?
Hmm... there might be other trivial BC problems apart from regex spec
differences, however the
Feel free :-)
- Stig
Thanks, Stig!
Then I'm adding to EXTENSIONS a entry for iconv module.
Any objections...?
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Forgot to send CC to dev list...
=
FAILED TEST SUMMARY
-
mb_strtoupper() / mb_strtolower() [ext/mbstring/tests/casefold.phpt]
mb_convert_encoding()
+1
Moriyoshi
[EMAIL PROTECTED] (Marcus Boerger) wrote:
Maybe we should add those two settings also to the default overwrites
since you can easily fail all tests by this simple settings and mbstring
module as well as output buffering are checked elsewhere.
marcus
Index: run-tests.php
The attached patch is a fix for misbehaviour of
OnUpdate_zlib_output_compression. Without this patch, test cases always
fail complaining Cannot use both zlib.output_compression and
output_handler together!! when output_handler is used.
Any objections?
Moriyoshi
Index: zlib.c
This appears not a bug, but an expected behaviour for me.
Let's change it from Critial to Won't Fix or so on.
---
?php
$ragged = array();
for ($count = 0; $count 10; $count++) {
$ragged[$count] = $count;
$ragged[$count]['idx'] =
'.$count; is executed, the original zval
containing a string is converted to an array. During this conversion the
string value is not freed and the result is a memory leak.
Ilia
On November 5, 2002 01:45 pm, Moriyoshi Koizumi wrote:
This appears not a bug, but an expected behaviour for me
The attached patch may be a fix for that bug.
Hope it works.
Moriyoshi
Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
I looked into it, and I've found you really got a point.
---
?php
$ragged = array();
$ragged[0] = a;
$ragged[0][0] = array(1);
var_dump($ragged
Hmm, I'm afraid that I have to mention you a PECL module that seems very
similar to your module...
Check out this one:
http://cvs.php.net/cvs.php/pear/PECL/smbc
Moriyoshi
Martial Rioux [EMAIL PROTECTED] wrote:
Hi,
I Request CVS account to contribute a new extension base on smbclient from
---
Perhaps my patch was not sufficient... A revised patch is attached. Please
try this one, and if you like the patch, then commit it with extreme care
:)
Moriyoshi
On November 5, 2002 05:48 pm, Moriyoshi Koizumi wrote:
The attached patch may be a fix
. I've also ran the test suit after applying the patch and none of the
tests have been adversly affected, so it does not appear to break any old
functionality.
Ilia
On November 5, 2002 09:17 pm, Moriyoshi Koizumi wrote:
Perhaps my patch was not sufficient... A revised patch is attached
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.
--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
@@
} else {
p = p-pListNext;
}
+ va_end(args);
}
- va_end(args);
HASH_UNPROTECT_RECURSION(ht);
}
marcus
At 09:52 08.11.2002, Moriyoshi Koizumi wrote:
Hi,
The attached patch is a probable fix
PHP 4.3.0's Zend Engine also comes with SJIS awareness. It does not
make sense to have SJIS awareness without mbstring also.
(Need compile option to enable SJIS awareness)
In addition, we'll have to take in account all of the double byte encodings
in which second bytes of characters spans GL
before any access to the unnamed
arguments.
3 The va_start macro initializes ap for subsequent use by va_arg and va_end.
va_start (or va_copy) shall not be invoked again for the same ap without an
intervening invocation of va_end for the same ap.
(...)
At 10:47 08.11.2002, Moriyoshi Koizumi
08.11.2002, Moriyoshi Koizumi wrote:
Yep, the spec goes right. a corresponding va_end() dtor should be applied
to ap once ap has been initialized by a va_start().
IMO no va_end() is needed without a preceding va_start(), and it doesn't
matter if ap is used between va_start() and va_end().
BTW, could
,
compare_func_t compar, zend_bool ordered TSRMLS_DC)
{
- Bucket *p1, *p2;
+ Bucket *p1, *p2 = NULL /* fixes warning */;
int result;
void *pData2;
At 16:45 08.11.2002, Moriyoshi Koizumi wrote:
Yep, the spec goes right. a corresponding va_end() dtor
--snip
+fprintf(stderr, %s:%d\n, __FILE__,__LINE__);
What's this fprintf()? This seems to be put just for debugging purpose.
Moriyosh
return T_STRING;
}
-ST_DOUBLE_QUOTES,ST_BACKQUOTE,ST_HEREDOC{LABEL_OR_WHITESPACE} {
It would be better to try inlining your patch also.
I'm very interested in the patch.
Moriyoshi
Adrian Gartland [EMAIL PROTECTED] wrote:
Attached is a patch which allows iso-2022-jp (jis) encoded text to be
passed through htmlspecialchars when the character set is
set to ISO-2022-JP.
It
Could you make a patch diff'ed against the latest version of html.c in HEAD
branch? determine_charset() issue which you pointed out seems to have been
fixed already.
Moriyoshi
Adrian Gartland [EMAIL PROTECTED] wrote:
http://support.oregan.net/php/php_htmlspecialchars_iso_2022-jp.patch
On
Generally it's not considered to be a good idea to use iso-2022-jp
encoding in your script because the scanner doesn't accept control codes
in a string literal that is used to form shift sequences, and iso-2022-jp
encoded strings may contain escape characters '\', which causes unexpected
Thanks, I'll take a look at it.
Moriyoshi
Adrian Gartland [EMAIL PROTECTED] wrote:
New patch applied against the current php4-latest.tar.gz,
same location:
http://support.oregan.net/php/php_htmlspecialchars_iso_2022-jp.patch
On 11 Nov 02, Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
Could
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
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
PROTECTED] wrote:
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
--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
--
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
Hi,
I found a bug in mime_magic. If the module fails to read the magic file
specified by mime_magic.magicfile during the module initialisation, it
tries to put an error, and then segfaults.
Here's the backtrace.
#0 0x0813402b in sapi_send_headers (tsrm_ls=0x8277f68)
at
03:10 pm, Moriyoshi Koizumi wrote:
Hi,
I found a bug in mime_magic. If the module fails to read the magic file
specified by mime_magic.magicfile during the module initialisation, it
tries to put an error, and then segfaults.
Here's the backtrace.
#0 0x0813402b
Hmm, your patch is a bit less sexy because of replaced white spaces.
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
The following patch for bug #19566 is open but should make it into 4.3.
cvs -z3 -q diff zend_hash.c (in directory S:\php4-HEAD\Zend\)
Index: zend_hash.c
No, it's not committed yet.
Both Marcus and me doesn't have access to Zend module.
Moriyoshi
Andi Gutmans [EMAIL PROTECTED] wrote:
Wasn't this commited a while ago?
Andi
At 11:58 AM 11/15/2002 +0100, Marcus Börger wrote:
The following patch for bug #19566 is open but should make it into
Thanks.
Could you merge the patch into ZE1 also?
Moriyoshi
Andi Gutmans [EMAIL PROTECTED] wrote:
Commited.
Andi
At 11:22 PM 11/15/2002 +0900, Moriyoshi Koizumi wrote:
No, it's not committed yet.
Both Marcus and me doesn't have access to Zend module.
Moriyoshi
Andi Gutmans [EMAIL
-latest.tar.gz,
same location:
http://support.oregan.net/php/php_htmlspecialchars_iso_2022-jp.patch
On 11 Nov 02, Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
Could you make a patch diff'ed against the latest version of html.c in HEAD
branch? determine_charset() issue which you pointed out seems
Hi,
This tiny patch prevents the warnings when applying imagecolordeallocate()
on true colour values. I suppose this new behaviour would be more
consistent because we can use imagecolorallocate() with true colour images.
Then what do you guys think about this issue?
Moriyoshi
Index:
Thanks!
Moriyoshi
Rasmus Lerdorf [EMAIL PROTECTED] wrote:
I have committed this, sort of anyway. I moved the check up as there is
really no reason to go through and even try to do the deallocate on a
truecolour image.
-Rasmus
On Sat, 23 Nov 2002, Moriyoshi Koizumi wrote:
Hi
Hi,
I've just found range() behaves unexpectedly in some special cases.
For instance, please try the following script.
?php
echo count(range('a', 'z', 12));
?
will give 45 while it should return an array that consists of 3 elements.
That is because the counting may exceed the upper limit of
Thanks for the review.
Also I'll add a test for this function.
BTW how about renaming it to array_range() and adding an alias for BC?
Moriyoshi
Jon Parise [EMAIL PROTECTED] wrote:
On Sat, Nov 23, 2002 at 03:37:29PM +0900, Moriyoshi Koizumi wrote:
I've just found range() behaves
(Bcontributed notes says and its behaviour is also as unexpectable as the
(Bnumber of charset - encoding mappings out there.
(B
(BMoriyoshi
(B
(BJon Parise [EMAIL PROTECTED] wrote:
(B
(B On Sat, Nov 23, 2002 at 08:47:45PM +0900, Moriyoshi Koizumi wrote:
(B
(B Just a notice:
(B
(B
I think the step option which you added is quite useful in every case.
Why didn't you merge into the branch? there seems no BC problem about it.
Moriyoshi
On Sun, Nov 24, 2002 at 03:28:45AM +0900, Moriyoshi Koizumi wrote:
Hmm, since nothing is mentioned about the rule of character sequence
I'm a bit late here, with an example which probably sounds interesting;
that is a computer language which was actually developed in Japan as a
product mainly for educational use, which enables you to program in nearly
complete Japanese syntax. I thnik it's undoubtfully great, but I have
never
I almost agree with you, but please note that error message translation is
not always the simple thing because the word order varies by language.
For example,
Warning: Argument %1 to array_diff() is not an array in - on line %2
the above message should be translated into Japanese romaji
Ah my bad. It's totally beyond my expectation...
Then how about RTL languages? They need some bidi processing.
Moriyoshi
Sascha Schumann [EMAIL PROTECTED] wrote:
sprintf handles these cases easily.
Warning: Argument %1 to array_diff() is not an array in - on line %2
-- Forwarded message --
Date: Mon, 25 Nov 2002 23:31:08 +0100 (CET)
From: Sascha Schumann [EMAIL PROTECTED]
To: Moriyoshi Koizumi [EMAIL PROTECTED]
Cc: Alexander Wagner [EMAIL PROTECTED],
Sterling Hughes [EMAIL PROTECTED], Ilia A. [EMAIL PROTECTED],
[EMAIL PROTECTED
Sorry, I failed to post the previous mail to the right list.
Just ignore it.
Moriyoshi
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
. |
+--+
| Author: Moriyoshi Koizumi [EMAIL PROTECTED]|
+--+
*/
/* $Id$ */
#ifndef _PHP_MB_API_H
#define _PHP_MB_API_H
#include php.h
#if HAVE_MBSTRING
Hi, Samuel
As far as I know, CP936 characters which is commonly used in MS products
are basically not allowed to use in PHP scripts. You have to use UTF-8
encoding in such case.
Anyway, this is wrong list for this kind of question, so better ask this
at [EMAIL PROTECTED]
Regards,
Moriyoshi
Derick Rethans [EMAIL PROTECTED] wrote:
On Wed, 27 Nov 2002, Sara Pollita Golemon wrote:
User complains that maximum length of a line used by fscanf is too short
(he has lines 1600 chars). Looking at file.h I agree (it's only 512).
The user requested two options:
1) Add an
err. it didn't need a reimplementation, i fixed it, it works fine in cvs.
Then,
?php
$buf = 123 456 \0 567
sscanf($buf, %d%d%s%d, $a, $b, $c, $d);
var_dump($a, $b, $c, $d);
?
How about this?
The result was the same as for fscanf.
Moriyoshi
-Sterling
Moriyoshi
Derick
Sterling Hughes [EMAIL PROTECTED] wrote:
err. it didn't need a reimplementation, i fixed it, it works fine in cvs.
Then,
?php
$buf = 123 456 \0 567
sscanf($buf, %d%d%s%d, $a, $b, $c, $d);
var_dump($a, $b, $c, $d);
?
How about this?
The result was the same as
--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?
For
Hi,
I've implemented some string related functions that make use of iconv().
Following is the list of them.
=
- _php_iconv_appendl()
Converts the given string in the way specified by a conversion
descriptor and then
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
Hi,
I'm trying to make a slight change on array_search(), which allows object
lookup with array_search() in ZendEngine2.
I think this feature doesn't break backwards compatiblity.
If there seems no problem, I'll commit the patch and close that PR.
Moriyoshi
Index: ext/standard/array.c
Hi,
Attached is a patch against the PHP_4_3 branch which appears to fix the
bug #20539, while I haven't expected for this to be a cure at all. I guess
destruction order of constants and resources have something to do with
this issue.
Moriyoshi
Index: php_cli.c
+1 for applying this patch.
and attached is yet another fix as my suggestion.
(a bit dirty, and not tested enough).
Moriyoshi
Sara Golemon [EMAIL PROTECTED] wrote:
I THINK the patch below will fix critical bug #20887, but it's late and
I've had a long day so I havn't begun to make sure
);
278 }
279 strcat(php_ini_search_path, .);
280 }
281 #endif
Moriyoshi
Jani Taskinen [EMAIL PROTECTED] wrote:
But unfortunately neither of these fix the bug.
If there is php.ini in /, it's still used.
--Jani
On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote
tries to read that one as
mod_cgi tries to chdir to where the script is put.
I'm not sure, but this appears to imply some security issues?
Moriyoshi
Derick Rethans [EMAIL PROTECTED] wrote:
On Thu, 12 Dec 2002, Jani Taskinen wrote:
On Thu, 12 Dec 2002, Moriyoshi Koizumi wrote:
Hmm
At the time CLI was introduced I argued to remove . from php.ini
search path, but that was not accepted because some people
apparently use this feature for having different configurations for
different virtual hosts.
Therefore . was removed only from CLI's php.ini search path.
This feature
of cgi that CWD wasn't removed
from the php.ini search path. Have a look at the following thread:
http://www.zend.com/lists/php-dev/200202/msg01325.html
Edin
- Original Message -
From: Moriyoshi Koizumi [EMAIL PROTECTED]
To: Edin Kadribasic [EMAIL PROTECTED]
Cc: Derick Rethans
Hi,
The original complaint in bug 20887 was that the CLI version was picking
up ini files in the wrong places. The patch I suggested last night does
address that problem (albiet not correctly, see below).
??? The original report goes:
If /php.ini exists, that one is used no matter what
Note that the patche is still incomplete because it dismisses many *nix OS
out there other than SunOS, Linux, FreeBSD, OpenBSD and NetBSD.
Moriyoshi
Sara Golemon [EMAIL PROTECTED] wrote:
??? The original report goes:
If /php.ini exists, that one is used no matter what PHPRC env is set
It would be easy to resolve this problem if we were allowed to break
backwards compatibilities, as long as the results of following script can
be said to be expected.
?php
$foo = array(1, 2, 3);
$bar = array();
$i = count($foo);
while (--$i = 0) {
$bar[$i] = $foo[$i];
This is a pretty well known issue indeed.
I should have read the archive carefully.
Related reports:
http://bugs.php.net/bug.php?id=6417
http://bugs.php.net/bug.php?id=7412
http://bugs.php.net/bug.php?id=7515
http://bugs.php.net/bug.php?id=15025
Moriyoshi
Moriyoshi Koizumi [EMAIL PROTECTED
This is a pretty well known issue indeed.
I should have read the archive carefully.
Related reports:
http://bugs.php.net/bug.php?id=6417
http://bugs.php.net/bug.php?id=7412
http://bugs.php.net/bug.php?id=7515
http://bugs.php.net/bug.php?id=15025
I wouldn't like to call it 'well-known'.
Oops, the patch was wrong as the runtime occationally segfaults
in a case like:
?php
$a = 0;
$a = $a; /* is_ref=1, refcount=1 */
?
Attached is the revised patch. Please try it out.
And the result of a tiny benchmark follows:
[Before patching]
1: 0.263245
2: 0.142505
3: 0.328045
4: 0.137149
Hi,
[EMAIL PROTECTED] (Marcus Börger) wrote:
First: Uniqid test (tests/strings/001.phpt) failes for cygwin because
the time for gettimeofday() is only updated once per second.
I suggest we should change the test to use more entropy.
Second: We should consider more entropy being default
--snip
And the result of a tiny benchmark follows:
[Before patching]
1: 0.263245
2: 0.142505
3: 0.328045
4: 0.137149
[After patching]
1: 0.273811
2: 0.141965
3: 0.699429
4: 0.137010
What's 1,2,3 and 4?
Have a look at the attachment 'bm.php.txt'.
Moriyoshi
Moriyoshi
My
-referenced elements.
Moriyoshi
Andi
At 04:09 PM 12/15/2002 +0900, Moriyoshi Koizumi wrote:
Oops, the patch was wrong as the runtime occationally segfaults
in a case like:
?php
$a = 0;
$a = $a; /* is_ref=1, refcount=1 */
?
Attached is the revised patch. Please try it out
Andi Gutmans [EMAIL PROTECTED] wrote:
At 12:49 AM 12/17/2002 +0900, Moriyoshi Koizumi wrote:
Andi Gutmans [EMAIL PROTECTED] wrote:
I don't understand what you're doing here. Are you actually separating on
every assignment and doing a deep copy?
What I'm trying to do in my patch can
1 - 100 of 139 matches
Mail list logo
