>>156884>>156887>Wenn man das weiterdenkt, dann dürftest du auch niemals einen Zeiger auf Element eines Structs nehmen oder eines Arrays.
Naja, die Frage ist, ob der "effektive Typ" von einem Objekt vom Typ
struct S { int n; } und einem Objekt vom Typ
int n; der gleiche ist. Also ob ein
struct-Kondom etwas am "effektiven Typ" vom Objekt ändert oder nicht. Das ist zu unterscheiden davon, ob man sich zum Objekt (auch über
structs) in Form eines Elements hinhangelt, und dann nur Überlegungen über den "effektiven Type" von dem einem Element
int n; macht. Bei Arrayelementen hätte man sowieso keine unterschiedlichen Zeigertypen, Pointer können da immer aliasen.
Aber Felix hat etwas gefunden.
In C++ wurde jetzt (im Jahre 2017) explizit klargestellt, dass es funktioniert (nachdem im Jahr 2016 gesagt wurde, dass es funktionieren soll):
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0817r0.html
Es ist also nicht so offensichtlich, wenn es erst klargestellt werden muss.
Damit ist nun natürlich die Frage, wie es in C ohne Klarstellung aussieht...
Übrigens wird das obige direkt wieder eingeschränkt mit:
>An array object and its first element are not pointer-interconvertible, even though they have the same address.
Jedenfalls hat Felix damit etwas gelernt und sagt: Ja, der Kot oben verstößt (jedenfalls in C++) nicht gegen die strict-aliasing-Rule.
>pkg-config --cflags glib-2.0
Felix hat es gerade auf seinem Gentoo (eigene Kompiler-Flags gesetzt) getestet, und da fehlt eine gigantische Menge an Kompiler-Flags in der Ausgabe.
>Und bei dem ursprünglichen Link mit Cocoa [0] dort ging es um was völlig anderes. Apfel hat diese Eigenart, dass sie Typen wie CGRect und NSRect in mehreren Headern definieren, jeweils als komplett eigene Definition, aber eigentlich identisch.
Ich sehe in der Dokumentation nur:
>typealias NSRect = CGRect
https://developer.apple.com/documentation/foundation/nsrect
Felix wundert sich, warum, nachdem der GNOME-Typ (zumindest beim "Product: GStreamer") "we should enable it" gesagt hat, der Status vom Käfer auf "RESOLVED FIXED" gesetzt wurde. Naja seis drum.
Da du dich mit der glib auszukennen scheinst, würde Felix mal nachfragen, was es damit auf sich hat:
/* We need GCC for __extension__, which we need to sort out strict aliasing of @object_ptr */
#if defined(__GNUC__)
#define g_set_object(object_ptr, new_object) \
(G_GNUC_EXTENSION ({ \
G_STATIC_ASSERT (sizeof *(object_ptr) == sizeof (new_object)); \
/* Only one access, please; work around type aliasing */ \
union { char *in; GObject **out; } _object_ptr; \
_object_ptr.in = (char *) (object_ptr); \
/* Check types match */ \
(void) (0 ? *(object_ptr) = (new_object), FALSE : FALSE); \
(g_set_object) (_object_ptr.out, (GObject *) new_object); \
})) \
GOBJECT_AVAILABLE_MACRO_IN_2_44