DISCLAIMER: All compilers are not created equal. Different compilers may achieve the same result, but may take different steps to achieve that result. Optimizers and code generators can do wonderful things. Thus, if you want to leave a comment and say “compiler XYZ does not do that,” that is fine, but that is not the point of this. This is for those “other” compilers you don’t use, that do not behave that way…

During my embedded C programming career, there are some interesting optimizations I have been taught. Most of these are things I would never consider on a modern C compiler running on a system that has ample memory and CPU resources. But when you are on a microcontroller with 4K or RAM or 16K of program storage, sometimes you have to do things oddly to make it fit, or, if the CPU is slow, make it run fast enough.

True, False, or Not True or Not False?

Consider this:

bool flag = false;

if (flag)
{
    // Do something
}

And “if” like this will be looking for a true result. Now, one compiler I work with has its own “TRUE” and “FALSE”, in uppercase, which all their code uses. Why? Maybe because they originated before the stdbool.h header file was added to the C standard and defined an official “true” and “false” in lowercase. Fortunately, they currently provide a stdbool which will undefine the uppercase ones (if the compiler is set to NON-case sensative — yep, by default “foo” and “FOO” and “else” and “Else” are processed the same) and define lowercase ones:

#if !getenv("CASE")
   // remove TRUE and FALSE added by CCS's device .h file, only if
   // compiler has case sensitivty off.

   #if defined(TRUE)
      #undef TRUE
   #endif
   
   #if defined(FALSE)
      #undef FALSE
   #endif
#endif

typedef int1   bool;
#define true   1
#define false  0
#define __bool_true_false_are_defined  

With 0 representing false, and 1 representing true, the “if” works — anything that is not 0 will be processed. In a normal compiler:

if (0)
{
    printf ("This will not print.\n");
}

if (1)
{
    printf ("This will print\n");
}

if (42)
{
    printf ("This will print\n");
}

On my Radio Shack Color Computer’s 6809 microprocessor, I expect such an “if” test compiles into assemble code that represents something like “branch if not zero”. I would expect every CPU has a similar instruction.

So checking for true (not 0) should be as fast as checking for false (0), assuming there is a similar instruction for “branch if zero.”

However, what if the CPU uses a different number of instruction cycles for a “branch if zero” versus “branch if not zero”? If that were the case, these might have different execution speeds:

if (flag == true)
{
    // Do something...
}

if (flag == false)
{
    // Do something...
}

But that seems unlikely, and is not the point of this post. (If you are aware of any CPU where this would be the case, please leave a comment.)

Some company coding standards I have used said to never use just “if (x)” but instead write out what it actually means. While you and I are experts and clearly know what the “if (x)” does, as should any programmer who knows programming, what if they don’t? In that case “if (x == true)” and “if (x == false)” are impossible to misunderstand, and should generate the same code as “if (x)” and “if (!x)”.

Right?

But suppose you used a crappy “C-like” compiler, and it had a “test for zero” which is used for “if (flag == false)” but used something dumb like “compare against a number” when you did “if (flag == true)” or “if (flag)”… Like, the compiler saw a check for 0 and knew it could efficiently do that… but if it was not zero, it did a compare against a number, resulting in something like…

load #1 in to some accumulator
compare register holding "flag" against accumulator
branch if equal (or if not equal)

That can generate some extra code each and every time you check for “true”, so checking for “not false” might save a few bytes every time.

Because of that, I often just default to doing this:

if (flag != false)
{
    // Do something...
}

And this looks stupid. But might save enough bytes to make something compile that otherwise would not fit.

Hopefully you have never had to work in such a constrained environment with such a crappy C-like compiler.

The good news is, by changing to doing this, it works the same on “real” compilers but “might” make smaller or faster code on bad compilers.

But I digress…

Adding it all up…

I really wanted to write this about something I had never considered:

#define HEADER_LENGTH 5
#define CRC_LENGH 2

unsigned int messageSize = HEADER_LENGTH + payloadLength + CRC_LENGTH;

If the message protocol uses a format like “[HEADER][PAYLOAD][CRC]”, writing out the C code like that makes it easy to visualize what the message bytes look like.

