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

options: prevent null pointer access to FrameDurationLimits #428

Merged
merged 1 commit into from
Jan 9, 2023
Merged

options: prevent null pointer access to FrameDurationLimits #428

merged 1 commit into from
Jan 9, 2023

Conversation

christianrauch
Copy link
Contributor

This fixes a null-pointer access when FrameDurationLimits is not available. In this case, the framerate is set to an invalid NAN.

@naushir
Copy link
Collaborator

naushir commented Jan 3, 2023

@christianrauch thanks for the submission!

Can I ask for some more context on this please? FrameDurationLimits should always be present for each camera mode, so this should never be null. Are you seeing it missing?

@christianrauch
Copy link
Contributor Author

I was experimenting with the app for a regular USB webcam without frame durations. I think it is always a good idea to check that the accessed elements are also available to avoid invalid access.

@@ -155,7 +155,7 @@ bool Options::Parse(int argc, char *argv[])

auto fd_ctrl = cam->controls().find(&controls::FrameDurationLimits);
auto crop_ctrl = cam->properties().get(properties::ScalerCropMaximum);
double fps = 1e6 / fd_ctrl->second.min().get<int64_t>();
double fps = fd_ctrl==cam->controls().end() ? NAN : (1e6 / fd_ctrl->second.min().get<int64_t>());
std::cout << std::fixed << std::setprecision(2) << "["
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think I would probably prefer 0 instead of NAN. What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since 0 is a valid number, this could be interpreted as you can only take a single or no images. "NAN" signals for me that the framerate is not available or unknown. As a bonus, if someone decides to do math with it, the NAN will propagate and it will be easier visible that this operation should not be done.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think fps == 0.0 is possible for a valid configuration. But I am ok with NAN either way.

@christianrauch
Copy link
Contributor Author

The CI questions the style of some code lines that I did not touch and it changes the only line I touched to something that looks weird with a large gap on the next line. Shall I really apply those suggestions to satisfy the CI?

@naushir
Copy link
Collaborator

naushir commented Jan 3, 2023

The CI questions the style of some code lines that I did not touch and it changes the only line I touched to something that looks weird with a large gap on the next line. Shall I really apply those suggestions to satisfy the CI?

No need to fix those, seems the CI got something wrong when scanning the patch. Although, looking closely, it has flagged one issue:

-    double fps = fd_ctrl==cam->controls().end() ? NAN : (1e6 / fd_ctrl->second.min().get<int64_t>());
+    double fps = fd_ctrl == cam->controls().end() ? NAN : (1e6 / fd_ctrl->second.min().get<int64_t>());

Would you be able to fix that up, then I can merge this.

@naushir naushir merged commit 1d91fdd into raspberrypi:main Jan 9, 2023
@christianrauch christianrauch deleted the fix_duration_access branch January 9, 2023 19:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants