Documentation | Rust Documentation: Hello World on SPARC crashes since 2024-Oct-10 (#37)
Frank Kuehndel (@frank_k)
gitlab at rtems.org
Thu Oct 17 10:17:23 UTC 2024
Frank Kuehndel commented: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/issues/37#note_113184
**A note**
The Rust discussion is https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Hello.20World.20on.20sparc-unknown-none-elf.20crashes
What happened:
* The Rust compiler replaced `memcpy()` from newlib by a Rust compiler buildin.
* The Rust community added sanity checks for pointer overruns a few days ago – to prevent undefined behavior.
* Since the `memcpy()` above reads the last byte of the address space, the pointer gets incremented and wraps around (or points to behind the address space).This triggers the sanity check and hence the program crashes.
There is a long and interesting Rust community discussion on
* whether accessing the last byte is legal at all. (The result is yes.)
* whether pointer arithmetic that wraps around is legal.
* whether the use of (even the standard) `memcpy()` is undefined behavior when accessing the first or last byte in the address space.
* whether compiler optimization could cause undefined behavior of `memcpy()` when accessing the last byte.
* whether the last and the first byte needs to be defined `volatile` to avoid "bad" compiler optimization.
* concerns of performance of `memcpy()` when adapted to handle this as special case.
Moreover, one must keep in mind that Rust as language is to be "more safe" (less relaxed) than C concerning pointers.
--
View it on GitLab: https://gitlab.rtems.org/rtems/docs/rtems-docs/-/issues/37#note_113184
You're receiving this email because of your account on gitlab.rtems.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20241017/314e4454/attachment-0001.htm>
More information about the bugs
mailing list