The compiler would be seeing that code as:

unsigned int messageSize = 5 + payloadLength + 2;

A compiler might be doing…

• Set messageSize to 5
• Add payloadLength to messageSize
• Add 2 to messageSize

But if you grouped the #define values together:

unsigned int messageSize = HEADER_LENGTH + CRC_LENGTH + payloadLength;

A good compiler might be changing that to:

unsigned int messageSize = 5 + 2 + payloadLength;
...
unsigned int messageSize = 7 + payloadLength;

…which results in:

• Set messageSize to 7
• Add payloadLength to messageSize

And if you deal with hundreds of messages where this might be calculated, that savings can really add up.

I would hope a real/smart compiler might be able to detect this and optimize the constants together … but I know this is not guaranteed to be the case.

The best thing about standards…

And as a bonus, earlier I posted asking about C coding standards trying to find one my employer could adopt, instead of rolling our own. Bing CoPilot led me to a few, including this one specifically for embedded C:

Embedded C Coding Standard | Barr Group

This “Barr C” standard has many things I have already forced myself to start doing, and does look promising. You can but a paperback book for the standard for $6 on Amazon, or download the book free as a PDF. I plan to go through it and see what all it discusses.

One thing I like about the approach is gives a reason for each of the coding standard things is presents. For example, braces:

Rules:

a. Braces shall always surround the blocks of code (a.k.a., compound
statements), following if, else, switch, while, do, and for statements; single statements and empty statements following these keywords shall also always be surrounded by braces.

b. Each left brace ({) shall appear by itself on the line below the start of the block it opens. The corresponding right brace (}) shall appear by itself in the same position the appropriate number of lines later in the file.

Reasoning:

There is considerable risk associated with the presence of empty
statements and single statements that are not surrounded by braces. Code constructs like this are often associated with bugs when nearby code is changed or commented out. This risk is entirely eliminated by the consistent use of braces. The placement of the left brace on the following line allows for easy visual checking for the corresponding right brace.

barr_c_coding_standard_2018.pdf

When I started learning C back in the late 1980s, it was the pre-ANSI K&R C. Thus, I learned C the way the books I had showed it:

if (something) {
   // Do something
} else {
   // Do something else
}

