Hi Bart, > sbrk is a little deceiving here since it just administrates a > high-water mark and does not allocate memory from DOS: > old: > https://github.com/tkchia/newlib-ia16/blob/e7c08882834a41d848698a19deae49089c2dab17/libgloss/ia16/dos-sbrk.c > which only returned NULL if heap ptr went beyond 64K (the libc for > ia16-elf-gcc started very bare bones in this respect!) that should be fine then. however IIRC MSC sbrk() would (try to) expand the allocated DOS memory to grow the stack; this would not work well with command XMS-SWAP.
> new (just changed by TK Chia) > https://github.com/tkchia/newlib-ia16/blob/newlib-2_4_0-ia16-tkchia/libgloss/ia16/dos-sbrk.c > malloc returns NULL when the end of the heap is reached but this is > not always checked properly in freecom, but at least it does not grow > into the stack any more. > One could easily swap heap and stack in ia16-elf-gcc though I think we > would just see different memory corruption, stack can then go corrupt > other data or even code. possibly a misunderstanding by me: if the stack and heap have clearly defined, separate areas, you are absolutely right. (it made debugging somewhat easier that REN destroyed always the same data, but that's a minor detail). I had understood 'heap grows up toward stack' as some sort of optimization so that the heap can grow at the cost of stack and vice versa. > (that still leaves Turbo C which also grows heap to stack.. and of > course protected mode OSes do it but with virtual memory protection virtual memory stack protection is really cool (at least in the MSVC implementation which happens to be the only one that I am knowledgeable in); all stack checking without any cost. Tom _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
