You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've checked the source code and found that NFD_MAX_STRLEN is 256 and maybe used for paths. However, on Linux MAX_PATH is often 4096. But with a 4096 buffer, it is probably risky to just put it multiple times onto the stack as done here since that might exceed the stack space on some systems with less stack by default (Alpine with musl-libc comes to mind). So that might need some more fundamental refactoring.
While checking this file, I have also found strdup() is used without null pointer checking, meaning the code would crash on allocation failure rather than allowing the calling application to recover in some way which would be preferable. I've seen a similar potential issue with NFDi_Malloc use. (I know this recovery isn't safely possible with glib/GTK+, but it should be with most/all(?) other targets.)
The text was updated successfully, but these errors were encountered:
Side note: maybe strdup should also be replaced with an NFDi_strdup() that uses NFDi_Malloc and memcpy? Since that would otherwise not go through the custom allocator as probably intended. Just another thought that came to mind.
I've checked the source code and found that NFD_MAX_STRLEN is 256 and maybe used for paths. However, on Linux MAX_PATH is often 4096. But with a 4096 buffer, it is probably risky to just put it multiple times onto the stack as done here since that might exceed the stack space on some systems with less stack by default (Alpine with musl-libc comes to mind). So that might need some more fundamental refactoring.
While checking this file, I have also found
strdup()
is used without null pointer checking, meaning the code would crash on allocation failure rather than allowing the calling application to recover in some way which would be preferable. I've seen a similar potential issue withNFDi_Malloc
use. (I know this recovery isn't safely possible with glib/GTK+, but it should be with most/all(?) other targets.)The text was updated successfully, but these errors were encountered: