On Sat, 31 Jul 1999, Richard Phillips wrote:

>     I wasn't aware that parameter variables should NOT be dimensioned.  I have
> always DIMmed them.  After reading Derek's message I just assumed that I'd have
> to go back over the ten zillion routines I've written and eliminate the lines
> that dimension parameter variables.
>  
>     But then I remembered that when it comes to defining string variables, if a
> new string length is NOT defined using the "DIM" or "DEF LEN" instructions,
> then the most recently defined string length value is instead used.
>  
>     So what happens, for example, if the previously allocated string is defined
> at seven bytes in length (8 with length byte), but I need my "not to be DIMmed"
> parameter string to occupy a full 255 bytes long (256 with length byte)?
>  
>     Can I use the "DEF LEN" instruction to force a new length?  And if so,
> where do I place this instruction so that the compiler will "see" it BEFORE my
> parameter string is actually defined?
>  
>     Or did I miss Derek's point altogether and I'm concerned about a situation
> that doesn't exist?


Basically what I'm saying is that FB^3 won't let you do this.  You'll have
to change any redundant DIM statements.

A parameter that you define in a function doesn't have to be dimmed,
because FB makes room for it on the stack during the function setup at
runtime.  Its basically an implied Dim.

I must admit that I was quite confused about the thread dealing with
how string variables are passed interally in FB.  This is how it works:
If you pass a quoted string or string variable to a function, FB
*internally* passes the address to the target function.  Depending on if
you asked for a string variable or address, a local copy of the string is
made in the function's stack frame.  If you explicitly passed by address,
then you basically just end up with a long integer.  You get what you want
either way.  And you can't stop FB from passing the parameter however it
wants.  What exactly is there to complain about?  Do you really need low
level control over how strings are passed more than you do now?

Also I would like to mention that if you pass a string to a function, a
local copy is not directly placed on the stack, but rather its address.
Placing all the characters on the stack is fairly wasteful and would make
acessing the string extremely slow.  When FB makes a copy of the string,
you have an address locally that is different from the address of what you
passed in.

try this example:

Dim t$

local fn test (b$)
  print @b$
end fn

fn test (t$)
print @t$

You will get different values.  This proves FB makes a copy of the
variable.

-Derek