You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 1, 2022. It is now read-only.
In Image::~Image, the code to free m_paucEncodingBits is commented out. Presumably this is because one of the Image::Image constructors allows the caller to pass in their own encoding bits so calling delete[] would be unsafe in this scenario. However, in other codepaths, the class allocates it's own m_paucEncodingBits in the Image::Encode function which is never freed.
A possible solution would be to add a bool to Etc::Image to track whether or not it allocated m_paucEncodingBits, and free when necessary.
The text was updated successfully, but these errors were encountered:
Actually looking at the behaviour of Etc::EncodeMipmaps Etc::Encode it's clear that m_paucEncodingBits must persist beyond the lifetime of the Etc::Image so it's the callers responsibility to free the memory. Perhaps that could be made clearer somehow, but there's no bug.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
In Image::~Image, the code to free m_paucEncodingBits is commented out. Presumably this is because one of the Image::Image constructors allows the caller to pass in their own encoding bits so calling delete[] would be unsafe in this scenario. However, in other codepaths, the class allocates it's own m_paucEncodingBits in the Image::Encode function which is never freed.
A possible solution would be to add a bool to Etc::Image to track whether or not it allocated m_paucEncodingBits, and free when necessary.
The text was updated successfully, but these errors were encountered: