rayedit.git/vector.h, branch masterText editor for large files
http://git.dilluti0n.com/rayedit.git/atom?h=master2025-05-14T09:40:29Zfix: double-free of line object in eb_backspace and eb_delete_line2025-05-14T09:40:29Zdilluti0nhskimse1@gmail.com2025-05-14T06:46:33Zurn:sha1:502aea93b7e2cae6a17d83e6989109d56c9ec79f
On eb_backspace, when the upper line was non-null, line_cat followed
by line_free, and eb_delete_line only cleared the line_vec. However,
commit 2441e78 introduced an additional line_free in eb_delete_line to
fix a memory leak, which led to a double-free for that line. This
patch resolves that problem.
refactor: introduce mem.h; wrappers for allocators2025-05-10T13:51:23Zdilluti0nhskimse1@gmail.com2025-05-10T13:13:33Zurn:sha1:d6872a59a28c8db551ff0b18c9d9041c5cbaa5a5
This patch removes the dependency on raylib when allocating memory.
fix: Memory Leak in eb_delete_line2025-05-10T13:20:29Zdilluti0nhskimse1@gmail.com2025-05-10T11:12:49Zurn:sha1:2441e78bffaef89dcea64c547329e541250553e7
The function eb_delete_line did not properly free the contents of the
entry when deleting an element from eb->line_vec. This patch fixes
that issue.
minor: use #pragma once instead of #ifndef ... on vector.h2025-05-01T13:37:10Zdilluti0nhskimse1@gmail.com2025-05-01T13:36:40Zurn:sha1:e92971fbd61e28d02f439d0d993d8693e079098crefactor: introduce lazy loading to each line buffer.2025-04-29T07:12:29Zdilluti0nhskimse1@gmail.com2025-04-29T06:54:05Zurn:sha1:681aca7025dd1d43700b55d8a254bb61881d4b06
Each `struct line` now holds a pointer (`origin`) to its corresponding
line in the mmap'd file, along with its length (`origin_len`). The
`vec` field is no longer allocated for each line during
`eb_load_file`.
Instead, actual memory allocation and copying into `vec` occurs only
when an edit is made or when `line_get_string` is called (since a C
string is required). This behavior is handled via the internal inline
function `edit_happen`.
Also implement `vec_cat_raw` to `line_cat` when lazy `src`.
[minor]
Remove unused debug messages in editor.c.
perf: reduce to a single allocation in line_init_from_buf2025-04-29T05:39:12Zdilluti0nhskimse1@gmail.com2025-04-29T05:36:07Zurn:sha1:21dd60f0fba9be465ccaac4ae05c2b3aba505f1a
Previously, line_init_from_buf called line_init followed by
vec_resize, which could result in up to two separate allocations. This
patch introduces vec_init_with_capacity, allowing the vector to be
initialized with the required capacity in a single step, reducing
allocation overhead.
perf: improve vec_resize to not realloc again and again2025-04-29T05:22:03Zdilluti0nhskimse1@gmail.com2025-04-29T05:22:03Zurn:sha1:1e1e22a2c2021fa1ed25932a742d310b039a09d5implement: vec_clear2025-04-28T05:08:55Zdilluti0nhskimse1@gmail.com2025-04-28T05:08:35Zurn:sha1:853154b4a3a2fc774d7cdbfdfcb7445a374e07f5
It just bump size to 0.
fix: inserting on newline cause segmentatnion fault2025-04-27T06:22:58Zdilluti0nhskimse1@gmail.com2025-04-27T06:17:49Zurn:sha1:531027c2299486b1727d8e22bc10ac32040acc78
This was rely on NULL-initialization of physically allocated
vector. When I remove that feature, it immediatly segfalt since
logically v->data[index] is not allocated so its not initialized by
NULL yet.
[minor]
add assert on vec_get to avoid this kind of stupid mistake.
change: remove zero initialization on allocation2025-04-27T06:14:48Zdilluti0nhskimse1@gmail.com2025-04-27T06:14:48Zurn:sha1:805a4d20721b53ae3a83f0ca59f6baeac7174520
instead, this will handle on *_resize for logically allocated segmants.
[minor]
refactor function vec_grow_to_size to proper name *_resize