Skip to content
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

Fix uninitialized variable #89040

Closed
wants to merge 4 commits into from
Closed

Conversation

iagarwa
Copy link
Contributor

@iagarwa iagarwa commented Apr 17, 2024

Fix uninitialized scalar field

Signed-off-by: Isha Agarwal <isha.agarwal@intel.com>
Copy link

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be
notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write
permissions for the repository. In which case you can instead tag reviewers by
name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review
by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate
is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

@llvmbot
Copy link
Collaborator

llvmbot commented Apr 17, 2024

@llvm/pr-subscribers-backend-directx

Author: Isha Agarwal (iagarwa)

Changes

Fix uninitialized scalar field


Full diff: https://github.com/llvm/llvm-project/pull/89040.diff

1 Files Affected:

  • (modified) llvm/include/llvm/BinaryFormat/DXContainer.h (+1-1)
diff --git a/llvm/include/llvm/BinaryFormat/DXContainer.h b/llvm/include/llvm/BinaryFormat/DXContainer.h
index e8d03f806715f1..7ef858d0b393b6 100644
--- a/llvm/include/llvm/BinaryFormat/DXContainer.h
+++ b/llvm/include/llvm/BinaryFormat/DXContainer.h
@@ -427,7 +427,7 @@ struct ResourceBindInfo : public v0::ResourceBindInfo {
 
 namespace v3 {
 struct RuntimeInfo : public v2::RuntimeInfo {
-  uint32_t EntryNameOffset;
+  uint32_t EntryNameOffset = 0;
 
   void swapBytes() {
     v2::RuntimeInfo::swapBytes();

@llvmbot
Copy link
Collaborator

llvmbot commented Apr 17, 2024

@llvm/pr-subscribers-llvm-binary-utilities

Author: Isha Agarwal (iagarwa)

Changes

Fix uninitialized scalar field


Full diff: https://github.com/llvm/llvm-project/pull/89040.diff

1 Files Affected:

  • (modified) llvm/include/llvm/BinaryFormat/DXContainer.h (+1-1)
diff --git a/llvm/include/llvm/BinaryFormat/DXContainer.h b/llvm/include/llvm/BinaryFormat/DXContainer.h
index e8d03f806715f1..7ef858d0b393b6 100644
--- a/llvm/include/llvm/BinaryFormat/DXContainer.h
+++ b/llvm/include/llvm/BinaryFormat/DXContainer.h
@@ -427,7 +427,7 @@ struct ResourceBindInfo : public v0::ResourceBindInfo {
 
 namespace v3 {
 struct RuntimeInfo : public v2::RuntimeInfo {
-  uint32_t EntryNameOffset;
+  uint32_t EntryNameOffset = 0;
 
   void swapBytes() {
     v2::RuntimeInfo::swapBytes();

@iagarwa
Copy link
Contributor Author

iagarwa commented Apr 17, 2024

@MalaySanghi @mahesh-attarde please review

Copy link
Collaborator

@llvm-beanz llvm-beanz left a comment

Choose a reason for hiding this comment

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

Uh, why do we need to do this? None of the other data structures in this file initialize their values with inline initializers.

@iagarwa
Copy link
Contributor Author

iagarwa commented Apr 18, 2024

RuntimeInfo Objects are created only for v3 ones. That's why i initialize only EntryNameOffset

@llvm-beanz
Copy link
Collaborator

Even if that were true (which it isn’t, we create a std::variant of the four versions), the change still doesn’t make sense. Why would we want to only initialize the last field of a large data structure?

Is there an actual case where this caused an uninitialized value to be used, or is this just a speculative problem?

@MalaySanghi
Copy link
Contributor

@iagarwa
The field is initialized before use. Just not in the constructor. Look at PSVRuntimeInfo::finalize. So it seems to me that there's no bug.

Although I don't see a downside in initializing the field, I think you can ignore this.

@iagarwa iagarwa closed this Apr 22, 2024
@iagarwa
Copy link
Contributor Author

iagarwa commented Apr 22, 2024

Not needed

@iagarwa iagarwa deleted the initialize_scalar branch April 22, 2024 07:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants