🚀 go-pugleaf

In article <155@hslrswi.UUCP> brantsch@hslrswi.UUCP (Stefan Brantschen) writes:
>Has anybody ever had problems with malloc() (DRI C)?
>Consider the following piece of code:
>
>long free_mem;
>
>struct midi_event
>{ int delay;
>  char midi_msgs[3];
>} buffer;
>
>main()
>{
>  struct event *malloc();
>
>  free_mem = (long)malloc(-1L);
>
>  buffer = malloc(free_mem);
>
>/*  error handling ..... */
>
>  printf("%ld bytes free",free_mem);
>
>  ........
>  ........
>}
>
>What I get is "879000 bytes free" on a 1040 with a 600k RAM disk
>installed....????
>
>Any hint?
>
>Thanks		Stefan Brantschen
> 		...cernvax!hslrswi!hslraxe!brantsch



Its all DRI's fault. First they wrote a memory allocation mechanism for
the Atari's OS, which is the most weird mechanism i have seen sofar.
It works something like this:

	When an application has done it's startup Mshrink the OS calculates the
	amount of memory that's left. This amount is divided by 256 and an array
	of pointers to that number of 256 byte memory blocks is initialized.
	Every time you do a Malloc (not a C malloc) you will get a pointer
	to one of those 256 byte blocks. There's yet another setback in this 
	story: the maximum number of pointers is limited to about 512.

	So, when i ported MicroEmacs 3.7 to my ST i used Malloc instead of malloc
	(i thought it might be more efficient: i used Lattice C ). You can
	imagine what happened: Emacs wouldn't read files more than about 320
	lines. THE OS WAS OUT OF POINTERS, NOT OUT OF MEMORY.

So every C compiler has to have its own 'linked list' memory allocation
mechanism, and so has DRI-C. To find the amount of memory left in the system
use Malloc(-1L) instead of malloc(-1L). malloc(-1L) should be a request for
16Mbytes of memory !!. And if i remember right malloc of DRI WILL ONLY ACCEPT
SHORT ARGUMENTS (<= 32KBYTE REQUEST)


Gert Poletiek
Dutch National Intitute for High Energy Physics.
Amsterdam
The Netherlands.



Hope Atari will get decent OS writers one day.....