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.
----- Original Message -----
> From: "Darryl L. Pierce" <dpie...@redhat.com>
> To: proton@qpid.apache.org
> Sent: Friday, August 24, 2012 9:38:14 AM
> Subject: Re: pn_message_save_data interesting problem...
>
> On Thu, Aug 23, 2012 at 05:39:02PM -0400, Rafael Schloming wrote:
> > On Thu, Aug 23, 2012 at 5:06 PM, Darryl L. Pierce
> > <dpie...@redhat.com>wrote:
> >
> > > On Thu, Aug 23, 2012 at 04:02:09PM -0400, Rafael Schloming wrote:
> > > > I'm a little confused by what you're trying to do with the
> > > > wrapper. This
> > > is
> > > > what I have for the wrapper in my ruby.i:
> > > >
> > > > int pn_message_save(pn_message_t *msg, char *OUTPUT, size_t
> > > *OUTPUT_SIZE);
> > > > %ignore pn_message_save;
> > >
> > > With the above the error happens at 65 characters. I took out my
> > > wrapper
> > > and ran the test again and it crashes at 65 characters every
> > > time.
> > >
> >
> > Can you post the test snippet so I can try?
>
> If you track my "Ruby-language-APIs" branch on github[1], and run the
> following in the ruby directory with
>
> ruby -I $RUBYLIB -I lib test
>
> you should see the output.
>
> ---8<[snip]---
> #!/usr/bin/env ruby
>
> require 'qpid_proton'
>
> msg = Qpid::Proton.create_message
> Qpid::Proton.set_message_format(msg, Qpid::Proton::Format::TEXT)
> length = 1
>
> puts "The message format is #{Qpid::Proton.get_message_format(msg)}."
>
> loop do
> data = (0...length).map{ ('a'..'z').to_a[rand(26)] }.join
>
> puts "Testing data at #{length} characters."
>
> Qpid::Proton.set_message_data(msg, data)
>
> returned = Qpid::Proton.get_message_data(msg)[1]
>
> puts "Comparing:\n#{data}\n#{returned}\n"
> puts "Do they match? #{(data == returned) ? 'Yes' : 'No'}"
>
> break unless (data == returned)
>
> Qpid::Proton.clear_message(msg)
>
> # length = 0 if length == 128
>
> length += 1
>
> end
>
> puts "We stopped at #{length} characters."
> ---8<[snip]---
>
> > > > I believe this is all that is necessary since the standard
> > > > typemaps
> > > should
> > > > pick up on OUTPUT and OUTPUT_SIZE and just do the right thing.
> > >
> > > What I would like to see in the dynamic languages for this is to
> > > not
> > > even have to specify the size for the output buffer; i.e., just
> > > call:
> > >
> > > Qpid::Proton.get_message_data(msg)
> > >
> > > and get the data back as one lump.
> > >
> >
> > Ah, in that case I think you want to use ALLOC_OUTPUT and
> > ALLOC_SIZE. Your
> > wrapper will need to be a little bit smarter though. There is no
> > way to
> > know in advance how much space it will take to encode the message
> > in a
> > given format, so the wrapper will have to pick an initial size and
> > then
> > keep on doubling until it fits.
> >
> > Here is an example of the ALLOC stuff. Obviously the wrapper would
> > need to
> > be different.
> >
> > %rename(pn_delivery_tag) wrap_pn_delivery_tag;
> > %inline %{
> > void wrap_pn_delivery_tag(pn_delivery_t *delivery, char
> > **ALLOC_OUTPUT,
> > size_t *ALLOC_SIZE) {
> > pn_delivery_tag_t tag = pn_delivery_tag(delivery);
> > *ALLOC_OUTPUT = malloc(tag.size);
> > *ALLOC_SIZE = tag.size;
> > memcpy(*ALLOC_OUTPUT, tag.bytes, tag.size);
> > }
> > %}
> > %ignore pn_delivery_tag;
> >
> > The swig chapter on C string handle is a good reference for this
> > stuff.
> > There might be some other macros there that are useful:
> >
> > http://www.swig.org/Doc2.0/SWIGDocumentation.html#Library_nn8
>
> Okay, I'll take a different approach to this one.
>
> > > Agreed. Also, we should make sure to remove having the individual
> > > languages include them relatively (i.e., %include "../cproton.i")
> > > and
> > > instead place the shared files in the include directory.
> > >
> >
> > +1
>
> I'll send out a patch for this today.
>
> --
> 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/
>
>
