you don't have to receive a request asking for 3 gigs of data. You could be close to the edge and there's not enough room to receive this particular request.
There are many daemons that require you to keep what you have in memory and just fail the particular action you are doing instead of throwing everything away. DB servers for example.
memory exhaustion is an error that should be handled like other errors.
in memqueue, http_respond logs the failed memory allocation(in http_cli_resp_hdr_create) and returns -1. there's nothing else I need to do in this case. The connection will get dropped without a response.
when reallocing, I don't see the integer wrap bug. Can you point me to the line?
What I am suggesting is to not overthink system error handling. Just handle it; aborting is one type of handling but not always what you want. Programs run in various environments and to guarantee a defined behavior we need to abide by the standard.
Then you've misunderstood me, or I've miscommunicated. My argument is that the default handling strategy should be to abort. I'm not saying that special case handling is evil. I'm saying that defaulting to manually checking malloc's return value is evil.
Also, your chunked encoding decoder seems to be using a signed strtol() routine to read an unsigned length variable. I could be misreading; I didn't look carefully.
It depends on the goal in the end. As long as it's an explicit decision and not relying on environment the behavior is expected to be defined.
For instance, I worked on an enterprise proxy where aborting on asserts wasn't acceptable. Why? Because the customer didn't want to interrupt his users even though in our opinion the proxy state was out of whack. This created a nightmare for us because it was hard to debug. We ended up fork()-ing and aborting on the side to debug the cores.
There are many daemons that require you to keep what you have in memory and just fail the particular action you are doing instead of throwing everything away. DB servers for example.
memory exhaustion is an error that should be handled like other errors.
in memqueue, http_respond logs the failed memory allocation(in http_cli_resp_hdr_create) and returns -1. there's nothing else I need to do in this case. The connection will get dropped without a response.
when reallocing, I don't see the integer wrap bug. Can you point me to the line?
What I am suggesting is to not overthink system error handling. Just handle it; aborting is one type of handling but not always what you want. Programs run in various environments and to guarantee a defined behavior we need to abide by the standard.