Skip to content

[LangRef] Document accessing memory outside of object is UB. #128429

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 6 additions & 7 deletions llvm/docs/LangRef.rst
Original file line number Diff line number Diff line change
Expand Up @@ -3293,7 +3293,9 @@ heap allocation calls, and global variable definitions. Once it is allocated,
the bytes stored in the region can only be read or written through a pointer
that is :ref:`based on <pointeraliasing>` the allocation value. If a pointer
that is not based on the object tries to read or write to the object, it is
undefined behavior.
undefined behavior. Trying to read or write memory outside of an allocated
object, including accesses partially outside an allocated object, is undefined
behavior.

The following properties hold for all allocated objects:

Expand Down Expand Up @@ -11108,12 +11110,9 @@ operation (that is, the alignment of the memory address). It is the
responsibility of the code emitter to ensure that the alignment information is
correct. Overestimating the alignment results in undefined behavior.
Underestimating the alignment may produce less efficient code. An alignment of
1 is always safe. The maximum possible alignment is ``1 << 32``. An alignment
value higher than the size of the loaded type implies memory up to the
alignment value bytes can be safely loaded without trapping in the default
address space. Access of the high bytes can interfere with debugging tools, so
should not be accessed if the function has the ``sanitize_thread`` or
``sanitize_address`` attributes.
1 is always safe. The maximum possible alignment is ``1 << 32``. Access of the
high bytes can interfere with debugging tools, so should not be accessed if the
function has the ``sanitize_thread`` or ``sanitize_address`` attributes.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"store" has similar language.

The language about sanitize_thread/sanitize_address isn't relevant if you're removing the allowance to load bytes past the end.

This was added in 7020f25 ; CC @arsenm .

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe @chandlerc requested the bit about the sanitizers


The alignment is only optional when parsing textual IR; for in-memory IR, it is
always present. An omitted ``align`` argument means that the operation has the
Expand Down