[PHP-DEV] patch for trivial ZE2 leaks

I found memleaks in the current HEAD. A Patch for this issue attached. $ php -r "class foo {}" /home/koizumi/src/php5/Zend/zend_hash.c(198) : Freeing 0x400C1034 (64 bytes), s cript=- /home/koizumi/src/php5/Zend/zend_hash.c(176) : Actual location (location was rel ayed) Last leak repeated 5 times

[PHP-DEV] Re: [PHP-I18N] Help: Sablotron and Shift-jis

It works for me. See the attached example. Anyway, you don't have to crosspost your question to [EMAIL PROTECTED], which is for developing php internals and irrelevant for such user questions. Hope this helps Moriyoshi "Michel Sahyoun" <[EMAIL PROTECTED]> wrote: > Does anyone have an example

[PHP-DEV] [PATCH][ZE1] (resend) fix for bug #19943

Hi, Could anyone review this patch again? (I sent this one before the release of 4.3.0 actually.) The patch is against ZE1 and addresses memleaks that occur when brackets are used to access an element in a string like below. patch: http://marc.theaimsgroup.com/?l=php-dev&m=103654899426422&q=p3

Re: [PHP-DEV] Modifying PHP variables in C

You should use zval_ptr_dtor() to dispose the old value. Note the old value won't actually be freed as long as any reference to the variable is alive. for example, zval *ary1, *ary2; /* $ary1 = array(); */ ALLOC_INIT_ZVAL(ary1); array_init(ary1); /* $ary2 = array(); */ ALLOC_INIT_ZVAL(ary2);

Re: [PHP-DEV] Tie'ing variables

George Schlossnagle <[EMAIL PROTECTED]> wrote: > Having this sort of functionaility in general would be great. I know > you can affect this with objects via overload, but it is useful for > scalars and arrays and streams as well. It is pretty 'magical' though. Then how about allowing access t

Re: [PHP-DEV] patch for binary-safe strip_tags()

Oops, forgot to attach it... Moriyoshi On Tue, Feb 25, 2003 at 03:14:58AM +0900, Moriyoshi Koizumi wrote: > Hi, > > Attached is the patch for binary-safe strip_tags(). > Although it doesn't appear to be harmful anyhow, I think it needs > review since it modifies rather sens

[PHP-DEV] patch for binary-safe strip_tags()

Hi, Attached is the patch for binary-safe strip_tags(). Although it doesn't appear to be harmful anyhow, I think it needs review since it modifies rather sensitive part. Any objections? Moriyoshi -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/un

Re: [PHP-DEV] CVS Account Request: daggilli

Please make your request for a cvs account at http://www.php.net/cvs-php.php. (Not here) Moriyoshi David Gillies <[EMAIL PROTECTED]> wrote: > > Ignore previous subject line, username request is > daggilli > > --- David Gillies <[EMAIL PROTECTED]> wrote: > > I'd like to request CVS access to th

Re: [PHP-DEV] Contributing to PHP - how?

David Gillies <[EMAIL PROTECTED]> wrote: > At present all I have is a tiny module that groks > tzfile(5) files to get you historical offsets from > UTC, and another one that exposes about 80 or so As for tzfile module, probably Pierre wants some sort of tzinfo parser in his extension. Better off

[PHP-DEV] [PATCH] (resend) fix for bug #21600 and #22231

Hi, Could anyone who has ZE karma review this patch again? Thanks, Moriyoshi Index: Zend/zend_execute.c === RCS file: /repository/Zend/zend_execute.c,v retrieving revision 1.316.2.3 diff -u -r1.316.2.3 zend_execute.c --- Zend/zend_

Re: [PHP-DEV] CLI & long options

[EMAIL PROTECTED] (Marcus Börger) wrote: > Hi, > > the patch below allows long option names such as "--version" and "--help" > what eases the use of php especially when used on the command line. > And it fixes the problem with duplicate error messages if arguments to > command line are erroneous.

Re: [PHP-DEV] writing test cases

