Skip to content

Address unlikely memleak in zimatcopy interface #1129

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

Merged
merged 3 commits into from
Mar 16, 2017
Merged

Address unlikely memleak in zimatcopy interface #1129

merged 3 commits into from
Mar 16, 2017

Conversation

brada4
Copy link
Contributor

@brada4 brada4 commented Mar 14, 2017

Temp buffer is leaked in (unlikely) fall-through path, now no more.

@martin-frbg
Copy link
Collaborator

What is the motivation for this change, which seems to boil down to the addition of a single "free(b)" for the impossible case that "order" or "trans" have an illegal value ? At least I would like to see all the early returns preserved, if only for human readability.

@brada4
Copy link
Contributor Author

brada4 commented Mar 14, 2017

Interface can be called by user directly,
Correct would be to malloc b before it is used, i.e in 2 valid places, and freed in branches. I am not sure about preserving readability then.

@brada4
Copy link
Contributor Author

brada4 commented Mar 14, 2017

ie if trans=grabage, then leak as it stands now.

@martin-frbg
Copy link
Collaborator

Still would prefer to see just the minimal change made (i.e. addition of the "free(b)" before the return of the fall-through path, no removal of the early returns)

@brada4
Copy link
Contributor Author

brada4 commented Mar 15, 2017

Can fix that. no probl

@martin-frbg martin-frbg merged commit 99880f7 into OpenMathLib:develop Mar 16, 2017
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.

2 participants