Skip to content

use saner parameter order for reallocate / reallocate_inplace #17837

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.

Sign up for GitHub

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

Jump to bottom
Closed
thestinger opened this issue Oct 7, 2014 · 0 comments · Fixed by #17870
Closed

use saner parameter order for reallocate / reallocate_inplace #17837

thestinger opened this issue Oct 7, 2014 · 0 comments · Fixed by #17870
Assignees
@thestinger
Labels
A-allocators Area: Custom and system allocators C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@thestinger
Copy link
Contributor

I wasn't really thinking about it when I added the old_size parameter and just put it at the end since it was a new addition. It would be better to match the order used by other APIs like mremap by putting the old size before the new size because it's more intuitive (old_ptr, old_size, new_size).
@thestinger thestinger added E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. C-cleanup Category: PRs that clean code up or issues documenting cleanup. labels Oct 7, 2014
@thestinger thestinger self-assigned this Oct 7, 2014
@thestinger thestinger added the A-allocators Area: Custom and system allocators label Oct 8, 2014
@thestinger thestinger mentioned this issue Oct 8, 2014
Merged
bors added a commit that referenced this issue Oct 8, 2014
@bors
auto merge of #17870 : thestinger/rust/alloc, r=eddyb
800e904 
Using reallocate(old_ptr, old_size, new_size, align) makes a lot more
sense than reallocate(old_ptr, new_size, align, old_size) and matches up
with the order used by existing platform APIs like mremap.

Closes #17837

[breaking-change]
bors added a commit that referenced this issue Oct 9, 2014
@bors
auto merge of #17870 : thestinger/rust/alloc, r=eddyb
41fde28 
Using reallocate(old_ptr, old_size, new_size, align) makes a lot more
sense than reallocate(old_ptr, new_size, align, old_size) and matches up
with the order used by existing platform APIs like mremap.

Closes #17837

[breaking-change]
bors added a commit that referenced this issue Oct 9, 2014
@bors
auto merge of #17870 : thestinger/rust/alloc, r=eddyb
f010aa5 
Using reallocate(old_ptr, old_size, new_size, align) makes a lot more
sense than reallocate(old_ptr, new_size, align, old_size) and matches up
with the order used by existing platform APIs like mremap.

Closes #17837

[breaking-change]
bors added a commit that referenced this issue Oct 9, 2014
@bors
auto merge of #17870 : thestinger/rust/alloc, r=eddyb
e6cfb56 
Using reallocate(old_ptr, old_size, new_size, align) makes a lot more
sense than reallocate(old_ptr, new_size, align, old_size) and matches up
with the order used by existing platform APIs like mremap.

Closes #17837

[breaking-change]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@thestinger thestinger

Labels
A-allocators Area: Custom and system allocators C-cleanup Category: PRs that clean code up or issues documenting cleanup. E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

saner parameter order for reallocation functions
1 participant
@thestinger