xplicitely commit the tests to that branch they won't be there. HEAD is PHP5. > there's no need for comparing versions or whatever except if you want to make > one test work differently for both php versions. > > harald > > "Moriyoshi Koizumi" <[

Re: [PHP-DEV] writing test cases

Kai Schröder <[EMAIL PROTECTED]> wrote: > In addition to my yesterday's mail I've found a new broken test: > tests/lang/bug21961.phpt Fixed. Thanks for the notification. Moriyoshi -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] please apply to PHP_4_3 branch: servlet build fix

Hi, Where's the patch? Perhaps the attachment was eliminated by the list program. Try suffixing it with ".txt" or inlining it. Thanks Moriyoshi Giuseppe Tanzilli - CSF <[EMAIL PROTECTED]> wrote: > hi, > committed some fixes to build the servlet sapi, > but have no permission to commit this sm

Re: [PHP-DEV] Question on bug list

[EMAIL PROTECTED] (Marcus Börger) wrote: > Wouldn't it be nice if one could attach himself to a bug and receive an email > on every new message to that bug? > > And then how am i informed about new bugs? Is there a mailing list for that? > Currently i read the bug-summary-list.. I was thinking o

Re: [PHP-DEV] deep compare: nesting level too deep

On Sat, Jan 25, 2003 at 01:00:53AM +0100, Vaclav Dvorak wrote: > When I try to compare two "child" objects, PHP says: "Fatal error: > Nesting level too deep - recursive dependency?". Well, yes, it _is_ a > recursive dependency, but I don't see why PHP could not compare those > objects anyway? Is

Re: [PHP-DEV] foreach nastiness with references (bug #21702)

On Wed, Jan 22, 2003 at 04:12:18PM +0100, Vaclav Dvorak wrote: > Moriyoshi Koizumi wrote: > >I tried to answer this question in the bug report page. > [...] > >1) Each time before entering a foreach loop, php first tries to make a > >copy of > > the array being i

