Re: FindFirstFile Possible Memory Leak

Don't take my outline too literally. The 'addition' to the stack for
internal blocks takes place during the build not at runtime. And not all
compilers worked the same way. Loop optimization and deeper parsers for
this
as well as other conditions soon changed the landscape.

As you say Ralph, for compiler variables that stack data is only
added/removed once for that local block, not on each invocation. Hence, a
plain {...} is no different from a Do{...} in that respect.

However, had it been accumulative, it should only be a matter of moving the
stack pointer (ignoring the need for any initialisation of course). I only
mention this because I had a great deal of experience with a little-used C
function called alloca (some other languages had a similar concept too).
This was suppose to allocate a local buffer on the stack and return its
pointer. It was *extremely* quick, and no explicit deallocation was needed
as stack variables are automatically destroyed when the current procedure
returns.

Well, that was the theory anyway. It works great on architectures with a
proper base pointer (BP) or frame pointer (FP) type of register. In those
architectures, the stack pointer (SP) can be changed without losing your
return address or losing any compiler-generated variables. Unfortunately,
some architectures elected to not provide one for reasons of efficiency (it
meant another register to save/restore), and some heroic compiler
optimisations even ignored those registers (when available) and invented
their own call conventions.

Now for the ironic part. This meant that for portability, you probably had
to ignore alloca and so use much slower alternatives. For instance,
allocating from the normal heap could be 50-100 times slower.On the worst
architectures (e.g. HP) where there was no concept of a BP/FP, there were
some purely s/w implementations of alloca available that used the heap
behind your back -- these were worse than useless because of the massive
performance difference. I also heard that some important standard benchmarks
relied on alloca, and it was a contentious issue. So, as a result of trying
implementing highly optimised h/w, or compiler code generation, some
architectures actually ended up less capable. Hah!

Tony Proctor

"Ralph" <nt_consulting64@xxxxxxxxx> wrote in message
news:%23jmCwjfrHHA.2368@xxxxxxxxxxxxxxxxxxxxxxx

"Robert Morley" <rmorley@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:%237ylDSfrHHA.884@xxxxxxxxxxxxxxxxxxxxxxx
I see your point here, though in the end, I'm in agreement with Rick and
Bob
on this one.


And why not? <g>

Wirth and Dijkstra weren't dummies - Formal restrictions and Top-Down
programming works.


It's interesting what you say about adding to the stack during
the execution of the procedure, as it has the advantage of only
consuming
as
many resources as necessary, but the obvious disadvantage that you have
to
run code each time to allocate more memory, do whatever maintenance is
required, etc., instead of just doing it once at the beginning of the
function call. If you accidentally do this in a loop, there would be
some
very significant performance hits, I would imagine.


Don't take my outline too literally. The 'addition' to the stack for
internal blocks takes place during the build not at runtime. And not all
compilers worked the same way. Loop optimization and deeper parsers for
this
as well as other conditions soon changed the landscape.


Of course, as I've mentioned before, I really found Pascal to my liking
"back in the day"...the structure of it really appealed to me. So it
shouldn't be any wonder that I still tend to think and work in those
terms.


Again, why not? Wirth wasn't a dummy. At least Pascal was designed - Basic
sort of just grew. <g>

-ralph

<snipped>




.

Relevant Pages

  • Re: What is a stack frame?
    ... There is no need for a separate "this frame" pointer. ... In any case, the more general term, which covers what a C compiler ... hardware-provided stack to implement the stack-like data structure ... manner since the current stack frame is "deformed" by alloca. ...
    (comp.lang.c)
  • Re: Criticisms?
    ... VLAs give you more than just that one particular feature. ... For alloca() to be reliable, the compiler has to recognize calls ... problem is that each allocacall adjusts the stack while the ...
    (comp.lang.c)
  • Re: alloca
    ... a compiler can decide to _always_ perform the calls to ... That's just another way to circumvent the potential problem with using 'alloca' in an argument list. ... A quality implementation might perform a run-time stack integrity check in debug configuration and trigger a run-time diagnostic. ... Although I don't direct connection to the 'alloca' being standard or not. ...
    (comp.lang.c)
  • Re: FindFirstFile Possible Memory Leak
    ... for compiler variables that stack data is only ... function called alloca. ... This was suppose to allocate a local buffer on the stack and return its ... architectures, the stack pointer can be changed without losing your ...
    (microsoft.public.vb.general.discussion)
  • Re: Do buffers always start with the lowest memory address being the first element?
    ... > The C standard does not assume a downward-growing stack, ... > an upward-growing stack. ... C allows but does not require that the array produced ... > machine depends on both the C compiler and the machine. ...
    (comp.lang.c)