Lots of places checking malloc result for NULL pointer #162
Replies: 2 comments 2 replies
-
The sound of silence... Really, no one interested in making the code less buggy and easier to understand at the same time? |
Beta Was this translation helpful? Give feedback.
-
Hello @svlobanov just asking for a quick comment if you think it's worth to continue in this direction. Not asking for full review as this patch is not yet final, I have a few more updates in the works like adding function attributes, such as noreturn for the out of memory error. Also not sure if abort or exit is better for out of memory condition but it usually indicates the system in very bad state anyway (for example, in my setup there are two redundant pppoe servers so it's no big deal if only one of them stops working, but it's more important for BGP on the same box to keep running). I do understand everyone is busy (I'm too) but I want to help you, I'm in the process of moving from VyOS(tm) to roll-my-own-router-Debian-or-Alpine, but will likely continue using accel-ppp. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
While trying to learn how accel-ppp works, I noticed lots of places where malloc is called and return value checked for NULL which means not enough memory. Are there current platforms where accel-ppp runs on which it makes sense to handle malloc failures gracefully, instead of simply terminating with fatal error? I bet these failure paths are not really much tested, as malloc returning NULL rarely (if ever) happens in practice, and lots of other bad things happen before the system is so low on memory (basically it slows down so much that it becomes unusable, swapping like mad).
See https://www.gnu.org/software/libc/manual/html_node/Malloc-Examples.html for a short xmalloc wrapper function which would be used instead, which never returns failure so all of these NULL checks can be removed. Many places also zero the allocated memory which could be handled by such a wrapper too, instead of separate memset calls. On current machines the performance impact of always zeroing even if not required is probably negligible, while leaving uninitialized data by mistake could lead to hard to detect bugs. What are your thoughts? Would pull requests cleaning up such things be accepted? Or has this been discussed before and decided that it should stay that way?
EDIT: looking more at the code, some places use malloc without checking for NULL, some places use malloc to allocate multiple objects where calloc would be safer (check for integer overflow), and many places zero the allocated memory (which calloc would do as well). A wrapper conventionally named xcalloc could take care of all this, and make the code more readable. Better simply abort() in the wrapper than risk undefined behaviour (like dereferencing NULL pointers), compilers sometimes do funny things making this a potential security issue too.
Beta Was this translation helpful? Give feedback.
All reactions