The @musllibc UB-purge continues. https://git.musl-libc.org/cgit/musl/commit/?id=4d0a82170a25464c39522d7190b9fe302045ddb2 … and previous few commits.
-
Show this thread
-
The only "intentional UB" I'm aware of remaining is (aligned) over-read potentially past end-of-array in string ops. There is no GNU C construct to annotate and make this legal so I'm not sure what to do with it.
2 replies 0 retweets 4 likesShow this thread -
Replying to @RichFelker
Get the committee to make it implementation defined
1 reply 0 retweets 1 like -
Replying to @stephentyrone
They don't even govern it because it can only happen with GNU-C-specific may_alias types. Really GCC and clang should probably specify this if it's supposed to work.
2 replies 0 retweets 1 like -
Replying to @RichFelker
Would be nice to be able to grab the aligned block containing the first byte. I don’t think you can compute that address without formal UB.
2 replies 0 retweets 0 likes -
Replying to @stephentyrone @RichFelker
Obviously, this is in the category of “UB, but has to work or everything breaks”, but it causes a lot of ASan false positives for me =\
1 reply 0 retweets 0 likes -
Replying to @stephentyrone
Yes, and for ASan and Valgrind it's breaking even if you use asm to do it, despite it being clearly well-defined for the asm code where the memory/address model is just the ISA's model.
2 replies 0 retweets 0 likes
Aside from the ASan and Valgrind spam though I'm not really bothered by this. The intent is likely that this work (it should probably be documented as a property of the may_alias attribute though) and it's not going to break.
-
-
Replying to @RichFelker
Yeah, at least on the clang side, lots of things in iOS and macOS would break if this changed, so it’s “safe”.
0 replies 0 retweets 1 likeThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.