A patch (I'm not familiar with the normal protocol) would simply be to
increase the allocated size by 1:
result = (unsigned char *)safe_emalloc(((length + 2) / 3) * 4, sizeof(char),
1);
would become
result = (unsigned char *)safe_emalloc(((length + 2) / 3) * 4 + 1,
sizeof(char), 1);
But I must add, I've only tried this function in a non-php environment in C
with malloc(). Maybe I'm just looking at it the wrong way in the case of
php, but in this specific environment I had (C, malloc() and not
safe_emalloc(), no php interpreting), the base64 encode function would
allocate 1 byte short of what it needed because of the \0 byte at the end of
the string. This at least happened as I tried to encode a 9 character long
string.
So maybe safe_emalloc() provides for this 1 byte and this whole post can be
ignored, otherwise I think someone with a little more knowledge about the
php engine should look into it.
Ron
"Andi Gutmans" <andi@zend.com> schreef in bericht
news:5.1.0.14.2.20041229174350.02ed81c0@localhost...
> Do you have a patch which you think should be applied? If not, can you
send
> a reproducing script (a short one). Maybe you want to run it through
> valgrind and see where the damage is done.
>
> Andi
>
> At 04:44 PM 12/28/2004 +0100, Ron Korving wrote:
> >Hi,
> >
> >I'm not sure how to test what I noticed, so I figured I would post this
here
> >and see if any of you could test it and see if I'm correct. When I test
this
> >in a non-PHP environment with malloc(), this does present a problem
however,
> >and when running segfaults randomly appear because of it.
> >
> >In base64.c, the string is closed with a \0 byte, but this one byte is
never
> >allocated. Since it's just 1 byte, this often happens without causing
> >trouble, but every once in a while it does cause a segfault. I hope
someone
