leaks

jaynuine commented

2026-02-17 12:48:46 +00:00

Owner

perspective vrot leak
unitialised value of size 8 in sin
investigate 24 blocks leak (i don't remember but i probably fixed it amongst with all the other previous leaks)
map field not being freed fully

- [x] perspective vrot leak unitialised value of size 8 in sin - [x] investigate 24 blocks leak (i don't remember but i probably fixed it amongst with all the other previous leaks) - [x] map field not being freed fully

jaynuine added this to the todo project

2026-02-17 12:48:46 +00:00

jaynuine changed title from ~~perspective vrot leak~~ to leaks

2026-02-19 08:08:11 +00:00

jaynuine added this to the foundation milestone

2026-02-27 02:36:00 +00:00

jaynuine commented

2026-02-27 14:17:01 +00:00

Author

Owner

the uninitialised value errors reported by valgrind are false positives as valgrind considers type punning illegal and requires inactive union members to be explicitly defined in spite of the standard considering such use defined since c11, especially for my use case in which types match. (typically, vectors indexable by natural or by axis name)

valgrind does not seem to care about the standard specified upon compilation, which is certainly odd. enforcing gnu11 should solve the issue assuming valgrind is considering my code as cpp, and yet no matter the standard those errors arise.

since this is clearly defined behaviour i will proceed to ignore valgrind's prescriptive attitude towards the standard, even when objectively in the wrong.

along with this, all leaks have been tamed.

the uninitialised value errors reported by valgrind are false positives as valgrind considers type punning illegal and requires inactive union members to be explicitly defined in spite of the standard considering such use defined since c11, especially for my use case in which types match. (typically, vectors indexable by natural or by axis name) valgrind does not seem to care about the standard specified upon compilation, which is certainly odd. enforcing gnu11 *should* solve the issue assuming valgrind is considering my code as cpp, and yet no matter the standard those errors arise. since this is clearly defined behaviour i will proceed to ignore valgrind's prescriptive attitude towards the standard, even when objectively in the wrong. along with this, all leaks have been tamed.

jaynuine closed this issue

2026-02-27 14:17:01 +00:00

jaynuine added a new dependency

2026-05-03 02:58:33 +00:00

#31 valgrind suppression file

Rows
Columns

leaks #5