The placement of the “{” on the first line seems to be referred to as “line saver” in some of the code editors I use. It was at a job where their standard says “line them up so you can see what goes to what” that I had to change my style:

if (something)
{
   // Do something
}
else
{
   // Do something else
}

Now the start of each code block has the start brace and end brace on the same column, making it much easier to spot rather than having to look at the ends of lines or some characters in to a line.

I hated that at first, but now I am used to it.

I also used to do things like this:

if (something)
    DoSomething();
else
    DoSomethingElse();

Somewhere on this site, I have written about this at least once or twice. This breaks when someone adds something without thinking about the braces:

if (something)
    DoSomething();
    WriteToLog(); // added this
else
    DoSomethingElse();

Without the braces, trying to compile this would at least give an error:

main.c: In function ‘main’:
main.c:31:5: error: ‘else’ without a previous ‘if’
   31 |     else
      |     ^~~~

BUT, if you did not have the else…

if (something)
    DoSomething();
    WriteToLog();

That code might “look” good, but running it would do something if the case was true, but would then ALWAYS write to the log… Because C is seeing it like this:

if (something)
{
    DoSomething();
}

WriteToLog();

And I have now seen a modern programmer, brought up on scripting languages that made use of tabs rather than braces, make this mistake working on C code they were not really familiar with.

But I digress. Again.

More to come when my book arrives and I start reading through it. Unless someone presents me a better alternative, I think this one may suffice. The book is cheap, it can be downloaded free (so it is searchable) and the items I have spot checked seemed reasonable.

If you have ever worked with the Barr-C coding standard, I’d love to hear your thoughts in the comments.

Until then…

…you can never go back.

After being shown that you can declare a global variable, as one does…

int g_globalVariable;

…and then make it be treated as a read-only variable to other files by extern-ing it as a const:

extern int const g_globalVariable;

…of course I wondered what the compiler did if you went the other way:

// main.c
#include <stdio.h>

void function (void);

int const c_Value = 0;

int main()
{
    printf("Hello World\n");
    
    printf ("c_Value: %d\n", c_Value);
    
    function ();
    
    printf ("c_Value: %d\n", c_Value);

    return 0;
}

// function.c
#include <stdio.h>

// Extern as a non-const.
extern int c_Value;

void function ()
{
    c_Value++;
}

Above, main.c contains a global const variable, but function.c tries to extern it as non-const.

But when I run the code…

Hello World
c_Value: 0


...Program finished with exit code 139
Press ENTER to exit console.

…the compiler does not complain, but we get a crash. Looking at this in a debugger shows more detail:

Program received signal SIGSEGV, Segmentation fault.
0x00005555555551ef in function () at Function.c:11
11          c_Value++;

I am unfamiliar with the inner workings on whatever compiler this Online C Compiler – online editor is using, but I suspect I’d see similar results doing this on any system with memory protection. Go back to the early days (like OS-9 on a 6809 computer, or even on a 68000 without an MMU) and … maybe it just allows it and it modifies something it shouldn’t?

We can file this away in the “don’t do this” category.

Until next time…

I do not know why this has confused me so much over the years. BING CoPilot (aka ChatGPT) explains it so clearly I do not know how I ever misunderstood it.

But I am getting ahead of myself.

Back in 2017, I wrote a bit about const in C. A comment made by Sean Patrick Conner on a recent post made me revisit the topic of const in 2024.

If you use const, you make a variable that the compiler will not allow to be changed. It becomes read-only.

int normalVariable = 42;
const int constVariable = 42;

normalVariable = 100; // This will work.

constVariable = 100; // This will not work.

When you try to compile, you will get this error:

error: assignment of read-only variable ‘constVariable’

That is super simple.

But let me make one more point-er…

But for pointers, it is a bit different. You can declare a pointer and change it, like this:

char *ptr = 0x0;

ptr = (char*)0x100; 

And if you did not want the pointer to change, you might try adding const like this:

const char *ptr = 0x0;

ptr = (char*)0x100; 

…but you would fine that compiles just fine, and you still can modify the pointer.

In the case of pointers, the “const” at the start means what the pointer points to, not the pointer itself. Consider this:

uint8_t buffer[10];

// Normal pointer.
uint8_t *normalPtr = &buffer[0];
    
// Modify what it points to.
normalPtr[0] = 0xff;
    
// Modify the pointer itself.
normalPtr++;

Above, without using const, you can change the data that ptr points to (inside the buffer) as well as the pointer itself.

But when you add const…

// Pointer to constant data.
const uint8_t *constPtr1 = &buffer[0];
// Or it can be written like this:
// uint8_t const *constPtr1 = &buffer[0];

// You can NOT modify the data the pointer points to:    
constPtr1[1] = 1; // error: assignment of read-only location ‘*(constPtr1 + 2)
    
// But you can modify the pointer itself:
constPtr1++;

Some of my longstanding confusion came from where you put “const” on the line. In this case, “const uint8_t *ptr” is the same as “uint8_t const *ptr”. Because reasons?

Since using const before or after the pointer data type means “you can’t modify what this points to”, you have to use const in a different place if you want the pointer itself to not be changeable:

// Constant pointer to data.
// We can modify the data the pointer points to, but
// not the pointer itself.
uint8_t * const constPtr3 = &buffer[0];

constPtr3[3] = 3;

// But this will not work:
constPtr3++; // error: increment of read-only variable ‘constPtr3’

And if you want to make it so you cannot modify the pointer AND the data it points to, you use two consts:

// Constant pointer to constant data.

// We can NOT modify the data the pointer points to, or
// the pointer itself.
const uint8_t * const constPtr4 = &buffer[0];

// Neither of these will work:
constPtr4[4] = 4; // error: assignment of read-only location ‘*(constPtr4 + 3)’

constPtr4++; // error: increment of read-only variable ‘constPtr4’

Totally not confusing.

The pattern is that “const” makes whatever follows it read-only. You can do an integer variable both ways, as well:

const int constVariable = 42;

int const constVariable = 42;

Because reasons.

The cdecl: C gibberish ↔ English webpage will explain this and show them both to be the same:

const int constVariable
declare constVariable as const int

int const constVariable
declare constVariable as const int

Since both of those are the same, “const char *” and “char const *” should be the same, too.

const char *ptr
declare ptr as pointer to const char

char const *ptr
declare ptr as pointer to const char

However, when you place the const in front of the variable name, you are no longer referring to the pointer (*) but that variable:

char * const ptr
declare ptr as const pointer to char

Above, the pointer is constant, but not what it points to. Adding the second const:

const char * const ptr
declare ptr as const pointer to const char

char const * const ptr
declare ptr as const pointer to const char

…makes both the pointer and what it points to read-only.

Why do I care?

You probably don’t. However, any time you pass a buffer in to a function that is NOT supposed to modify it, you should make sure that buffer is read-only. (That was more or less the point of my 2017 post.)

#include <stdio.h>
#include <string.h>

void function (char *bufferPtr, size_t bufferSize)
{
    // I can modify this!
    bufferPtr[0] = 42;
}

int main()
{
    char buffer[80];
    
    strncpy (buffer, "Hello, world!", sizeof(buffer));
    
    printf ("%s\n", buffer);
    
    function (buffer, sizeof(buffer));
    
    printf ("%s\n", buffer);


    return 0;
}

When I run that, it will print “Hello, world!” and then print “*ello, world!”

If we do not want the function to be able to modify/corrupt the buffer (easily), adding const solves that:

#include <stdio.h>
#include <string.h>

void function (const char *bufferPtr, size_t bufferSize)
{
    // I can NOT modify this!
    bufferPtr[0] = 42;
}

int main()
{
    char buffer[80];
    
    strncpy (buffer, "Hello, world!", sizeof(buffer));
    
    printf ("%s\n", buffer);
    
    function (buffer, sizeof(buffer));
    
    printf ("%s\n", buffer);

    return 0;
}

But, because the pointer itself was not protected with const, inside the routine it could modify the pointer:

#include <stdio.h>
#include <string.h>

void function (const char const *bufferPtr, size_t bufferSize)
{
    // I can NOT modify this!
    //bufferPtr[0] = 42;
    
    while (*bufferPtr != '\0')
    {
        printf ("%02x ", *bufferPtr);
        
        bufferPtr++; // Increment the pointer
    }
    
    printf ("\n");
}

int main()
{
    char buffer[80];
    
    strncpy (buffer, "Hello, world!", sizeof(buffer));
    
    printf ("%s\n", buffer);
    
    function (buffer, sizeof(buffer));
    
    printf ("%s\n", buffer);

    return 0;
}

In that example, the pointer is passed in, and can be changed. But, since it was passed in, what gets changed is the temporary variable used by the function, similarly to when you pass in a variable and modify it inside a function and the variable can be changed in the function without affecting the variable that was passed in:

void numberTest (int number)
{
    printf ("%d -> ", number);
    
    number++;

    printf ("%d\n", number);
}

int main()
{
    int number = 42;
    
    printf ("Before function: %d\n", number);
    
    numberTest (number);
    
    printf ("After function: %d\n", number);

    return 0;
}

Because of that temporary nature, I don’t see any reason to restrict the pointer to be read-only. Any changes made to it within the function will be to a copy of the pointer.

In fact, even if you declare that pointer as a const, the temporary copy inside the function can still be modified:

void function (const char const *bufferPtr, size_t bufferSize)
{
    // I can NOT modify this!
    //bufferPtr[0] = 42;
    
    while (*bufferPtr != '\0')
    {
        printf ("%02x ", *bufferPtr);
        
        bufferPtr++; // Increment the pointer
    }
    
    printf ("\n");
}

Offhand, I cannot think of any reason you would want to pass a pointer in to a function and then not let the function use that pointer by changing it. Maybe there are some? Leave a comment…

The moral of the story is…

The important takeaway is to always use const when you are passing in a buffer you do not want to be modified by the function. And leave it out when you DO want the buffer modified:

#include <stdio.h>
#include <string.h>
#include <ctype.h>

// Uppercase string in buffer.
void function (char *bufferPtr, size_t bufferSize)
{
    while ((*bufferPtr != '\0') && (bufferSize > 0))
    {
        *bufferPtr = toupper(*bufferPtr);
        
        bufferPtr++; // Increment the pointer
        bufferSize--; // Decrement how many bytes left
    }
}

int main()
{
    char buffer[80];
    
    strncpy (buffer, "Hello, world!", sizeof(buffer));
    
    printf ("%s\n", buffer);
    
    function (buffer, sizeof(buffer));
    
    printf ("%s\n", buffer);

    return 0;
}

And if you pass that a non-modifiable string (like a real read-only constant string stored in program space or ROM or whatever), you might have a different issue to deal with. In the case of the PIC24 compiler I use, it flat out won’t let you pass in a constant string like this:

function ("CCS PIC compiler will not allow this", 80);

They have a special compiler setting which will generate code to copy any string literals into RAM before calling the function (at the tradeoff of extra code space, CPU time, and memory);

#device PASS_STRINGS=IN_RAM

But I digress. This was just about const.

Oddly, when I do the same thing in the GDB online Debugger, it happily does it. I don’t know why — surely it’s not modifying program space? Perhaps it is copying the string in to RAM behind the scenes, much like the CCS compiler can do. Or perhaps it is blindly writing to program space and there is no exception/memory protection stopping it.

Well, it crashes if I run the same code on a Windows machine using the Code::Blocks IDE (GCC compiler).

One more thing…

You could, of course, try to cheat. Inside the function that is passed a const you can make a non-const and just assign it:

// Uppercase string in buffer.
void function (const char *bufferPtr, size_t bufferSize)
{
    char *ptr = bufferPtr;
    
    while ((*ptr != '\0') && (bufferSize > 0))
    {
        *ptr = toupper(*ptr);

        putchar (*ptr);
        
        ptr++; // Increment the pointer
        bufferSize--; // Decrement how many bytes left
    }

    putchar ('\n');
}

This will work if your compiler is not set to warn you about it. On GCC, mine will compile, but will emit a warning:

main.c: In function ‘function’:
main.c:16:17: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
   16 |     char *ptr = bufferPtr;

For programmers who ignore compiler warnings, you now have code that can corrupt/modify memory that was designed not to be touched. So keep those warnings cranked up and pay attention to them if your code is important.

Comment away. I learn so much from all of you.

Even though I first started learning C using a K&R compiler on a 1980s 8-bit home computer, I still feel like I barely know the language. I learn something new regularly, usually by seeing code someone else wrote.

There are a few common “rules” in C programming that most C programmers I know agree with:

• Do not use goto, even if it is an intentional supported part of the language.
• Do not use globals.

I have seen many cases for both. In the case of goto, I have seen code that would otherwise be very convoluted with nested braces and comparisons solved simply by jumping out of the block of code with a goto. I still can’t bring myself to use goto in C, even though as I type this I feel like I actually did at some point. (Do I get a pass on using that, since it was a silly experiment where I was porting BASIC — which uses GOTO — to C, as literally as possible?)

But I digress…

A case for globals – laziness

Often, globals are used out of sheer laziness. Like, suppose you have a function that does something and you don’t want to have to update every use of it to deal with a parameter. I am guilty of this when I needed to make a function more flexible, and did not have time to go update every instance and use of the function to pass in a variable:

void InitializeCommunications ()
{
     InitI2C (g_Kbps);
}

In that case, there would be some global (I put a “g_” the variable name so it would be easy to spot as a global later) containing a baud rate, and any place that called that function could use it. Changing the global would make subsequent calls to the function use the new baud rate.

Bad example, but it is what it is.

A case for globals – speed

I have also resorted to using globals to speed things up. One project I worked on had dozens of windows (“panels”) and the original programmer had created a lookup function to return that handle based on a based in #define value:

int GetHandle (int panelID)
{
   int panelHandle = -1;

   switch (panelID)
   {
      case MAIN_PANEL:
         panelHandle = xxxx;
         break;

      case MAIN_OPTIONS:
         panelHandle = xxxx;
         break;
...etc...

Every function that used them would get the ID first by calling that routine:

handle = GetHandle (PANEL_MAIN);

SetPanelColor (handle, COLOR_BLUE); // or whatever

As the program grew, more and more panels were added, and it would take more and more time to look up panels at the bottom of the list. As an optimization I just decided to make al the panel handles global, so any use could just be:

SetPanelColor (g_MainPanel, COLOR_BLUE); // or whatever

This quick-and-dirty change ended up having about a 10% reduction in CPU usage — this thing uses a ton of panel accesses! And it was pretty quick and simple to do.

Desperate times.

An alternative to globals

The main replacement I see for globals are structures, declared during startup, then passed around by pointer. I’ve seen these called “context” or “runtime” structures. For example, some code I work on creates a big structure of “things” and then any place that needs one of those things accesses it:

InitI2C (runTime.baudRate);

But as you might guess, “runTime” is a global structure so any part of the code could access it (or manipulate it, or mess it up). The main benefit I see of making things a global structure is you have to know what you are doing. If you had globals like this:

// Globals
int index = 0;
int baudRate = 0;

…you might be surprised if you tried to use a local variable “index” or “baudRate” and got it confused with the global. (I actually ran in to a bug where there was a global named simply “index” and there was some code that had meant to have a local variable called “index” but forgot to declare it, thus it was always screwing with the global index which was used elsewhere in the code. This was a simple accident that caused alot of weird problems before it was identified and fixed.

Prepending something like “g_index” at least makes it clear you are using a global, so you could have a local “index” and not risk messing up the global “g_index”.

To me, using that global runtime structure is just a slower way to do that, since in embedded compilers I have tested, accessing a global something like “foo.x” is slower than just accessing a global “x”. I have also seen it to take more code space, and I had to remove all such references in one tightly restrained product to save just enough bytes to add some needed new code.

Yes, I have ran in to many situations where a tiny bit of extra memory space or a tiny bit of extra code space made the difference between getting something done, or not.

A cleaner approach?

Ideally, code could pass around a “context” structure, and then nothing could ever access it without specifically being handed it. Consider this:

int main ()
{
   int status = SUCCESS;

   // Allocate out context:
   RunTimeStruct runTime;

   ...

   status = StartProgram (&runTime);

   return status;
}

int BeginProgram (RunTimeStruct *runTime)
{
    InitializeCommunications (runTime->baudRate);

    status = DoSomething (runTime);

    return status;
}

The idea seems to be that once you had the runTime structure, you could pass in specific elements to a function (such as the baud rate), or pass along the entire context for routines that needed full access.

This feels like a nice approach to me since passing one pointer in is fast, and it still offers protection when you decide to pass in just one (or a few) specific items to a function. No code can legally touch those variables if it doesn’t have the context structure.

But what about globals that aren’t globals?

And now the point of this article. Something I learned from this project was an interesting use of “globals” that were not globals. There were functions that declared static structures, and would return the address of the structure:

RunTimeStruct *GetRunTimeData (void)
{
   static RunTimeStruct runTimeDate;

   return &runTimeData;
}

Now any place that needed it could just ask for it:

RunTimeStruct *runTime = GetRunTimeData (); 

runTime->baudRate = 300;

This seems like a hybrid approach. You can never accidentally use them, like you might with just a global “int index” or whatever, but if you did, you could get to them without needing a context passed in. It seems like a good compromise between safety and laziness.

It also means those functions could easily be adapted to return blocks of thread-safe variables, with a “Release” function at the end. (This is actually how the thread-safe variables work in the LabWindows/CVI environment I use at my day job.)

RunTimeStruct *runTime = GetRunTimeData (); 

runTime->baudRate = 300;

ReleaseRunTimeData ();

What do you do?

Since I like learning, I thought I’d write this up and ask you what YOU do. Show me your superior method, and why it is superior. I’ve seen so many different approaches to passing data around, so share yours in a comment.

Until next time…