From: Markus Armbruster
We use atomic operations to keep track of dropped events.
Inconveniently, GLib supports only int and void * atomics, but the
counter dropped_events is uint64_t. Can't stop commit 62bab732: a
quick (gint *)&dropped_events bludgeons the compiler into submission.
That cast
On Thu, Jan 31, 2013 at 12:18:52PM +0100, Laszlo Ersek wrote:
> BTW I wonder if trace files are endianness-dependent by design --
> normally you'd store them in network byte order (= big endian) only and
> use htonX() when writing, an ntohX() when reading.
Yes, they are host endian but the magic n
On 01/31/13 13:10, Markus Armbruster wrote:
> Laszlo Ersek writes:
>> On 01/25/13 16:43, Markus Armbruster wrote:
>>> @@ -63,7 +63,7 @@ typedef struct {
>>> uint64_t timestamp_ns;
>>> uint32_t length; /*in bytes */
>>> uint32_t reserved; /*unused */
>>> -uint8_t argum
Laszlo Ersek writes:
> comments in-line
>
> On 01/25/13 16:43, Markus Armbruster wrote:
>> We use atomic operations to keep track of dropped events.
>>
>> Inconveniently, GLib supports only int and void * atomics, but the
>> counter dropped_events is uint64_t.
>
> That's too bad. Instead of (or
On 01/25/2013 09:13 PM, Markus Armbruster wrote:
We use atomic operations to keep track of dropped events.
Inconveniently, GLib supports only int and void * atomics, but the
counter dropped_events is uint64_t. Can't stop commit 62bab732: a
quick (gint *)&dropped_events bludgeons the compiler in
comments in-line
On 01/25/13 16:43, Markus Armbruster wrote:
> We use atomic operations to keep track of dropped events.
>
> Inconveniently, GLib supports only int and void * atomics, but the
> counter dropped_events is uint64_t.
That's too bad. Instead of (or in addition to) int, glib should ta
We use atomic operations to keep track of dropped events.
Inconveniently, GLib supports only int and void * atomics, but the
counter dropped_events is uint64_t. Can't stop commit 62bab732: a
quick (gint *)&dropped_events bludgeons the compiler into submission.
That cast is okay only when int is
