Re: Question about GTK+ and timers

[Igor Korot <ikorot01 gmail com>]

Mikhail,

On Fri, Apr 8, 2011 at 5:11 PM, Mikhail Titov <mlt gmx us> 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 cvine freeserve co uk]
>> Sent: Friday, April 08, 2011 7:02 PM
>> To: Mikhail Titov
>> Cc: 'Igor Korot'; gtk-list gnome org
>> Subject: Re: Question about GTK+ and timers
>>
>> On Fri, 8 Apr 2011 18:36:41 -0500
>> "Mikhail Titov" <mlt gmx us> 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
>>
>
>
>