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
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:
amp;q=p3
snippet:
Regards,
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
(ary2);
array_init(ary2);
/* $ary1['key'] = 123; */
add_assoc_long_ex(ary1, "key", sizeof("key"), 123);
/* $ary2['key'] = 456; */
add_assoc_long_ex(ary2, "key", sizeof("key"), 456);
/* $ary1 = $ary2 */
zval_add_ref(ary2);
zval_ptr_dt
how about allowing access to object properties via square brackets
like ECMA-Script? Though this will definitely add much more complexity to
the Engine...
Moriyoshi
> George
>
> On Saturday, March 1, 2003, at 11:26 AM, Sterling Hughes wrote:
>
> > I was wondering if it m
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
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 <http://www.php.net/>
To unsubscribe, visit: http://
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:
> >
ion. Better off getting in touch with him.
http://news.php.net/article.php?group=php.dev&article=94275
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
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
nts to
> command line are erroneous.
>
> http://marcus-boerger/php/ext/cli-getopt.diff.txt
+1 from me if you are sure it doesn't break BC.
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
I got the same idea in the first place and so I didn't append SKIPIF
section. I simply don't know much about Windows testruns.
Moriyoshi
"Harald Radi" <[EMAIL PROTECTED]> wrote:
> that's not true guys, PHP4 is in the PHP_4_3 branch and if you don't
> e
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 <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
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 hav
;s point of view, I don't see that much need for "my
favourite bugs" because my MUA is just doing enough.
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
he object.
Are you trying it with ZE2? Compare those objects with "===" not "==".
You'll get the exact result you've expected to see, I suppose.
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
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
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
&g
by another, both are treated as "reference"
from then on. For example,
This script produces following output:
array(2) refcount(2){
["a"]=>
&string(1) "a" refcount(2)
["b"]=>
&string(1) "a" refcount(2)
}
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
be handled properly in the ordinary query parser. Therefore Rasmus's
sugestion sounds quite logical to me.
Moriyoshi
On Wed, Jan 15, 2003 at 04:52:58PM -0800, Rasmus Lerdorf wrote:
> In trying to implement a security policy I need to pass all user-supplied
> data (GET/POST/Cookie) t
the engine to bail out when the length exceeds the maximam
value of signed integer (or possibly signed short) like Sascha said,
more priority has to be taken on fixing the engine over the former because
it hardly seems the change has been known by the numerous extension
developers.
Moriyoshi
--
PHP
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
w produce vulnerble runtimes because
the length of string is expected to be a positive integer value...
int maxlen;
...
if ((int)Z_STRLEN_P(length) > maxlen) {
RETURN_FALSE;
}
memcpy(allocated_buf, Z_STRVAL_P(length), Z_STRLEN_P(length));
> Any objections?
No objection from me.
Mori
What kind of warnings was the compiler (which one?) issuing?
Please look at the win32/ZE2 compile log in http://snaps.php.net/
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
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
cision.
By the way, I find the converter is quite portable and also important
for i18n stuff, I'd like to make the converter independent to
the filter code. Any comments on this?
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
me to make my own handler, but I see it will
definitely end up in great inconsistency.
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
nctions are designed to
be used in string semantics while streams require a different facility
due to its statefulness, I couldn't use the existing implementation.
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
meant no tricks by is_numeric_string() were needed and
the passed string values should always be regarded as a single character,
just as it was.
Moriyoshi
On Sun, Jan 05, 2003 at 01:40:31PM -0500, Ilia A. wrote:
> While converting the functions inside string.c to the new parameter parsing
>
ttempts in the next call of the write op.
Is this just my fault that I should always limit chunk length within the range
of the given length? Or possible stream bugs?
Please try the attached patch and run the following script to reproduce the
problem.
Thanks,
Moriyoshi
Index: ext/standard
ndering why I should commit the patches in such order.
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
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 Devel
> 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 <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
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
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
ve checked your test build, and it works fine as for Apache-1.3.27.
But it still fails with Apache2... this seems another apache2filter
problem.
Anyway this solution sounds like a quickest and most reasonable way.
Moriyoshi
> Edin
>
> P.S. Make sure to remove extension=php_zlib.d
t should be reverted for now, unless
there is a better way to fulfill the requirement (see bug #16109).
BTW since when did I become a "output guy" ? :)
Moriyoshi
Wez Furlong <[EMAIL PROTECTED]> wrote:
> This needs one of you "output guys" to resolve it.
> Andre
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=u
Andrei Zmievski <[EMAIL PROTECTED]> wrote:
> Moriyoshi,
>
> I appreciate your effort here, but it seems that while this approach is
> more flexible, it is also bound to have more complicated. I have decided
> to apply Philip's patch for 4.3.0.
I think my patch is too
ble 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
Hope this helps.
Moriyoshi
Philip Olson <[EMAIL PROTECTED]> wrote:
>
> Att
and STDERR registered.
So can I commit the patch again?
Moriyoshi
> Andi
>
>
> >--Wez.
> >
> >On Wed, 18 Dec 2002, Andi Gutmans wrote:
> >
> > > I don't like these voodoo patches. I think if the stream is destroyed twice
> > > that should b
patch. It prints out notices in such cases.
--
Benchmark results (the script used for this test is the same as the one
attached in my previous mail)
[Unmodified]
1: 0.166993
2: 0.099101
3: 0.219380
4: 0.094828
[After applying the new patch]
1: 0.189953
2: 0.099915
3: 0.238101
4: 0.095103
--
Moriy
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
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;
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 proposal, was based on 2 things: fix or document. I'm sure
> >>
y idea for this?
> Fourth: We should split ./tests/strings/001.phpt. One for the string
> functions and one for uniqid().
+1
Moriyoshi
> marcus
>
>
> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
>
4: 0.137010
Moriyoshi
> My proposal, was based on 2 things: fix or document. I'm sure Zeev/Andi had a
> good reason not to always separate, and that probably is performance.
>
> IF this impacts overall performance very negatively, then maybe the better
> choice is to docume
tached patch should work.
> IF this can't be fixed short term, we surely could detect the statement and
> issue a warning?
AFAIK possible. We'll have to trade off performance against usability.
Moriyoshi
Index: zend_execute.c
===
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
#x27;; debug_zval_dump($bar_ref);
echo 'bar_copy: '; debug_zval_dump($bar_copy);
?>
Is this a kind of "Won't fix" thing?
Moriyoshi
[EMAIL PROTECTED] wrote:
> ID: 20993
> Updated by: [EMAIL PROTECTED]
> Reported By: [EMAIL PR
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, tha
"php" (inaccurate!
> Our CWD is ~ and ~/php does not exist) Neither my patch nor Moriyoshi's
> fixes this.
My patch would give the accurate location of the binary being executed
since it doesn't rely on argv[0].
Moriyoshi
--
PHP Development Mailing List <http://w
Thanks for the pointer. As far as I looked over the thread, which is not
so long as I expected, I don't feel there is that much need for including
CWD in php.ini search path. +1 for removing that feature.
Moriyoshi
"Edin Kadribasic" <[EMAIL PROTECTED]> wrote:
> No b
.ini search path.
This feature looks somewhat evil since it enables users to bypass the safe
mode restrictions enforced by the administrator, or am I missing
something?
Anyway, the following patch should make sense for #20887?
Moriyoshi
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
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.
>
> -
+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 lo
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_
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/s
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
http://www.voltex.jp/patches/iconv_functions-patch.diff.gz
But I'm not sure if these are really needed while mbstring offers the
same facility. So it would rather depend on the result of discussion
whether I commit this patch or not :)
Your comments will be greatly appreciated.
Moriyoshi
ose. Perhaps did you mean integration of mbstring into core part?
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 k
, $c, $d);
> > var_dump($a, $b, $c, $d);
> > ?>
> >
> > How about this?
> >
> > The result was the same as for fscanf.
> >
>
> Yes, but it didn't need a reimplementation as far as using arbitrary buffer
> sizes.
Right, I just missed a big point
> 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
>
>
> > M
hink this has the best overall return on it.
>
> I don't like us adding a new ini entry for this, I think we should try
> another option:
>
> 4) Make sure we can use fscanf on a dynamically sized buffer. This will
> definitely the hardest solution, but also the most b
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
> what's this? :)
Did you get interested?
Hmm, it went on like following...
p.s. please keep quiet on this for now though I guess you'll find a lot to
say about :)
Moriyoshi
- translated message begins here -
Hi,
I'm now planning on a new mbstring API as refe
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
$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
I have no idea on this issue now though I guess this is a problem of ISP
that I'm using.
Sorry for the inconvenience.
Moriyoshi
Sascha Schumann <[EMAIL PROTECTED]> wrote:
> Looks like some program in the chain erroneously appended
> @vckyb3.nw.wakwak.com.
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 a
e the order of
subjects.
This trivial example implies that sprintf() cannot be used for error
message reporting at all in this case, which may result in a mess.
Regards,
Moriyoshi
Alexander Wagner <[EMAIL PROTECTED]> wrote:
> On Monday 25 November 2002 21:55, Sascha Schumann wrote:
>
ave
never seen it become popular by now.
I guess part of the reason is that most of the folks there take it for
granted that they have to be familiar with English as well as the
behaviour of the computer.
Anyway, I'm +0 for the localization of messages.
Moriyoshi
Daniel Lorch <[EMAIL
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
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
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
loop.
The attached patch is a fix for this issue. I'll commit this if there are
no objections.
Moriyoshi
Index: ext/standard/array.c
===
RCS file: /repository/php4/ext/standard/array.c,v
retrieving revision 1.201
diff -u -r1.2
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
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
ow on.
BTW, your code doesn't seem to handle the string that might result in a
string longer than 256 bytes. IMO erealloc() is lacking somewhere. As for
the other part, I see no obvious problems.
Moriyoshi
"Adrian Gartland" <[EMAIL PROTECTED]> wrote:
> New patch appl
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
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 followi
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:
Thanks, it works.
Attacthed is a slightly modified version of Ilia's patch in consideration
of win32 build.
If there are no objections, I'll commit it.
Moriyoshi
"Ilia A." <[EMAIL PROTECTED]> wrote:
> Could you try the attached patch and see if it fixes the proble
172770 <_fini>,
rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xba8c)
at ../sysdeps/generic/libc-start.c:129
IMO php_error() should not be used in PHP_MINIT_FUNCTION. Any fix else?
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
uinea-pig since only a subset of users will have a
> need for mbsting and those that do can use the switch. Those that don't
> will not even notice that it's not enabled.
I think your words "only a subset of users" would be more accurate if i
--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
&
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.&quo
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
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
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
either by
mb_convert_encoding() or iconv() function whenever necessary. Or it is not
enough ?? :)
Moriyoshi
"Adrian Gartland" <[EMAIL PROTECTED]> wrote:
> When using iso-2022-jp encoded strings within the I have to
> resort to doing error_reporting = ~E_COMPILE_WARNI
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_htmlspecia
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
--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
var_args issue doesn't have much to do with the purpose of the patch. We
were perhaps just curious about the usage of va_start() and va_end().
And that warning reducer was later added by Marcus, so the first version
should look nice. What about it?
Moriyoshi
Andi Gutmans <[EMAIL P
done.
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Moriyoshi could you make a *.phpt file from the bug?
>
> Attached is a new diff tested already. It also fixes a compiler warning.
> Since i do not have Zend karma someone with karma should commit it
> or give me kar
ch if there seems no problem?
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Some comments on ISO9899 standard
> 7.15.1.3-2 Read between the lines: without va_end the behaviour is undefined.
> What ever that means i guess you have to call va_end and that requires
> va_start.
>
of characters spans GL area (\x20-\x7e), like cp936(a
MS variant of GB2312), cp949(ditto of KSC5601). Those encodings also need
such awareness.
Moriyoshi
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
See http://www.opengroup.org/onlinepubs/007908799/xsh/stdarg.h.html
This appears to imply that va_start() can be used more than twice.
And I don't think va_start() always has to be invoked.
Moriyoshi
[EMAIL PROTECTED] (Marcus Börger) wrote:
> I am not sure if va_start can be called tw
1 - 100 of 145 matches
Mail list logo
