Closed TobleMiner closed 6 years ago
Moving the event buffer to the stack somewhat makes the calls involving this buffer use explicit pointers. As the Event FD already needs checking there's not too much overhead also checking these allocations. Especially as we'd have to this being allocated dynamically (yes, it's more or less a constant in the current implementation, but people might want to configure this eventually).
Two more arguments against these allocations to appear on the stack are 1. stack frame size, which you should limit to keep within sane limits of stack usage and 2. security by avoiding buffers that could overflow into critical control and application data at constant addresses.
Yeah, we should probably keep the stack frames to reasonable sizes. We'll just keep the dynamically allocated structures then. Security is a good point, too. I don't think implications would be too big right now but in case the receive routine grows a little more complex in the future we might make stack smashing a lot easier by moving the data buffer to the stack.
https://github.com/sargon/ddhcpd/blob/master/main.c#L130 allocates the config on the heap. As far as I can see the stack frame of the main method should be valid throughout the whole lifetime of the program. I think we could just put it on the stack, couldn't we? That way we won't have to deal with allocation failues.
The same goes for the event buffer at https://github.com/sargon/ddhcpd/blob/master/main.c#L363
also for the packet buffer at https://github.com/sargon/ddhcpd/blob/master/main.c#L340
and even the packet buffer in https://github.com/sargon/ddhcpd/blob/master/ddhcpctl.c#L28