Mikhail, On Fri, Apr 8, 2011 at 5:11 PM, Mikhail Titov <mlt@xxxxxx> wrote: > I guess the main point it should just work for x86 and certain ARM > architecture. Everything else doesn't matter, including efficiency, > especially if one side is already implemented in a particular way. > > Yes, structure packing is compiler-specific. In case of Visual C++ one uses > #pragma, but I feel like OP uses gcc in both cases. So here comes the syntax > http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Type-Attributes.html#Type-Attrib > utes Yes, I'm using gcc. > > I just learned that ARM is bi-endian and can be set up either way. Haven't > ever had to deal with these creatures. And that is what endianness is > usually about. If you are unlucky the order of 2 bytes of m_voltageMask may > be incorrect, in this case you would receiver char[10] first, reverse it, > and have a packed structure defined with the inverse order of members. See > also http://linux.die.net/man/3/htons . Does anybody know how to make ARM system to have the same endianess as with x86? I am using X11-GPE-IMAGE from OpenEmbedded. I just tested my program and it looks like I am not getting data properly, so I guess the image set as big endian by default. Thank you. > > Mikhail > > >> -----Original Message----- >> From: Chris Vine [mailto:chris@xxxxxxxxxxxxxxxxxxxxx] >> Sent: Friday, April 08, 2011 7:02 PM >> To: Mikhail Titov >> Cc: 'Igor Korot'; gtk-list@xxxxxxxxx >> Subject: Re: Question about GTK+ and timers >> >> On Fri, 8 Apr 2011 18:36:41 -0500 >> "Mikhail Titov" <mlt@xxxxxx> wrote: >> > Just use something like __attribute__ ((__packed__)) for your >> > structure and you can always cast back and forth from the pointer to >> > your structure to an array of bytes (char*). Just make sure that both >> > systems have same ending (little or big) and that members' order is >> > correct. Otherwise you'll have to swap data within let's say >> > m_voltageMask . >> >> This attribute is compiler specific. He would also have to be careful >> to avoid breaking strict aliasing with his casting, or he could have the >> compiler "optimize" away some of his code. It is relatively easy to >> avoid that (make sure you start with the type you finish with), but I >> am not convinced the OP is necessarily up to speed on how to do it >> defensively. >> >> Because this provides unaligned access (on gcc) it can also be >> significantly inefficient on particular architectures. >> >> Chris >> > > > _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
