Re: base64_encode() memory issue

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 > >can confirm this. > > > >Happy holidays, > > > >Ron > > > >-- > >PHP Internals - PHP Runtime Development Mailing List > >To unsubscribe, visit: http://www.php.net/unsub.php