Re: [PHP-DEV] foreach nastiness with references (bug #21702)

Just FYI, here's a relevant commit made by Andi two years ago: http://cvs.php.net/diff.php/Zend/zend_execute.c?r1=1.222&r2=1.223&ty=h Moriyoshi "John Coggeshall" <[EMAIL PROTECTED]> wrote: > Ah, I understand now... This perhaps in a documentation problem then > after all, as there is no way to

Re: [PHP-DEV] foreach nastiness with references (bug #21702)

Hi, > $a = array(1,2,3); > #$r =& $a; > echo "current before foreach: " . current($a) . "\n"; > foreach($a as $b) { > echo "- value in cycle: " . $b . "\n"; > echo "-- current in cycle: " . current($a) . "\n"; > } > echo "current before foreach: " . current($a) . "\n"; > ?> > > Try it,

Re: [PHP-DEV] request data filter

It looks like a mess indeed, and there seems a thought that encoding conversion and variable registration should be separated into two phases. However doing so doesn't make sense because some of multibyte characters contains "[", "]", or "=" and they cannot be handled properly in the ordinary query

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

On Wed, Jan 15, 2003 at 06:36:20PM +0100, Harald Radi wrote: > iirc the reason why i changed it to unsigned was that actually the zend engine > treated it as unsigned everywhere but in that particular struct. i also > remember that i discussed that with andi and that he agreed to change this in > t

[PHP-DEV] [PATCH] fix for bug #21600

Attached is a patch for bug #21600. This problem is caused by unnecessary zval destruction performed when trying to assign a value that is originated from the same zval. Moriyoshi Index: Zend/zend_execute.c === RCS file: /repository

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

On Sun, Jan 12, 2003 at 12:12:39AM +0100, Sascha Schumann wrote: > As many past security advisories have shown, signedness > issues are the frequent cause for severe vulnerabilities in > software (recent examples include MySQL, OpenBSD kernel). Actually codes like below produce vulnerb

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

On Sat, Jan 11, 2003 at 11:59:49PM +0100, Sascha Schumann wrote: > > Does this mean we now always need to cast the result of the > > Z_STRLEN_P/Z_STRLEN_PP macros to int? That seems pretty annoying and not to > > producing ugly code. > > Certainly not. > > What kind of warnings was the co

Re: [PHP-DEV] Re: php4 /ext/standard file.c formatted_print.c

On Sat, Jan 11, 2003 at 05:56:23PM -0500, Ilia A. wrote: > On January 11, 2003 06:03 pm, Moriyoshi Koizumi wrote: > > On Sat, Jan 11, 2003 at 11:38:20PM +0100, [EMAIL PROTECTED] wrote: > > > Sorry but just a thought, in that line: > > > > > > if (argc > 1 &am

[PHP-DEV] Stream filters, converters and i18n.

Hi, I renewed the base64 filter yesterday to use newly implemented converter facility. This enables you to apply arbitrary filter operations to a writer and a reader respectively. But this also makes some complexity for users. How can we select these operations? Currently there seems to be just t

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard filters.c

Hi, On Tue, Jan 07, 2003 at 12:12:15PM -0800, Sara Golemon wrote: > Speaking of filter "string.base64" I have an issue with its parity. > > string.base64 will encode on write and decode on read... What if the user > wants the other way round? Is the expected behavior even obvious from the > name

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard filters.c

On Tue, Jan 07, 2003 at 08:46:09AM -0500, Andrei Zmievski wrote: > Couldn't you have used parts of ext/standard/base64.c here instead of > duplicating code? At first I thought of using php_base64_encode() and php_base64_decode() rather than reimplementing them. But because those functions are desi

Re: [PHP-DEV] string functions

I mentioned a similar inconsistency of range() parameters in the past and pointed out a possible BC breaking issue raised by your recent patch on array.c in HEAD. http://news.php.net/article.php?group=php.dev&article=91489 http://news.php.net/article.php?group=php.dev&article=92910 I meant no tri

[PHP-DEV] new iconv functions

Hi, I've just committed a patch which I mentioned in the previous mail. http://news.php.net/article.php?group=php.dev&article=92027 But I'm not sure if the function naming really conforms to the standard. If it annoys you, please let me know. Regards, Moriyoshi -- PHP Development Mailing Li

[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c /ext/standard/tests/array range.phpt

> Added support for float values and handling of numeric values being passed > as strings. Is this change likely to cause backwards compatibility issues? Moriyoshi -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /ext/standard array.c

Andrei Zmievski <[EMAIL PROTECTED]> wrote: > On Fri, 27 Dec 2002, Moriyoshi Koizumi wrote: > > Andrei Zmievski wrote: > > > > >Was this fix entirely necessary? It didn't seems like a showstopper bug. > > > > > > > > First, I apo

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4(PHP_4_3) /ext/standard array.c

it's a bug that causes segfault in usual usage. Moriyoshi On Wed, 25 Dec 2002, Moriyoshi Koizumi wrote: moriyoshi Wed Dec 25 15:00:14 2002 EDT Modified files: (Branch: PHP_4_3) /php4/ext/standard array.c Log: Fixed bug #21182 Index: php4/ext/standard/array.c d

Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure

"Edin Kadribasic" <[EMAIL PROTECTED]> wrote: > > Isn't the solution as "simple" as changing the #ifdef to include > > COMPILE_DL_ZLIB in the checks, or is this another situation where the > > zlib extension should be compiled into the distribution itself? > > > > Is there a problem with doing that

Re: [PHP-DEV] Re: #21139 [Ctl]: zlib.output_compression + windows failure

As far as I've looked into this problem, absense of "Content-Encoding" field in the response headers, apparently a side effect of the patch of rev 1.138 for main/SAPI.c, results in un-inflated output on the clients. Because the patch was designed only to work with statically linked zlib module,

Re: [PHP-DEV] RC4: ground rules

Hi, > > > Possible values are: > > > > > > - php_auth_exposure=user > > > Only PHP_AUTH_USER is exposed. > > > > > > - php_auth_exposure=pw > > > Only PHP_AUTH_PW is exposed > > > > > > - php_auth_exposure=user,pw > > > Both PHP_AUTH_USER and PHP_AUTH_PW are exposeed > > > > Moriyoshi, have

Re: [PHP-DEV] RC4: ground rules

complicated to be included in 4.3.0 release too, and there is still room for the discussion whether to prepare a special ini entry like "php_auth_exposure" for those variables. Moriyoshi > On Sat, 21 Dec 2002, Moriyoshi Koizumi wrote: > > Ohh, it seems we have

Re: [PHP-DEV] RC4: ground rules

Ohh, it seems we have been working on the same patch simultaneously :) Attached is my version of fix for bug #20441, which adopts a new ini entry "php_auth_exposure" so that administrators can selectively expose auth information to the clients regardless of safe_mode settings. Possible values a

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /sapi/cli php_cli.c

Andi Gutmans <[EMAIL PROTECTED]> wrote: > At 01:28 PM 12/19/2002 +, Wez Furlong wrote: > >Actually, it does seem valid to me; streams based on FILE* are not > >registered in the persistent list, so does it make sense to have the > >associated resources registered as persistent resources when t

Re: [PHP-DEV] Re: #20993 [Ver]:Elementvaluechangeswithoutasking

Melvyn Sopacua <[EMAIL PROTECTED]> wrote: --snip > > > OK so that's a deep copy. As much as I understand the motivation I don't > > > think this should be done. It'll slow down lots of things in PHP. I think > > > this should be solved by documentation. > > > >Yes, according to my trivial benchmar

Re: [PHP-DEV] Re: #20993 [Ver]: Elementvaluechangeswithoutasking

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 assi

Re: [PHP-DEV] Re: #20993 [Ver]: Element valuechangeswithoutasking

increments the refcount for non-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: > > > > > $a = 0; > > $a = &$a;

Re: [PHP-DEV] Re: #20993 [Ver]: Element valuechangeswithoutasking

--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

Re: [PHP-DEV] uniqid

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

Re: [PHP-DEV] Re: #20993 [Ver]: Element value changeswithoutasking

Oops, the patch was wrong as the runtime occationally segfaults in a case like: 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 [After patching] 1: 0.273811 2: 0.141965 3: 0.699429

Re: [PHP-DEV] Re: #20993 [Ver]: Element value changes withoutasking

> >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

Re: [PHP-DEV] Re: #20993 [Ver]: Element value changes without asking

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 PROTEC

[PHP-DEV] Re: #20993 [Ver]: Element value changes without asking

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. = 0) { $bar[$i] = &$foo[$i]; } $foo_ref = &$foo; $bar_ref = &$bar; $foo_copy = $foo; $bar_copy = $ba

Re: [PHP-DEV] Bug #20887 (Two separate issues)

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 en

Re: [PHP-DEV] Bug #20887 (Two separate issues)

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

Re: [PHP-DEV] Critical Bug #20887

ecause it was preciselly because 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"

Re: [PHP-DEV] Critical Bug #20887

> 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 fe

Re: [PHP-DEV] Critical Bug #20887

inary 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 2

Re: [PHP-DEV] Critical Bug #20887

ini_search_path, paths_separator); 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. > > -

Re: [PHP-DEV] Critical Bug #20887

+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

[PHP-DEV] Placebo for bug #20539

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 ===

[PHP-DEV] Patch for Bug #20681: object lookup with array_search()

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

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

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

[PHP-DEV] New iconv functions being introduced

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 appen

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

--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

Re: [PHP-DEV] Bug #20460 (Feature Request)

Sterling Hughes <[EMAIL PROTECTED]> wrote: > > > err. it didn't need a reimplementation, i fixed it, it works fine in cvs. > > > > Then, > > > > > $buf = "123 456 \0 567" > > sscanf($buf, "%d%d%s%d", $a, $b, $c, $d); > > var_dump($a, $b, $c, $d); > > ?> > > > > How about this? > > > > T

Re: [PHP-DEV] Bug #20460 (Feature Request)

> err. it didn't need a reimplementation, i fixed it, it works fine in cvs. Then, How about this? The result was the same as for fscanf. Moriyoshi > > -Sterling > > > > Moriyoshi > > > > > Derick > > > > > > -- > > > > > > --

Re: [PHP-DEV] Bug #20460 (Feature Request)

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: > > >

Re: [PHP-DEV] php bugs (Chinese word display problem)-help

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

Re: [PHP-DEV] RFC: V API Ä

mail you a copy immediately. | +------+ | Author: Moriyoshi Koizumi <[EMAIL PROTECTED]>| +--+ */ /* $Id$ */ #ifndef _PHP_MB_API_H #define _PHP_MB_API_H #

[PHP-DEV] Re: RFC: .....

Sorry, I failed to post the previous mail to the right list. Just ignore it. Moriyoshi -- PHP Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] RFC: $B?7(B API $BAp0F(B

$B>.@t$G$9!#(B (B $BK\2H$NJ}$H!"(Bsf.jp $B$NJ}$N%=!<%9$r8+Hf$Y$D$D!"(B (Bmbstring API $B$r9M$($F$_$^$7$?!#E:IU$N%U%!%$%k$r$4Mw2<$5$$!#(B $B$3$l$r$?$?$-Bf$K:G=*E*$J(B API $B$r7hDj$7N>e$2$k0lJ}$G!"%G%P%C%0$,$7$E$i$/$9$k$HH=CG$7$?$?$a$G$9!#(B (B $B$"$H$O!"%(%i!C<$K$J$C$F$7$^$C$F$$$^$9

Re: [PHP-DEV] [PATCH] Redirect on Error (fwd)

> > - Sascha > > -- 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]>, >

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

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 > > spri

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

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 script

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

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 s

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c

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

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard array.c

f the user (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

Re: [PHP-DEV] Patch for range()

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'v

[PHP-DEV] Patch for range()

Hi, I've just found range() behaves unexpectedly in some special cases. For instance, please try the following script. 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 positive char value during the loop. Th

Re: [PHP-DEV] Patch for gd.c

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 20

[PHP-DEV] Patch for gd.c

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: ext/gd/g

Re: [PHP-DEV] htmlspecialchars iso-2022-jp patch

ied 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 you make a patch diff'ed against the lat

Re: [PHP-DEV] Patch for bug #19566

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 h

Re: [PHP-DEV] Patch for bug #19566

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

Re: [PHP-DEV] Patch for bug #19566

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 >

Re: [PHP-DEV] mime_magic segfaults

m. > > Ilia > > On November 14, 2002 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

[PHP-DEV] mime_magic segfaults

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 /home/koizumi/src/p

Re: [PHP-DEV] mbstring and 4.3.0

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 w

Re: [PHP-DEV] mbstring and 4.3.0

--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 > > -- > > -

Re: [PHP-DEV] mbstring and 4.3.0

t; <[EMAIL 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 brainde

Re: [PHP-DEV] mbstring and 4.3.0

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: &g

Re: [PHP-DEV] mbstring and 4.3.0

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 sev

Re: [PHP-DEV] htmlspecialchars iso-2022-jp patch

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

Re: [PHP-DEV] Getting escape chars through the parser without warnings

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 result

Re: [PHP-DEV] htmlspecialchars iso-2022-jp patch

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 >

Re: [PHP-DEV] htmlspecialchars iso-2022-jp patch

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. >

Re: [PHP-DEV] ZEND_ADD_STRING patch

--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; > } > > > -{LABEL_OR_WHITESPACE} { > +{LABEL} { > zend_copy_value(zendlval, yytext, yyleng); > zen

Re: [PHP-DEV] [PATCH] Fix for bug #19566

(args); > > > } > > > - va_end(args); > > > > > > HASH_UNPROTECT_RECURSION(ht); > > > } > > > @@ -1163,7 +1163,7 @@ > > > > > > ZEND_API int zend_hash_compare(HashTable *ht1, HashTable *ht2, > > > compare

Re: [PHP-DEV] [PATCH] Fix for bug #19566

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 corre

Re: [PHP-DEV] [PATCH] Fix for bug #19566

e 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 wrote: > >See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html > >This appears to imply that va_start() can be u

Re: [PHP-DEV] Re: mbstring and 4.3.0

> 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 G

Re: [PHP-DEV] [PATCH] Fix for bug #19566

; hash_key.nKeyLength = p->nKeyLength; > hash_key.h = p->h; > @@ -733,8 +737,8 @@ > } else { > p = p->pListNext; > } > + va_end(args); > } > -

Re: [PHP-DEV] mbstring and 4.3.0

--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 wan

[PHP-DEV] [PATCH] Fix for bug #19566

Hi, The attached patch is a probable fix for bug #19566. I guess the bug is that va_list is not properly initialized before each callback function call. I've tested it in PPC linux, and it works fine. Regards, Moriyoshi Index: zend_hash.c ==

  1   2   >