Hi Bernd,
On 01/29/2013 11:46 AM, Bernd Petrovitsch wrote:
> I didn't look into the source of strcat2() ATM but all pjlib string
> functions do not care about the allocation (and so they cannot possibly
> enlarge it - if it is actually possible at all).
>
please take a look at pj_strcat2. You'll notice, dst assumes it owns
the memory beyond the string it currently encapsulates.
In order to correct the semantical ambiguity of the word "grow" from
my previous posting on this topic, please understand: create a new
pj_str_t, thus the pj_pool_t, that will be the concatenation of both
strings and assign that new string to dst afterwards.
> So what happens is IMHO:
> - you create the attribute correct and successful (at least at that
> moment)
> - you append the base64 string (and it looks then correct) but the pool
> doesn't know that it should touch the space after
> mikey_attr->value.ptr+mikey_attr->value.slen (because you only
> pj_strdup2() "mikey " into and that reserves probably just 7 bytes
> or so).
> - on the next allocation from that pool and the subsequent write into
> it, the base64 string is plain simply overwritten.
>
> So better allocate enough space for "mikey " and the base64 string (and
> not only around 7 bytes ....).
>
How much space is enough space ;o)
BTW pj_strdup2 allocates exactly six bytes, while
pj_strdup2_with_null allocates seven in this case.
IMHO the proposed "void pj_strcat3(pj_pool_t*,pj_str_t*,const
char*)" solution leans more to the PJ library programming style.
Best Regards,
Alain Totouom
--
""
(o)(o)
_____o00o__(__)__o00o_____
1024D/A9F85A52 2000-01-18 Alain Totouom <totouom at gmx.de>
PGP Fingerprint DA180DF2 FBD25F67 0656452D E3A27531 A9F85A52
