FB II Compiler







Disk I/O














Made with FB


Know where the variables are localised

Local variables in a FN are in existence until you hit that function's END FN statement; in particular, it's OK to pass a pointer to local variable(s) _into_ another FN; the "outer" function's variables are all still intact and available while the "inner" function executes.

If your data is located, say, in a handle-type block, then that block is accessible (to any function) until you explicitly dispose of it. In that case, the block could be valid even _after_ the END FN statement.

Lucy replied:
<< Would that apply to regions? As in:... >>

Yes, your region exists intact until you call DISPOSERGN. Regions (and in fact anything that's stored in a handle-type block) are stored in a completely different area of memory from things like program variables.
Program variables are stored in an area of memory called the "stack," and their space is automatically allocated when you enter a function and automatically disposed when you exit the function. On the other hand, "relocatable blocks" (which is another name for a block that's referenced by a handle) are stored in an area of memory called the "heap." No automatic allocation nor disoposing for those: you have to explicitly allocate their memory via some statement (such as FN NEWRGN), and the memory remains allocated until you explicitly dispose of it via some other statement (such as DISPOSERGN).

<< My explorations in Macsbug last fall led me to a slightly different conclusion. It's true that local _arrays_ are put on the stack, but it looks to me as if other local variables are in a handle (locked during FN execution) located in the heap. >>

I tried tracing a simple function through MacsBug just now, and it still looks to me as though non-array local variables are on the stack. My test function has 6 short-integer variables (comprising a total of 12 bytes). One of the first things the function does is subtract 12 from the stack pointer (A7), essentially reserving 12 bytes on the stack. It then copies A7 to A6. From then on, it refers to all the local variables as offset from A6 (the offsets ranging from 0 bytes to 10 bytes), which means they're all within that 12-byte area of reserved stack space.

Now the stack can _also_ be within a Heap Zone, but I don't think that's considered part of the application's "heap." (In my previous message I pretended there was just one "heap" so as not to complicate the issue.)
In fact, when I did a "WH" command to locate my 6 variables, I found that they were in a locked relocatable block within the Process Manager Heap (but far from the block's beginning). Yet they were _also_ "on the stack," because the stack pointer itself pointed to an address within that block!

So I think the real story is that the Process Manager heap zone can contain a relocatable block which _itself_ is a (smaller) heap zone which contains the whole application--including the application's heap, the application's stack, and the application's globals. So you can have blocks within blocks. But this makes my head swim, so I usually just think of one "heap" at a time. :-)