Passing arrays as global variables instead of pointers in C

Question

I'm required to write the Low-Level Requirements of a Software Component which shall perform signal processing over arrays of 200k elements of integers/floats which lives in the main memory of the program. The program is single thread.

The software shall be certified in the context of DO 178-C (DAL-A).

The signal processing unit will expose functions like these that will be re-used as needed by the rest of the software:

- low_pass_signal_filter
- element_by_element_vector_multiplcation
- ...

We also are based on MISRA-C 2012 to develop in-house Software Code Standard which actually, allows the use of pointers, but pointers to pointers are disallowed.

Rationale about the use of pointers

In the book "Developing Safety Critical Software", by Leanna Rierson she says:

Page 172:

"Recommendation 9: Ensure the software is deterministic. Safety-critical software must be deterministic; therefore, coding practices that could lead to non-determinism must be avoided or carefully controlled (e.g., self-modifying code, dynamic memory allocation/deallocation, dynamic binding, extensive use of pointers, multiple inheritance, or polymorphism). Well-defined languages, proven compilers, limited optimization, and limited complexity also help with determinism."

And also, in page 172:

"1. Minimize the use of pointers. Pointers are one of the most error-prone areas of programming. I cannot even begin to describe the hours I have spent tracking down issues with pointers—always"

Also, in the book "Embedded Software Development for Safety-Critical Systems" by Chris Hobbs, says at page 255:

"At one end of the spectrum, C’s extensive use of pointers, particularly function pointers, makes static analysis very difficult"

Proposal Solution

Furthermore, I've explored so many ideas, and now I'm just exploring the possibility to avoid passing pointers arguments at all to that library, and then just set and fetch data from a dedicated global array.

Here is a simplified example where I have taken the license to condense two files into one single translation unit for simplicity.

Do you think I should continue exploring this way, or rather stick to pointer parameters as usual?

#include <stdio.h>

/* library.c */

#define MAX_SIZE 10

static int g_input  [ MAX_SIZE ] = { 0 };
static int g_output [ MAX_SIZE ] = { 0 };

extern void process_input ( const int n )
{
    /* process g_input and writes into g_output */
    for ( int i = 0; i < ( n < MAX_SIZE ? n : MAX_SIZE ); i = i + 1 )
    {
      g_output [ i ] = g_input [ i ] * g_input [ i ];
    }

}


/* main.c */
#define SRC_SIZE 4

int main ( void )
{
    int src [ SRC_SIZE ] = { 0, 1, 2, 3 };

    for ( int i = 0; i < (SRC_SIZE < MAX_SIZE ? SRC_SIZE : MAX_SIZE); i = i + 1 )
    {
        g_input [ i ] = src [ i ];
    }

    process_input( SRC_SIZE );

    int dst [ SRC_SIZE ];

    for ( int i = 0; i < (SRC_SIZE < MAX_SIZE ? SRC_SIZE : MAX_SIZE); i = i + 1 )
    {
        dst [ i ] = g_output [ i ];
    }

    for ( int i = 0; i < (SRC_SIZE < MAX_SIZE ? SRC_SIZE : MAX_SIZE); i = i + 1 )
    {
      printf( "%d\n", dst [ i ] );
    }

    return 0;
}

Answer 1

We also are based on MISRA-C 2012 to develop in-house Software Code Standard which actually, allows the use of pointers, but pointers to pointers are disallowed.

This means that it is fully allowed to use variables or arguments of the type int*, but that you should not use the type int** (or with even higher levels of indirection).

The reason for this restriction is that with higher levels of indirection, it becomes increasingly harder for a human to reason about the correctness of the code where those pointers-to-pointers are being used. For a single level of indirection, it is still well doable for an average programmer to reason about the code and understand if it contains flaws or not.

Incidentally, there is also a (negative) relation between the size of the (total) codebase and how easy it is to reason about the correctness in the presence of global variables. When global variables are used, especially when they can be accessed from multiple functions or even multiple modules, it becomes increasingly harder to make sure that those functions do not tread on each other's toes.

"Recommendation 9: Ensure the software is deterministic. Safety-critical software must be deterministic; therefore, coding practices that could lead to non-determinism must be avoided or carefully controlled (e.g., self-modifying code, dynamic memory allocation/deallocation, dynamic binding, extensive use of pointers, multiple inheritance, or polymorphism). Well-defined languages, proven compilers, limited optimization, and limited complexity also help with determinism."

And also, in page 172:

"1. Minimize the use of pointers. Pointers are one of the most error-prone areas of programming. I cannot even begin to describe the hours I have spent tracking down issues with pointers—always"

The most important part of this recommendation is the first part, which bears repeating: Ensure the software is deterministic. Everything after it should be weighed against other good programming practices, like avoiding modifiable global data, and the idioms and limitations of the programming language you use.

In C, putting a total ban on the use of pointers is likely to be counter-productive for the aim of creating deterministic software. You can restrict the use of pointers, but they are still the best or only solution for supporting out-parameters and for passing around largish data structures, including arrays.

Answer 2

Most people consider globals bad when used in libraries, because that imposes restrictions on how you can use the library in various programs. Libraries usually are more parameterized, using dynamic arguments rather than globals and constants. It makes them more flexible.

Consider if your program needs to grow to handle multiple client connections, for example. Threads, etc. Do you want to re-write your library(-ies) in order to do this?

It's easier to use a more carefully crafted library in a simple single-task program than the converse. The reason you even call it a library implies some amount of portability or re-use is being considered, and thus it's worthy of a bit more care in the crafting. Otherwise it's just another chunk of your program.

I have personally had to refactor many would-be libraries into code that had less globals and #DEFINE constants in them, in order to suit the new target environment.

Answer 3

Coding and testing to DAL A is hard enough without adding more complications. MISRA-C is a recognised industry standard coding guideline. If you're going to adopt it, then don't try to adopt other peoples' ideas of what's good or bad as well, as you will only make life harder for yourself.

As part of the certification evidence, you will need to draw up a set of coding guidelines, and show how you meet them. It's much easier if your guidelines are primarily "follow MISRA-C", rather than a collection of different people's ideas gathered from across the internet.

Answer 4

Yes, the rules are contradictory, so throw them out - not arbitrarily - until you get something logically coherent and actionable. You can't act on logically inconsistent rules, so you have to change/adapt them; no other way around it, your gut is right.

In this case I'd say compromise in favor of pointers. Beyond null reference as a possibility, pointers aren't too bad so long as all you do is dereference them. It gets more problematic when you start, say, trying to do pointer arithmetic, and keep in mind that indexing (i.e. "p[3]") is a form of pointer arithmetic, in effect. Pointer arithmetic is a problem because you can risk an out-of-bounds memory access. Without it, pointers aren't much different from a nullable reference in "safer" languages like Java. Heck, if you want to be really paranoid, wrap the pointers in a macro like "DEREF(p)", which means any pointer access NOT wrapped in that macro can be default-regarded as sus, and it's also possible to easily search for all legitimate pointer dereference usages.

If you compromise in favor of global variables, on the other hand, you very easily will create a maintainability mess because global variables pass state between things in a hidden fashion. Once you lose track in your head or a teammate loses track in their head of how the globals interact when different function calls involving them come into play, or an implementation changes, or anything like that, BAM, it will break and not only will it break, but you will have a heck of a time trying to track down the bug.