Here it is, in roscpp/src/libros, writeHeader
uint32_t msg_len = len + 4;
boost::shared_array<uint8_t> full_msg(new uint8_t[msg_len]);
memcpy(full_msg.get() + 4, buffer.get(), len);
*((uint32_t*)full_msg.get()) = len;
and onHeaderLengthRead:
uint32_t len = *((uint32_t*)buffer.get());
This type of code might create some trouble when run between x86 and arm
cpu. However, I could only track this bit of code in the UDP and service
loop, and I only checked that this code was there up to fuerte.
In my experience some time ago, I could listen to packet from a gumstix
(cturtle, compressed or raw video) from a x86 laptop (diamondback I think).
So this might actually be two different bugs...
Now, for people who wonder why I did not report this earlier: contributing
to ros_comm has not been very successful so far on my side, so I just keep
track of my patches until someone really needs them... (shared memory and
compressed transports out-of-the-box for all topics?)
Regards
On Wed, Nov 28, 2012 at 5:14 PM, Claudio Carbone <
cla_carbone@tiscali.it>wrote:
> Thank you Cedric,
>
> I'll wait for your info.
>
> Regards
> --
>
> *Eng. Claudio Carbone
> Embedded Systems Design***
> **
>
> P.IVA: 11688471009
> tel: +393809017424
> email: Send email
> <cla_carbone@tiscali.it>[image: My linkedin profile]<http://it.linkedin.com/in/embeddedesign/en>
>
> My Portfolio****
> [image: My portfolio site] <http://www.fusioncoredesign.it/>****
>
> **
> **
>
>
> On 28/11/12 17:09, Cedric Pradalier wrote:
>
> Hi,
>
> last time I checked, some of the deserialization code was actually
> endianness specific (if I'm not mistaken), in particular the length of the
> message... This could lead easily to a buffer overrun.
>
> I'll try to point out the little bit of code later today.
>
> Regards
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
>
--
Cedric Pradalier
(text/plain)