Re: String encoding in extension API

Thanks Gustavo, it's fixed now. I've just another quick question about RETURN_STRINGL(). I'm returning an emalloc()-ed string and my understanding is that when the duplicate flag is set to false, there's no need to efree() the memory of the returned result. Is that correct? Cheers, -Behnam On Sun, May 26, 2013 at 6:30 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt>wrote: > On Sun, 26 May 2013 22:47:41 +0200, Behnam Esfahbod <behnam@zwnj.org> > wrote: > > I'm updating pecl/fribidi to use zend_parse_parameters() instead of the >> ancient zend_get_parameters() and I'm not sure what encoding expect from >> zpp() when I ask for a string value with non-ascii characters. Is there >> any conversion done mechanically? >> > > PHP strings have no encoded, they're basically just byte arrays. See the > manual: > http://php.net/manual/en/**language.types.string.php#** > > language.types.string.details<http://php.net/manual/en/language.types.string.php#language.types.string.details> > > > Also, when I call RETURN_STRINGL with some UTF-8 encoded data, I get a >> double-encoded string in my script. Again, what's the expected encoding >> for calling RETURN_STRINGL()? >> >> > I don't know what the problem is, but in any case RETURN_STRINGL() is not > changing the data you're giving it any way. You're probably using the > fridibi library incorrectly. > > -- > Gustavo Lopes > -- Behnam Esfahbod | بهنام اسفهبد http://behnam.es/ GPG-FP: 3E7F B4B6 6F4C A8AB 9BB9 7520 5701 CA40 259E 0F8B