[ProgClub list] Memory management in C

John Elliot jj5 at progclub.org
Sun Oct 2 04:27:38 AEDT 2011


On 2/10/2011 4:11 AM, Asher Glynn wrote:
> ... actually, MS wrote an experimental OS that was completely in .Net which,
> by the few people I know who actually saw it, was really, really good. But
> wouldn't have supported the old Win API so wasn't going anywhere.

Isn't that a shame?

I'm surprised Google hasn't released a desktop operating system yet.

I wonder if they just threw the /unsafe switch and did their own memory 
management. You don't actually need to use the GC in .NET -- did you know?

> IBM writes a lot of their mainframe operating systems in PL/X which is a
> variant on PL/I. OS/400 I believe has a bit in some OO variant of RPG.

Are either of those GC'ed?

> I'd personally be inclined to have a stab with Oberon (since they've
> developed an OS in it anyway), its Pascal derivative and supports some very
> nice features.

Pascal is such an ugly language, don't you think?

> And interestingly you probably wouldn't use many of C's defaults - I think
> its already been commented that its method of passing parameters is actually
> rather inefficient

What's wrong with how it passes parameters? How could you do better?

The method of passing parameters is basically to copy their values onto 
the stack, isn't it? (Is this ever averted by leaving them in registers? 
I understand that .NET can pass values in registers, but it probably has 
enough information to be able to do that, I'm not sure how a called 
function would know to check for a parameter in a register if you were 
calling a library function from C..?)

> as is its string representations, and its memory model
> is quite dangerous.

I vaguely remember hearing a remark once that having the stack grow down 
and the heap grow up (i.e. each toward the other) has been the source of 
most computer security related issues over the past few decades.

I'm still not sure how that works when you have multiple stacks. Because 
it's a pretty primitive view of an application to say that it has one 
stack that grows down and one heap that grows up. Often there will be 
multiple stacks, although I'm not sure where they all get located. My 
understanding of memory models is a little trite.

> You wouldn't use its default linking method either. This
> is kind of true for a lot of OSes that are "written in C" at any rate.

What's wrong with the linking model? (I don't remember anything about it).



More information about the list mailing list