>
> struct foo {
> uint8_t a;
> uint16_t b;
> };
> struct foo x, y;
> memset(&x, 1, sizeof(x));
> memset(&y, 2, sizeof(y));
> x.a = y.a = x.b = y.b = 0;
> atomic_compare_exchange(&x, &y, y);
>
This is a good question; for the case you presented, things will work,
since the padding itself is taken into account upon memset(). I'm not sure
of the case if you omit the memset, though; C doesn't allow to compare the
structures. I'd assume binary equivalence, if not mentioned otherwise, but
I'll check this case.
I also thought about it, and even wanted to supply a real integer into
type_size() routine, but then decided to keep things simple for the first
patch, and stick to exact memory match, since it was the simplest thing to
do.
I'll check the behavior of other compilers and will update in a separate
patch. Actually, when I checked it, I was kinda surprised it even works for
types other than integers.
It also leaves a room for other questions, like "say float is the same size
as uint32_t, should we handle the trap representation?". And I'm not sure
whether the answers are evident. The binary equivalence was the best shot I
could think of.
All other answers potentially lead to additional code generation. Also,
thinking of non-lock-free-atomics: IIRC these are usually handled by
hashing the addresses along with locking and memcmp/memset. This is also
that should be checked.
When I have time, I'll write some tests which check at least usual
integers; as for more complicated cases, I'll check them afterwards.
>
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
