Re: why no palloc() ("permanent alloc")?

rahul <rahulsinner@xxxxxxxxx> writes:
On Jul 19, 9:03 pm, Bernie Ohls <Bernie.O...@xxxxxxx> wrote:
_want_ to free. Consider exporting an environment variable; this will
result in a malloc() call and be treated as a leak.
Can you elaborate?

When using putenv to add to the environment, the pointer passed as
argument is just inserted into the corresponding array. This means
that the space it is refering to must remain allocated for as long as
the new variables could still be used.

It strikes me that it would be a real benefit for a programmer to be
able to make the assertion "I'm allocating this memory and I do not plan
to free it; it needs to stick around until exit time." Such as a

These concepts have been implemented as garbage
collection in other languages viz. java, c# but do not exist
in C.

Some language runtime environments provide 'automatic memory
management'. The idea above was about adding a memory-allocating
subroutine whose semantics would imply that the allocated memory is
not going to be freed by the program for some reason. I fail to see a
connection between these two, except maybe as 'knee-jerk reaction' of
suggesting 'automatic memory management' as solution to any
conceivable memory management problem because it exists.

But without a sound technical reason to not use automatic memory
management of any sort, one should IMO spend some time asking oneself
why C is being used at all. Which would be a different discussion.

C was closely modelled around the low level stuff,

RISC processors (the ones I know of) where closely modelled in the way
C 'works'. But these didn't exist by the time C was invented and the
processors of these days had complex, unorthgonal instructions sets
intended to make it easy to program in assembly.

so both allocating and freeing memory is done by the
programmer(roughly simulating the functionality of the
machine).

That you may have some machine which 'roughly' simulates
problem-adapted memory management, mostly relying on an abundance of
memory and fast CPUs to plaster over its deficiencies (general purpose
memory allocation is still an unsolved research problem) does not
reverse-modify everything similar which existed before and alongsides
of it into 'a simulation of your machine'. A bicycle is not a
motorcycle with a human simulating the motor.

.

Relevant Pages

  • Re: C++ Garbage Collector on VMS?
    ... worry about memory management in a virtual memory OS design. ... The Language and the Language Run-Time is generally left holding the proverbial bag, if the bag isn't passed directly to the programmer. ...
    (comp.os.vms)
  • Re: C++ sucks for games
    ... > language, including plain english. ... > dangling reference crop up in my code. ... references and memory management is a bit of a red herring here. ...
    (comp.lang.lisp)
  • Re: Memory Management scares me
    ... I kind of regret not having gone into programming at that ... It wasn't so much the idea of memory leaks as the idea of ... > are the driving factors for selecting customized memory management. ... simply replicates the entire data structure on each iteration, ...
    (comp.lang.cpp)
  • Re: OT: Comparison of Unix systems and window managers
    ... tricks to get quite a lot of memory. ... couldn't afford more than 512K. ... but not really good memory management. ... so the Mac meets my needs admirably. ...
    (rec.crafts.metalworking)
  • Re: C++ sucks for games
    ... > mistakes it is possible for a programmer to make (although of course memory ... > references and memory management is a bit of a red herring here. ... you would use smart pointers too. ...
    (comp.lang.lisp)