Re: What to do when malloc() returns 0?

Hi

> Currently, a 0 return from malloc() is considered a fatal
> error throughout wwwlib. The error is reported to stderr,
> and the process exits.

It's not to say that it's the right way to do it but I havn't seen any
program not starting to behave strangely when the memory limit is
reached: the mouse disappers, windows start blinking, keyboard dies
etc.

> 	E. Support "malloc failed" return code throughout the library
> 		- requires significant library reengineering
> 		- error prone
> 		- requires library clients to do lots of error checking
> 		+ suitable for use in robust applications

:-( This is what I have been reading in every `how to be a good
programmer' book. In practice I have _never_ seen return codes used in
a consistent manner - especially when they are a result of something
that happened more than one level below the current function.

> 	C. Raise an exception -- export exception API to library
> 			clients
> 		- requires significant library reengineering
> 		- requires integration of external technology
> 			(who's exception package do we use?)
> 		- requres library clients to use exceptions API
> 		+ allows robust editing applications to use the library
> 
> 	D. Raise an exception, catch it before exiting the API,
> 		return an error code
> 		- requires significant library reengineering
> 		- requires integration of external technology
> 			(who's exception package do we use?)
> 		- requires distinction between "public" API and
> 			"internal" API
> 		- requires library clients to do lots of error checking
> 		+ suitable for use in robust applications

:-( I don't like exceptions in the library due to portability problems -
sorry for saying this word again ;-)

> 	B. Call fatal-exit hook function
> 		+ easy to code
> 		+ allows editing apps to do "last ditch save"
> 		+ allows graceful exit on small-memory machines
> 		- still unsuitable for integration with otherwise
> 			robust apps

:-) This is what I would call to take the easy way out. However, I
think it is the most realistic way right now. Two reasons: The library
is not consistent enough at the moment to have a very suffisticated and
gracefull exit on problems like this. Secondly, I think that once a
memory problem has occured new ones are likely to appear very soon
after. If we can prevent loss of data using a call back function then I
think it is a good and simple step to do.

Another thing: I don't like malloc at all. We have had so many problems
with uninitialized memory when allocating structures etc. in the
Library. The only way to avoid this is to use calloc. Any memory
problems are then a lot easier to find as they always dump core on UNIX.

The new multi-threaded HTTP client has another way of using memory. All
information necessary to fulfill a request is stored in HTRequest and
HTNetInfo structures. Nothing is freed until the request is done
(success or failure). As all the protocol modules now are state
machines it makes it easier to handle fatal error such like lack of
memory as it then is a question of jumping into an error state. This
might also be used in other parts of the library.

*******

OK - to summarize the working list for version 3.0:

	- Better handling of malloc (calloc)
	- free static memory on exit
	- replacement of verbose output to stderr
	- Integration of DOS (system dependent stuff etc.)
	- take a look at all system calls
	- Better SGML/HTML parsing
	- Better MIME parsing
	- Multi threaded HTTP client (alpha version exists)
	- Cleaning up include files
	- chop filenames to 8.3 format for DOS
	- Introduction of PUT and POST (specification exists)
	- FORMs support in the library
	- canonicalising URLs so that
	
		www.fit.qut.edu.au = www.fit.qut.edu.au:80 = www.fit.qut.edu.AU

	  etc. all have the same anchor
	- and some minor stuff on my list...

DID I MISS ANYTHING??? I will put the items onto a WEB page one of these days.

However, as I said in my last mail - I need to write my thesis _*NOW_*
so I can't do any work on the library the next 2-3 weeks. So - please
bear with me...

-- cheers --

Henrik Frystyk

Received on Thursday, 21 July 1994 16:15:04 UTC