(We're already talking about this elsewhere, but commenting for posterity.)
I had already taken a different approach to writing an allocator (adding a header to each alloc'd chunk) but had not pushed it yet. You have taken the time to locate calls to malloc/free/XFree/etc. that need to be fixed, though, and that's quite helpful. If there's a handy way for me to cherry-pick lines from this patch, I'll try to do that.
Thank you!
(We're already talking about this elsewhere, but commenting for posterity.)
I had already taken a different approach to writing an allocator (adding a header to each alloc'd chunk) but had not pushed it yet. You have taken the time to locate calls to malloc/free/XFree/etc. that need to be fixed, though, and that's quite helpful. If there's a handy way for me to cherry-pick lines from this patch, I'll try to do that.
I'm merging this into another branch and will open a PR for that to the main repo, under refactor/wutil-rs.
When you went in and updated calls to malloc/free, did you also look at XFree? That seems to delegate to the stdlib free under the hood.
I'm merging this into another branch and will open a PR for that to the main repo, under refactor/wutil-rs.
When you went in and updated calls to malloc/free, did you also look at `XFree`? That seems to delegate to the stdlib `free` under the hood.
I'm merging this into another branch and will open a PR for that to the main repo, under refactor/wutil-rs.
When you went in and updated calls to malloc/free, did you also look at XFree? That seems to delegate to the stdlib free under the hood.
Oops, sorry; just saw this: I don't think gitea sends email when updates happen.
I did not touch XFree; my theory there is that the X library does its own memory management and wraps around malloc/free, and I don't think we should interpose on that.
> I'm merging this into another branch and will open a PR for that to the main repo, under refactor/wutil-rs.
>
> When you went in and updated calls to malloc/free, did you also look at `XFree`? That seems to delegate to the stdlib `free` under the hood.
Oops, sorry; just saw this: I don't think `gitea` sends email when updates happen.
I did not touch XFree; my theory there is that the X library does its own memory management and wraps around `malloc`/`free`, and I don't think we should interpose on that.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Replace
wmallocet al with wrappers around the Rust allocationlibrary.
Thank you!
(We're already talking about this elsewhere, but commenting for posterity.)
I had already taken a different approach to writing an allocator (adding a header to each alloc'd chunk) but had not pushed it yet. You have taken the time to locate calls to malloc/free/XFree/etc. that need to be fixed, though, and that's quite helpful. If there's a handy way for me to cherry-pick lines from this patch, I'll try to do that.
I'm merging this into another branch and will open a PR for that to the main repo, under refactor/wutil-rs.
When you went in and updated calls to malloc/free, did you also look at
XFree? That seems to delegate to the stdlibfreeunder the hood.I merged this into another branch to get all the
wmalloc/wfreefixes and pulled it in with #2. Thanks again!Oops, sorry; just saw this: I don't think
giteasends email when updates happen.I did not touch XFree; my theory there is that the X library does its own memory management and wraps around
malloc/free, and I don't think we should interpose on that.RE calls to
XFree: there are definite instances of (w)malloc'd pointers being passed toXFree. I'm cleaning them up as I find them.Pull request closed