Type-punned pointers as lvalues
Jerry James writes:
The compiler warning above tells the story; GCC doesn't see an
assignment to ((ANSI_ALIASING_voidp) &newpath)->p as the same as
assigning to newpath,
You mean newpath.p, right?
even with -fno-strict-aliasing. In the GCC 4.6
manual, it says that assignments of the form:
*(fooptr *)&bar = foo_value;
have undefined semantics.
That seem pretty capricious; to me, that expression seems to have a
very clear (if dangerous) meaning.
So it appears that we've been getting lucky all these years,
and our luck has now run out.
Not really. It has taken a lot of hard work to keep up with GCC's
"this is the edge, so bleed, NOW!" attitude toward optimization.
We're not the only project that's had trouble like this; the GDB folks
are not pleased, either.
I'll try to start looking at what violence we need to do to our
code
base to fix this issue. Whee!
That sounds like more fun than fixing the permissions notices. :-/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta