Even when C89 was being drafted, there was a concern for ensuring that compilers could optimize based on non-aliasing assumptions.
With footnote 28 as follows: "The intent of this list is to specify those circumstances in which an object may or may not be aliased."
-
-
And of course there's dmr's famous response to the noalias qualifier, which was subsequently omitted from C: https://www.lysator.liu.se/c/dmr-on-noalias.html …
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
this doesn't contradict OpenBSD's man page, and I'm not sure what you find funny in it. It says -fstrict-aliasing causes issues…
-
Did you mean to reply to this thread and not the OpenBSD one?
-
This thread is about the general unawareness that even before C89 there was intent that compilers do non-aliasing-based optimizing
-
both. I assumed they were related.
-
Well they are on some level. I just found it ridiculous that OpenBSD is nonchalauntly saying their code needs -fno-strict-aliasing
-
..rather than fixing their UB like I'd expect from a secure OS, & just using -fno-strict-aliasing as extra hardening/safety.
-
in other thread I pointed out an example of how the sockets API demands no-strict-aliasing (not just OpenBSD either)
-
And I've pointed out in multiple threads how that claim is wrong and it's only bad legacy socket code that has probs
- 7 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.