RE: ARGH!!! Pointers

[James Rich <james@xxxxxxxxxxx>]

On Thu, 30 May 2002, Scott Mildenberger wrote:

> The problem is that you are returning a pointer to a data structure that is
> defined locally to the subprocedure, the data structure goes away when the
> subprocedure ends.  You mainline code now has a pointer to memory that is

[snip]

> subprocedure.  You need to define the field globally if it is to exist after
> the call to the subprocedure, or you can define it as 'static' in the
> subprocedure.  A method to accomplish this is to define the data structure

Scott is correct about what is going wrong here.  I just want to add some
comments that help me get pointers right.

Someone else mentioned that using static is a sign of poor design.  I
agree with this.  While you certainly *can* use static you almost
certainly shouldn't.  Using static in this situation is more of a band-aid
than a real fix.

You also don't have to have the variable be global.  If you define the
variable in your main program then it will be global (because all
variables are global in the main program, probably for backwards
compatibility).  But the fact that a variable is global is not what fixes
this problem.  What fixes it is defining and allocating storage for a
variable and then passing the address of that variable to some other
subprocedure (which I'll refer to as functions since it takes less
typing and that's what every other language calls them).

Usually the definition of a variable and the allocation of storage for
that variable happen at the same time with one statement.  But pointers
enable you to define a variable without allocating storage for it.  That
makes for some very powerful and flexible programming, but you need to
know what is going on with the storage that you want your variable to
represent.

What you should be thinking when using pointers and function calls is,
"Here I have allocated some storage.  I am giving the address of my
storage to a function so that function can do some work with my storage."
What you program is thinking is, "Please do some magic to come up with
storage and do some work on it and then tell me where I can find that
storage the function created."  The calling function (whether it isthe
main program or not doesn't matter) needs to provide the space required
for the called functions to work in.  If you don't know how much you are
going to need that's fine, have the called function alloc some memory to
increase the storage that you have already prepared in the calling
function.  Called functions should return someone else's storage space,
never their own.

James Rich
james@eaerich.com