On Fri, Aug 24, 2012 at 10:27:29AM -0400, Chuck Rolke wrote: > This sounds like a gratuitous trailing null. > Added nulls could be happening on all buffer sizes but don't cause an issue > until the power-of-2-size payload puts the null into territory that gets > checked for buffer overruns.
I think you're onto something there. Putting some debugging code into the wrapper, I'm seeing that at those points the data returns by pn_message_save is corrupted; i.e., on those specific lengths the data returns doesn't even remotely match. For example: [TEST AT 64 CHARACTERS] Testing data at 64 characters. Trying with a bufsize of 1024. rc=0 bufsize=64 *ALLOC_OUTPUT is 65 bytes. *ALLOC_OUTPUT == "vdzxprjepkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcgP" Exiting with a return code of 64 Comparing: vdzxprjepkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcg vdzxprjepkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcg Do they match? Yes [TEST AT 65 CHARACTERS] Testing data at 65 characters. Trying with a bufsize of 1024. rc=0 bufsize=65 *ALLOC_OUTPUT is 4 bytes. *ALLOC_OUTPUT == "�j� " Exiting with a return code of 65 Comparing: obinopuaxubdehrwmkqqxhitzcfroiqnzdoxjqcqvkgpwsdprryegwxluiheklaul �j� pkvgcfzdtzhdrkuambduahhjmhdczkcihuauedxzelgcjqlxfnhqpmcg Do they match? No As you can, at 64 bytes (and all lengths prior to it) the strings internal always match. But, at 65 bytes the result is those weird few characters and nothing even remotely like the string passed in previously. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Description: PGP signature