Too funny. Ok so "word" in my reply was the wrong word but I did say you have corruption going on at these boundaries and an assert will help you diagnose. But don't mind me.
This is a classic and pretty common issue. William ----- Original Message ----- > 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/ > >
