Timeline for Safe(r) / Easier Pointer Allocation Interface in C (ISO C11)
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 12, 2024 at 10:25 | comment | added | Matthieu M. | @c19: I will disagree heartily with the idea that empowering the caller is "pushing complexity" on them. You are correct, of course, on the pointer comparison issue. | |
| Aug 11, 2024 at 22:53 | comment | added | c19 | @MatthieuM. Pushing complexity up to the caller is the exact opposite of what makes for good programming. And in C it is illegal for the caller to compare the pointers because they are not pointing to the same object. | |
| Aug 10, 2024 at 11:23 | comment | added | Matthieu M. | @c19: That's a very good point, and the first time I see it raised when discussing in-place realloc as a better primitive than copying realloc. Fortunately, I think it's not necessarily a problem: if "moving down" only occurs during block extension, then all the previous memory can remain available, and thus the user can detect the change (by comparing the result pointer to the pass in pointer) and perform the copy. | |
| Aug 9, 2024 at 22:15 | comment | added | user272752 | A bit silly, imho. This suggests (portable?) app source code can and will manage system heap storage better than platform specific library code. If the coder feels they can do a better job, in their application, they can implement an arena (and stay awake at night worrying they've missed an edge case or two.) | |
| Aug 9, 2024 at 19:24 | comment | added | c19 | You can't always leave copying to the user. What if there is adequate free space immediately before the current block? The allocator can add it to the block and shift the contents down, but the user would have to allocate a new block, for which there may not be sufficient available memory. | |
| Aug 9, 2024 at 12:06 | history | answered | Matthieu M. | CC BY-SA 4.0 |