There is no 'nice' solution to what you are attempting.  It flies against the
idea of programming in C.

If, as you indicate, this secondary function only applies to the primary
function, then why don't you simply inline it.  It will have access to all the
variables (static or otherwise) that the primary has.  You can use control
stuctures to manipulate it just as you would if it were a seperate function.

Is there a compelling reason to seperate these two procedures?

-Adam

Mike Harrison wrote:
>
> Am I right in thinking there is no 'nice' solution to this C
> problem..?
>
> I want to have a procedure which can access a local variable of its
> caller. The procedure is only ever called by the one calling
> procedure, so the address of that local variable is known at compile
> time.
>
> e.g. :
>
> void subproc(a);
> {b+=a;} // I want 'b' to be proc1's local 'b'
>
> void proc1()
> {int b=0;subproc(1);subproc(2);}
>
> Obviously this is a trivial example, but a decimal-number print
> routine is a good example of where this would be useful, as is
> anywhere that you have a few sections of arbitary, identical code you
> want to turn into a procedure to save memory.
> This is purely a code-size issue - I realise could pass subproc a
> pointer to b, but that wastes code space as it will always be the
> same. Returning the updated value would be another way, again wasteful
> and not viable if subproc accessed more than one variable..
>
> I could make b global but that partly defeats the point of having a
> high-level language do all the data memory allocation, makes the code
> less readable, and wastes data memory if I dedicate a global to it.
> This can easily be done in Pascal with nested procs, but as far as I
> can see you can't do it in C - can someone prove me wrong ?
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.