Allocate rbs_string_t with allocator
#14
Conversation
st0012
force-pushed
the
allocate-string-with-allocator
branch
from
1fff656 to
f0467a1
Compare
| return (rbs_string_t) { | ||
| .start = start, | ||
| .end = end, |
There was a problem hiding this comment.
So if I understand correctly, this is still a "shared"/"unowned" string, it just doesn't need to be tagged as such, because we're never going to free() any RBS strings anyway.
We might still want the shared/owned distinction for debugging, but this makes sense to me.
There was a problem hiding this comment.
Yes a string will be either "owned by the allocator" or "owned by something else" but we don't have to distinguish them anymore as the freeing is not manual anymore.
I prefer not to leave code around just for potential debugging purpose tho.
| rbs_string_t rbs_string_copy_slice(rbs_string_t *self, size_t start_inset, size_t length) { | ||
| char *buffer = (char *) malloc(length + 1); | ||
| rbs_string_t rbs_string_copy_slice(rbs_allocator_t *allocator, rbs_string_t *self, size_t start_inset, size_t length) { | ||
| char *buffer = rbs_allocator_calloc(allocator, length + 1, char); |
There was a problem hiding this comment.
Follow-up: we're seeing a few of their cases where calloc is convenient for its API, but we don't need its behaviour memset(0, ...) (since we immediately overwrite it, here).
Perhaps we can add something like rbs_allocator_alloc_many which takes a count like calloc doesn, but doesn't 0-out all the memory.
There was a problem hiding this comment.
Will implement right after the PR is merged 👍
st0012
force-pushed
the
allocate-string-with-allocator
branch
from
f0467a1 to
00945c7
Compare
Since we don't manually allocate/free strings anymore, we don't need the string type enum and all the complexity that comes with it.
st0012
force-pushed
the
allocate-string-with-allocator
branch
from
00945c7 to
ee16286
Compare
rbs_string_towned by the parser is now allocated by the allocator