On 09/10/2014 04:35 PM, Marko Tiikkaja wrote:
> On 9/10/14 1:38 PM, Heikki Linnakangas wrote:
>> On 09/10/2014 02:26 PM, Marko Tiikkaja wrote:
>>> So I wonder if I shouldn't try and instead keep the
>>> code closer to what it is in HEAD right now; I could call
>>> enlargeStringInfo() first, then hand out a pointer to b64_encode (or
>>> b64_decode()) and finally increment StringInfoData.len by how much was
>>> actually written. That would keep the code changes a lot smaller, too.
>>
>> Yeah, that sounds reasonable.
>
> OK, I've attemped to do that in the attached. I'm pretty sure I didn't
> get all of the overflows right, so someone should probably take a really
> good look at it. (I'm not too confident the original code got them
> right either, but whatever).
Looks good, committed. It might've been a tad more efficient to return
the StringInfo buffer directly from pgp_armor/dearmor, and avoid the
extra palloc and memcpy, but this isn't performance critical enough for
it to really matter.
Are you planning to post the main patch rebased on top of this soon? As
in the next day or two? Otherwise I'll mark this as "Returned with
feedback" for this commitfest.
- Heikki