How to share variables between two functions without declaring it a global variable in C language

Question

I've been reading through a lot of answers, and there are a lot of opinions about this but I wasn't able to find a code that answers my question (I found a lot of code that answers "how to share variables by declaring")

Here's the situation:

• Working with embedded systems
• Using IAR workbench systems
• STM32F4xx HAL drivers
• Declaring global variables is not an option (Edit: Something to do with keeping the memory size small, so local variables disappear at the end of scope but the global variable stay around. The local variables were sent out as outputs, so we discard them right away as we don't need them)
• C language
• in case this is important: 2 .c files, and 1 .h is included in both

Now that's out of the way, let me write an example.

file1.c - Monitoring

void function(){
    uint8_t varFlag[10]; // 10 devices
    for (uint8_t i = 0; i < 10; i++)
    {
        while (timeout <= 0){
            varFlag[i] = 1;
            // wait for response. We'll know by the ack() function
            // if response back from RX, 
            // then varFlag[i] = 0;
    }

file2.c - RX side

// listening... once indicated, this function is called
// ack is not called in function(), it is called when 
// there's notification that there is a received message
// (otherwise I would be able to use a pointer to change 
// the value of varFlag[]
void ack(uint8_t indexDevice)
{
    // indexDevice = which device was acknowledged? we have 10 devices
    // goal here is to somehow do varFlag[indexDevice] = 0
    // where varFlag[] is declared in the function()

}

Answer 1

You share values or data, not variables. Stricto sensu, variables do not exist at runtime; only the compiler knows them (at most, with -g, it might put some metadata such as offset & type of locals in the debugging section -which is usually stripped in production code- of the executable). Ther linker symbol table (for global variables) can, and often is, stripped in a embedded released ELF binary. At runtime you have some data segment, and probably a call stack made of call frames (which hold some local variables, i.e. their values, in some slots). At runtime only locations are relevant.

^{(some embedded processors have severe restrictions on their call stack; other have limited RAM, or scratchpad memory; so it would be helpful to know what actual processor & ISA you are targeting, and have an idea of how much RAM you have)}

So have some global variables keeping these shared values (perhaps indirectly thru some pointers and data structures), or pass these values (perhaps indirectly, likewise...) thru arguments.

So if you want to share the ten bytes varFlag[10] array:

• it looks like you don't want to declare uint8_t varFlag[10]; as a global (or static) variable. Are you sure you really should not (these ten bytes have to sit somewhere, and they do consume some RAM anyway, perhaps in your call stack....)?

• pass the varFlag (array, decayed to pointer when passed as argument) as an argument, so perhaps declare:

  void ack(uint8_t indexDevice, uint8_t*flags);
  

  and call ack(3,varFlag) from function...
  

  • or declare a global pointer:

    uint8_t*globflags;
    

and set it (using globflags = varFlag;) at the start of the function declaring varFlag as a local variable, and clear if (using globflags = NULL;) at the end of that function.

I would suggest you to look at the assembler code produced by your compiler (with GCC you might compile with gcc -S -Os -fverbose-asm -fstack-usage ....). I also strongly suggest you to get your code reviewed by a colleague...

PS. Perhaps you should use GCC or Clang/LLVM as a cross-compiler, and perhaps your IAR is actually using such a compiler...

Answer 2

Your argument for not using global variables:

Something to do with keeping the memory size small, so local variables disappear at the end of scope but the global variable stay around. The local variables were sent out as outputs, so we discard them right away as we don't need them

confuses lifetime with scope. Variables with static lifetime occupy memory permanently regardless of scope (or visibility). A variable with global scope happens to also be statically allocated, but then so is any other static variable.

In order to share a variable across contexts it must necessarily be static, so there is no memory saving by avoiding global variables. There are however plenty of other stronger arguments for avoiding global variables and you should read A Pox on Globals by Jack Ganssle.

C supports three-levels of scope:

• function (inside a function)
• translation-unit (static linkage, outside a function)
• global (external linkage)

The second of these allows variable to be directly visible amongst functions in the same source file, while external linkage allows direct visibility between multiple source files. However you want to avoid direct access in most cases since that is the root of the fundamental problem with global variables. You can do this using accessor functions; to use your example you might add a file3.c containing:

#include "file3.h"

static uint8_t varFlag[10]; 
void setFlag( size_t n )
{
    if( n < sizeof(varFlag) )
    {
        varFlag[n] = 1 ;
    }
}

void clrFlag( size_t n )
{
    if( n < sizeof(varFlag) )
    {
        varFlag[n] = 0 ;
    }
}

uint8_t getFlag( size_t n )
{
    return varFlag[n] == 0 ? 0 : 1 ;
}

With an associated header file3.h

#if !defined FILE3_INCLUDE
#define FILE3_INCLUDE

void setFlag( size_t n ) ;
void clrFlag( size_t n ) ;
uint8_t getFlag( size_t n ) ;

#endif

which file1.c and file2.c include so they can access varFlag[] via the accessor functions. The benefits include:

• varFlag[] is not directly accessible
• the functions can enforce valid values
• in a debugger you can set a breakpoint catch specifically set, clear or read access form anywhere in the code.
• the internal data representation is hidden

Critically the avoidance of a global variable does not save you memory - the data is still statically allocated - because you cannot get something for nothing varFlag[] has to exist, even if it is not visible. That said, the last point about internal representation does provide a potential for storage efficiency, because you could change your flag representation from uint8_t to single bit-flags without having to change interface to the data or the accessing the accessing code:

#include <limits.h>
#include "file3.h"

static uint16_t varFlags ;

void setFlag( size_t n )
{
    if( n < sizeof(varFlags) * CHAR_BIT )
    {
        varFlags |= 0x0001 << n ;
    }
}

void clrFlag( size_t n )
{
    if( n < sizeof(varFlags) * CHAR_BIT )
    {
        varFlags &= ~(0x0001 << n) ;
    }
}

uint8_t getFlag( size_t n )
{
    return (varFlags & (0x0001 << n)) == 0 ? 0 : 1 ;
}

There are further opportunities to produce robust code, for example you might make only the read accessor (getter) publicly visible and hide the so that all but one translation unit has read-only access.

Answer 3

Put the functions into a seperate translation unit and use a static variable:

static type var_to_share = ...;

void function() {
    ...
}

void ack() {
    ...
}

Note that I said translation unit, not file. You can do some #include magic (in the cleanest way possible) to keep both function definitions apart.

Answer 4

Unfortunately you can't in C.

The only way to do such thing is with assemply.