Libraries must not abort on malloc failure.

[GoogleCodeExporter]

If we want applications to use libproxy, we shouldn't make it abort the
application on failures -- it should return an error.

Original issue reported on code.google.com by dwmw2b@gmail.com on 30 Dec 2009 at 2:30

[GoogleCodeExporter]

Abort on allocation failure is pretty common.  I'm of the opinion that it is 
the only sensible option. Is it a 
problem for a specific application?

Original comment by npmccallum@gmail.com on 30 Dec 2009 at 2:55

[GoogleCodeExporter]

It's a problem for any application which doesn't want to just _crash_ on a
remotely-triggerable failure. Any application which wants to clean up after 
itself,
or to display an error message to the user, or for which HTTP access isn't
mission-critical and it would be better off just copying with the error and
continuing with its _real_ task, whatever that is.

It's not as if it's hard to just return an error to the caller and let the 
caller
decide what to do. We shouldn't be making this kind of policy decision on 
behalf of
the applications.

Especially if we're trying to get _all_ applications to use libproxy to get a
consistent behaviour across an entire distribution. I'm working on getting 
libproxy
used consistently across Moblin, and was going to work on Fedora next. (I've 
fixed
yum already). But I can't in good faith put libproxy into all HTTP-using
applications, if it has this kind of problem.

Original comment by dwmw2b@gmail.com on 30 Dec 2009 at 4:21

[GoogleCodeExporter]

I agree it is a critical bug.

Bastien

Original comment by roucarie...@gmail.com on 14 Jan 2010 at 1:42

[GoogleCodeExporter]

dwmw2,

This should be fixed in trunk (via the port to C++).  Using the C++ API, you'll 
get a
bad_alloc exception.  The C API should return NULL.  Please let me know if you 
have
any difficulties.

Original comment by npmccallum@gmail.com on 22 Jan 2010 at 7:12

• Changed state: Fixed