-
Notifications
You must be signed in to change notification settings - Fork 163
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
Move jpeg_finish_compress out of destructor #433
Conversation
Moving the function out will ensure that no function that can error will be called inside a destructor, thus leaving no chance to get two exceptions in flight or finishing compression even if an error occured
I've lurked around and haven't spotted resource leak. Could anyone please confirm this? This commit should deal with both undefined behavior, termination and resource leakage if that's right. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
I think it is a good idea to add comment in ~writer_backend()
, something like:
// JPEG compression object destruction does not signal errors,
// unlike jpeg_finish_compress called elsewhere,
// so there is no need for the setjmp bookmark here.
jpeg_destroy_compress(get());
This should help a suspicious reader to avoid an urge to patch it :)
Added comments to explain why finish compress was moved out of destructor, and did stylistical changes
@mloskot , thanks! I did as you mentioned, and I believe the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. Many thanks to @misos1 for his involvement and help
Awesome. Thanks again @simmplecoder & @misos1 for your efforts. |
Description
This pull request removes the
jpeg_finish_compress
call from destructor, which will ensure no erroring function can be called when an exception is in flight or the destructor can fail. If we would throw out of destructor some time in the future, we will have to putnoexcept(false)
, as destructors arenoexcept
by default.Thanks a lot to @misos1 for having productive discussion about the
setjmp
andlongjmp
in the original issue.References
#416
Tasklist