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

Code mistakes found with TscanCode #1617

Merged
merged 2 commits into from
Jan 24, 2021
Merged

Conversation

HybridDog
Copy link
Contributor

I executed TscanCode on SuperTux' src folder and it found these errors: tscan_result.txt

I tried to fix them but I don't understand all code sections, so I don't know if all my changes make sense.

Copy link
Member

@Semphriss Semphriss left a comment

Choose a reason for hiding this comment

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

Looked into it, there are some minor details and information about the fixed errors - nothing critical though. I'm responsible for half of them and I'll probably correct them in a cleaner way, to keep my features as straightforward as possible.

float value = 0.f;
static float value = 0.f;
m_value = &value;
revert_value();
Copy link
Member

Choose a reason for hiding this comment

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

According to https://www.geeksforgeeks.org/static-keyword-cpp/ :

Static variables in a Function: When a variable is declared as static, space for it gets allocated for the lifetime of the program. Even if the function is called multiple times, space for the static variable is allocated only once and the value of variable in the previous call gets carried through the next function call.

This variable should be unique - in fact, it shouldn't even exist, and should be forcibly included in the ctor. It's my responsibility to fix that! 😆

int value = 0;
static int value = 0;
m_value = &value;
revert_value();
Copy link
Member

Choose a reason for hiding this comment

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

Same as above

Comment on lines 1531 to 1574
else if ((m_physic.get_velocity_y() <= 0)) {
m_sprite->set_action(sa_prefix+"-jump"+sa_postfix);
}
else if ((m_physic.get_velocity_y() <= 0)) {
m_sprite->set_action(sa_prefix+"-skid"+sa_postfix);
}
}
Copy link
Member

Choose a reason for hiding this comment

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

The bodies are different - it shouldn't be deleted right away. We should see in which case(s) Tux must skid/jump and fix the conditions accordingly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The skidding action is also set at another place in the code and skidding worked in the game when I tried it.

Comment on lines -83 to +82
if (m_action->family_name != newaction->family_name)
if (!m_action || m_action->family_name != newaction->family_name)
Copy link
Member

Choose a reason for hiding this comment

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

Is it possible for m_action to be empty at this point in the code? Should we use a non-pointer property?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In the constructor m_action is set to some action from the SpriteData reference m_data, and the draw method only works if m_action is not nullptr. I don't know if a Sprite which cannot be drawn can exist.

Comment on lines -118 to +119
for (auto& mask : m_masks)
return mask->get_mask();
if (!m_masks.empty())
return m_masks[0]->get_mask();
Copy link
Member

Choose a reason for hiding this comment

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

(I'm responsible for that one - I'm currently revamping the autotiles and I had spotted that error and a few others:) But thanks anyways for the fix, I have no idea what I was thinking when I wrote that 😆)

@Semphriss
Copy link
Member

Question - Why "involves: security"? Are there security-critical exploits in the bugs found?

@HybridDog
Copy link
Contributor Author

HybridDog commented Dec 25, 2020

I think since SuperTux is a singleplayer game there are inherently almost no security problems. Exceptions are the add-on downloading, downloaded script execution (or similar things) and availability problems (e.g. crash on startup when a configuration is wrong; I'm not sure if this is safety or security).
Apparently the security label was never used before: https://github.com/SuperTux/supertux/pulls?q=label%3Ainvolves%3Asecurity+
Here I thought the label may be relevant in comparison to many other issues or PRs because some detected errors are about invalid pointers, but it's not critical, so I'm removing it.

@tobbi
Copy link
Member

tobbi commented Jan 10, 2021

Can you please rebase? I'll merge it afterwards.

@Semphriss
Copy link
Member

@tobbi Don't merge it yet - I believe those static variables in the UI might cause a memory leak. I'd like to fix those myself.

@HybridDog Do I have your permission to edit the two static variables?

@HybridDog
Copy link
Contributor Author

Do I have your permission to edit the two static variables?

Yes, please do it.

I think my changes in game_session.cpp may not make much sense. I don't know in which cases m_currentsector can be null.

@Semphriss
Copy link
Member

Forgot to write it yesterday, but it's ready now 👍

@tobbi
Copy link
Member

tobbi commented Jan 24, 2021

Thanks, @HybridDog

@tobbi tobbi merged commit 2edc75a into SuperTux:master Jan 24, 2021
@HybridDog HybridDog deleted the m_tscan_detecteds branch January 24, 2021 16:12
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.

3 participants