https://bugs.exim.org/show_bug.cgi?id=1861
--- Comment #7 from Marc Mutz <marc.mutz@???> ---
> > As I wrote in the commit message, it is not. If you're programming in
> > assembler, sure, it is, but in C, you're not programming an x86, but the C
> > abstract machine, and the compiler is allowed to assume (and does assume,
> > ask the Linux kernel guys) that UB doesn't happen, and optimise accordingly.
>
> Is this described in the C standard?
Yes. And the fact that ubsan (ie. the compiler) warns means that it's aware of
the issue. Chandler Carruth said in one of this recent talks that for the Clang
the goal is to warn about UB with ubsan or not take advantage of it when
optimising. So, from that fact that ubsan warns.... :)
> I mean I would rather use SLJIT_MEMCPY directly than introducing another
> sljit_unaligned_store_s32 macro.
I tried that at first, too, but some of the assignments have different types on
the LHS than on the RHS, so you would have to introduce a temporary of the
target type before you can memcpy that into the target address, because memcpy
doesn't do type conversion. After two or so of those, I decided it's much more
elegant to add the store_unaligned functions, esp. since it saves a comment
each time it's called, too.
--
You are receiving this mail because:
You are on the CC list for the bug.
