Re: FindFirstFile Possible Memory Leak


"Tony Proctor" <tony_proctor@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:ukwklXprHHA.1204@xxxxxxxxxxxxxxxxxxxxxxx
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

<snipped>

wow! Does that take me back.

I started as a C programmer in 1977 (my brag has always been I was doing C
before the book. <g>), and after a few years I felt I had a better than
average knowledge of compiler basics - Unfortunately I was predominately
self taught, thus my knowledge contain large holes filled with absolute
cluelessness. <g> I knew the effects, but not necessarily why?

At the time, for PC development, I was using MS C 5.1 which was a damn fine
optimizing compiler compared to the others out there. Then I discovered
Watcom and began to wonder why its optimizations were better. So I started
on a two-year adventure into the world of "optimizing compilers". (Luckily I
was working for an Engineering company at the time, so they actually cared.
<g>)

I remember starting out rather smug. After all, it would only be a matter of
reading up on the subject. <bg>

After stacks and stacks of INTEL papers, ACMs, reams of fan-fold, dozens of
seminars, cases of Coke, and galleon cans for ash trays. I became wiser.
There are still large areas of "ignorance" but at least I knew what I didn't
know. <g>

-ralph



.