Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Most C programmers, even beginners, would claim that arrays are easy, except those abundant off-by-one errors and they are right. Arrays are easy indeed. However, here are a few points to consider when writing a program that needs a rather large array (By the way, the thought for this article came into mind while helping a colleague to resolve an error a couple of days ago). When creating a large array (e.g. something like int a[1000][1000], which BTW takes up around 3.8 MB on most machines), you might not have any issue at all or might see either a compile time error or worse, runtime errors.
Why do these errors happen? Depending on your machine’s limitations you are most probably consuming the total available stack (if you used a local variable) or data memory. Depending on your compiler, these might be flagged at compile time or surface when you try to run your program. Or it might be that your compiler isn’t able to work with large arrays. What you can do to alleviate these:

• The first and best way is to minimize your array size (This makes for an amazing example here from the bookd “Programming Peals”: http://www.cs.bell-labs.com/cm/cs/pearls/cto.html )
• Use “huge” memory model.
• Use a global variable (or a static variable if you are particular about its visibility to the rest of the program). The stack is generally quite limited as compared to the data memory available to a program. So, a variable with static storage would ensure that you use memory from the data segment.
• Don’t declare it as an array at all and instead use a pointer and dynamically allocate the memory required for it. You might have to use special allocation calls instead of normal malloc/calloc to get this working though (e.g. using farmalloc)
• Create a section in assembly with the “Area” directive (or whatever it is for your particular assembler) and reserve space for your array there and refer to that array as an extern variable.

The first approach is something that you should always look for. But if you can’t mimize your need any further, choose one out of the rest two. But few things to be kept in mind here that these options can still fail, e.g., when you don’t have enough RAM/heap memory remaining at runtime (of course, you would have planned for a graceful exit though in such case instead of the random crash that would have occured otherwise). But still these could be useful to you in case you don’t have any real RAM limitations but just that your compiler isn’t able to work with large objects.

© Safer Code | Large Arrays In C

Related posts

• int main() vs void main() (21)

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Even an expert programmer cannot claim of writing bug free code. Bugs are here to stay during a software development life cycle. But what every programmer needs to do is to test his code before the code goes into the main repository. So, programmers have different techniques to do this. Running Test cases, getting code reviewed, code walk through, running manual tests, ad-hoc tests are various things performed by people and Bang!!! code goes into the repository. Let’s consider the following psuedo-code:

char* someString = (char*) malloc(100);
if(someString != NULL){
    // do something
}else{
    // handle error condition
}

Now, If you try to test the above code using the above mentioned testing techniques, you can never be sure that you have covered 100% code in developer testing. The code definitely seems to be fine handling the error condition if the memory allocation fails. But have you actually tested the error condition handling? Generally, all the automated test cases or running the code will make the memory allocation successful and the error condition will never get executed. Even the code reviewers will pass the code without any objection as the code is handling memory allocation failure. But you haven’t made sure that error handling is safe or not. The Bug might be in error handling scenario.

So, One of the best way to “de-Bug” or test your code is always to step through your code. Think that you were stepping through your code using a debugger. Now, put a breakpoint at malloc and set someString to NULL right after memory allocation is done. This will enable your error condition code to be executed and you can claim 100% coverage of testing your code before checking it in the repository.

The next word of advise is that not only error conditions, one should check all the possible execution paths in the code. Consider the following example:

int someInt = 30;
char someChar = 'c';
if( someInt= 32 && someChar=='c'){
    // do something
}else{
    // handle error condition
}

If you notice, I have made a mistake in the code by typing ‘=’ in place of ‘==’ in the first part of ‘if’ statement. So, even if you run test cases or use debugger, the code will easily execute ‘if’ statement in one shot and will evaulate to true as first and second condition will always evaluate to ‘TRUE’. and hence, leaving a hole in the code. The error condition will never occur in this case. This can only be caught if while using a debugger, put a breakpoint inside ‘if’ statement, and then verify both the conditions on either side of ‘&&’ operator. This will lead you to find the anomaly in the code and hence, you’ll be able to kill a potential showstopper bug instantly.

In a nutshell, I wish to emphasize on a point is that debuggers are not meant only to be used when the defects are raised in defect trackign systems, they should be used during developmental testing of the code. I agree that this consumes a hell lot of extra time in development but isn’t it beneficial to be safe in the beginning rather than wasting time on these small issues after the software is released and have already translated into bigger crash bugs.

© Safer Code | “De-Bugging” Code before Check-in

Related posts

• And So It Begins… (0)
• Improper Variable Initialization (0)
• Predicting the rand() and using Cryptographic Random Numbers (7)
• int main() vs void main() (21)
• All Input is Evil (3)

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Many people would agree with me when I say that the hardest part of fixing a bug is to find where it is originating from. It has happened to me quite a number of times that a certain module exhibits a particularly wild behaviour making me go mad on its developer but as I dug deeper, the cuplrit turned out to be someone who had not even heard of that module.

Today I bring to you such an example of a nice bug, which I’ll term as (like many others):

OpenOffice.org Cannot Print On Tuesdays Bug

OpenOffice.org (also known as OOo or just Open Office) is a free and widely used MS Office alternative and a lot of its users reported in recently that it would just stop printing on every tuesday. Come Wednesday, everything would be just fine and dandy, but for just less than a week till Tuesday showed its face again. Now, before I continue to unravel the mystery behind this unique bug, let me outrightly clear it out to my Indian friends that OOo is not devotee of Lord Hanuman, deciding to go on a fast on Tuedays to offer its obesceinces.

Well, after days of discussions, and people blaming everything from OOo to cups (the printer daemon), printer drivers, or the printer itself, one enterprising soul decided to investigate and found out that if he changed the “CreationDate” tag in the generated postscript file to replace the “Tue” of Tuesday with something else, the file happily printed.

His doubt about this being a cups issue strengthened when he noticed that this only occurs with OOo because other tools like evince omit this particular tag and hence escape cups’ wrath. On looking further he found out that somehow the Tuesday file is not being identified as a valid postscript file by cups but as something else. But the culprit is not cups, the cups script was actually using another utility “file” to do this identification and whenever T occurs at the file’s fourth byte, it is being identified as an “Erlang Jam” file isntead of a postscript file. This bug is listed here. Now, he couldn’t solve the issue with the file utility, but the correct identification of the bug’s origin allowed him to make a quick workaround to solve his issue. He just made a small modification to the cups script and changed:

cat > $INPUT_TEMP

to

cat | sed -e 's/^%%CreationDate: (Tue/%%CreationDate: (tue/' > $INPUT_TEMP

This change changed the “Tue” to “tue” whenever it was found int he creation date hence circumventing the issue.

Let this be an example for you to remember always “A bug is not always where it seems to be” and that even the weirdest bugs are possible. If you are still in doubt, read this: The Case of the 500 Mile E-Mail

© Safer Code | A Bug Is Not Always Where It Seems To Be

Related posts

• “De-Bugging” Code before Check-in (0)

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

First of all, I apologize for the decreased frequency of updates. We have been quite busy with our offline lives and primary livelihoods lately keeping us away from posting much. But we intend to not let it remain like this for much longer. I’m posting a short article today about something that almost everyone of us has had to do at some point of time, i.e., to find the offset (or relative position in bytes) of an element in a structure. Let’s take the following structure as an example:

struct
{
  char a;
  int b;
  char c;
}example;

Now, if I were to ask you to find out the element b’s offset in the above structure, you won’t probably be able to answer with complete confidence unless I tell you the compiler you are working with and whether packing has been turned on or not. The easiest way to find it out is to use a small snippet of code to do it for us and that always works. e.g.

struct example s1;
unsigned int offset;
offset = (unsigned int)&s1.b - (unsigned int)&s1;

The above snippet will work, but not always (Hint). Many people use a much simplified form, which does not involve any pointer arithmetic:

unsigned int offset;
offset = (unsigned int)(&(((example *)(0))->b));

The above code is much simpler/faster but again, it might not be portable. So, what is the best method to do this portably. It’s quite simple really, just use the “offsetof” macro provided by any ANSI-C compliant compiler. It is present in stddef.h and can be used in the following way:

size_t offset;
offset = offsetof(example, b);

If you noticed, offsetof() also presents another advantage to you like the 2nd method, i.e., it does not require an extra structure to be defined. In fact, this macro is defined in forms similar to our method 2 but the benefit is that it ensures portability for your code.

© Safer Code | Find The Offset Of An Element In A Structure In C- offsetof()

Related posts

• Volatile: C Keyword Myths Dispelled (12)
• Validating Untrusted String Inputs (1)
• Validating Untrusted Integer Inputs (6)
• Unsafe Functions In C And Their Safer Replacements: Strings Part II (8)
• Unsafe Functions In C And Their Safer Replacements: Strings Part I (7)

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Every programmer, no matter how great he is, makes mistakes sometime or the other while coding. Although every compiler tries its best to put across every possible error during compilation,many mistakes skip the wrath of compiler. Some are seemingly very innocent and very tough to be caught even during code review, sometimes even get through the cycle of testing. The real face of these mistakes show up always on the customer side by crashing the system.

Consider the following example:

int multiply(int m, int n)
{
	int result = 0;
	result = m * n;	
	return 	result;
}
 
void func()
{
	int m = 32767;
	int n = 32767;
	int result = 0;
	result = multiply( m, n );
}

In this example, if you notice, the result always overrun the maximum value of an integer (int being of 16 bits). Now, for any compiler, this code seems to be perfect. But if you lint this code, the lint tool will definitely raise a warning about this potential bug. This bug if overlooked, can cause havoc in any system in crucial scenarios.

Similarly, there are many more example like these which can be caught while linting the code. Quite a few significant but obvious problems like buffer overrun, array index out of bounds, uninitialized variables causing junk in junk out can be caught using any of the good lint tools. This process of linting makes the code safe, secure and strong enough to withstand any kind of malicious input injections or buffer overrun attacks. Ofcourse, the complex scenarios can get skipped by some of the tools but still, it definitely is a better steo to catch the bug early. Quite a few tools are available in the market but i’ll recommend a tools can PC-Lint(Windows)/FlexLint(Linux). This tool is pretty good as it catches almost every obvious flaw which gets skipped by the developers or code reviewers eyes. It follows the guidelines given in MISRA (Motor Industry Software Reliability Assocation)standard and strictly adhers to that.

These linting tools generally have their properietary algorithms but in general, they all follow the same approach of static analysis of source code. Following are examples of some of the problems which these tools are capable of finding during the lint process.

Linting your code during development is very important as it can make your code much safer. It definitely does add to the build time and it might take few extra seconds to get the final object file, but isn’t it worth the hassle if you are saved from deadly bugs?

© Safer Code | Lint your code: Find probable mistakes much before testing

Related posts

• Validating Untrusted Integer Inputs (6)
• Validating Untrusted String Inputs (1)
• Unsafe Functions In C And Their Safer Replacements: Strings Part II (8)
• Unsafe Functions In C And Their Safer Replacements: Strings Part I (7)
• int main() vs void main() (21)

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Writing portable code is very important but it is one of the aspects that most people neglect until it is too late to realize its importance. Till few years ago, most people writing code for personal computers were not worried about the data sizes on their machines. They didn’t even think whether the machines, on which their code would be running, would be 32 bit or 64 bit. But the recent advent of 64 bit machines in normal every-day usage has them running helter-skelter to get their programs into shape. Many of these programs would like to run the same code base on 32 bit as well as 64 bit machines. There are many ways to do it. A few allow us to use data types that would work as expected in both machines while in other ways, they explicitly check for the architecture of the machine and carry out their tasks accordingly. Before I give you the code to run this check, let’s see a bit of theory behind it.

First, let’s be clear that the discussion we will be doing now will not always give you the “hardware architecture” of a machine. Rather it’ll allow you to know the “Programming Model” (or Data Model)that the OS or your compiler enforces on you. What I mean is that if you run a 32 bit OS on top of your latest 64 bit processor based system, it will still mean a 32 bit programming model for you. Infact, if you were to compile your programs using the ancient Turbo C compiler, you’d be in for an even bigger surprise . That said, ultimately the programming model is what you’d be interested in knowing to make sure that your program can compile and run accurately on that particular system. The most common programming models in use are as below:

So, what do we infer from this table? The glaring issues are that we can no longer depend on the sizes of data types with which we work. If your program does not make use of the data type sizes (either explicitly or implicity, e.g. by type conversion like converting between pointers and integers), most probably you will be safe by just recompiling your code for the new machine without changing it. Otherwise, a safe bet is to base your code around either all char’s or long long’s because this data type will always have the same size across machines.

Now, onto the “check”. If you read the above table carefully, you will come to know that most of the data type sizes can be misleading, i.e. they can be 32 bit even on 64 bit architectures. So, most people who make the mistake of using the size of integer on a machine for their checks fall into this trap. However, one of them that is useful for us is “The Pointer”. Yes, in all these models, the pointer to a data type is always 64 bit on 64 bit architectures and 32 bit on 32 bit architectures. Hence, the check becomes rather trivial, i.e.

n = sizeof(void *);

The above expression results in n being equal to 8 on a 64 bit architecture and 4 on a 32 bit architecture. So, there it is but remember that should not try this out with function pointers because that can lead to wrong results but that is a topic for some other time. We’ll bring you a few more articles about 32 bit vs 64 bit programming, its pitfalls, issues and areas where we can optimize and take advantage. Please let us know if you’d like us to cover a certain aspect in particular.

© Safer Code | Portable Code: How To Check If A Machine Is 32 Bit Or 64 Bit

Related posts

• Volatile: C Keyword Myths Dispelled (12)
• Generic Function Pointers In C And Void * (5)
• Validating Untrusted String Inputs (1)
• Validating Untrusted Integer Inputs (6)
• Unsafe Functions In C And Their Safer Replacements: Strings Part II (8)

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Last time we explained the real meaning of const keyword, this time it’s going to be Volatile, the other sibling of this most misunderstood duo in C history. Let’s separate out the myths and the facts first and then we will discuss the how’s and why’s of it.

FACTS:

• A volatile qualifier is important to be used for auto-storage variables within setjmp and longjmp.
• A volatile qualifier must be used when reading the contents of a memory location whose value can change unknown to the current program.
• A volatile qualifier must be used for shared data modified in signal handlers or interrupt service routines.

MYTHS:

• All shared data in multi-threaded programs must be declared volatile.

Now, we’ll see how we made the above classfication.

The only information/directive that volatile keyword means to the compiler is to not apply any implementation specific optimization to the object to which this qualifier has been attached. e.g. One of the most general optimizations that a compiler can apply to a variable is that if it cannot find a variable’s value being changed within a certain scope, it will cache the value of that variable, probably in a register, and then refer to that cached value whenever that variable is accessed instead of fetching it from the main memory.

#include "stdio.h"
#include "setjmp.h"
static jmp_buf buf;
int main( )
{
  int a;
  a = 0;
  if (setjmp(buf)!=0)
  {
    printf("%d n", a) ;
    exit(0);
  }
  a = 1;
  longjmp(buf , 1);
  return 0;
}

If you were to compile the above program without any optimization, you would see the output as 1, which is correct. But if you were to compile it with optimization turned on (e.g. by using -O2 option with gcc), the output would be 0. This is because the compiler saw that “a” was not used after setting it to one and hence optimized out that statement. Then, if you try it out by declaring “a” as volatile, you’d see the output as 1 even with optimization turned on, because the volatile qualifier would tell the compiler not to optimize any accesses related to a. For the 3 situations stated under facts, compiler cannot determine that a particular variable is needed or not because the accesses happen unknown to the compiler. Hence, we need to declare such variables as volatile.

Now, let’s turn towards the myths. Many people say that since in multi-threaded environment, a shared variable’s value can be changed by a thread before the other thread reads it, such variable should be declared as a volatile. But this is completely false. This is because a volatile qualifier just promises us that the accesses won’t be optimized and would be read from main memory each time but a multi-threaded program needs much more, namely:

1. Atomicity – The read/write access to the shared variables should be atomic in nature but access to volatile can be non-atomic and are completly implementation defined.
2. Preserve order of access – A volatile variable does not mandate this, especially when mixed with non-volatile variables.

So, if you are writing a multi-threaded program, what you need is something that ensures these 2 particular things by providing you proper memory barriers. e.g. You could use mutexes, pthreads, or something similar that provides you the above mentioned semantics.

If you rely completely on volatile to get a proper working multi-threaded program for you, let me assure you that all you will achieve is introduce serious slowness to the program (by taking optimization out of the equation). e.g. nothing stops another thread from coming in changing your variable’s value while you are half way through reading it in the current thread. And if you still require to use a volatile even after using a proper memory fencing “lock”, then there is something wrong with it and you need to take a hard look at your locking mechanism. But do not confuse it with the volatile provided in other languages like java where it does provide you with proper memory barriers.

I hope the article helped in clearing out your doubts about this mysterious little keyword from the C stable. Let us know if you have more questions about this.

© Safer Code | Volatile: C Keyword Myths Dispelled

Related posts

• "const" Keyword Explained (17)
• Tweak Your Code For Speed: Unroll Those Loops Part 1 (5)
• Portable Code: How To Check If A Machine Is 32 Bit Or 64 Bit (9)
• Optimizing Switch-Case Statements In C For Speed (11)
• And So It Begins… (0)

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

Everyone must have used rand() sometime or the other while writing C code. The problem with rand() in most of the platforms is that it is easy to predict the output. Being based on unsigned int, it is just a simple function using a seed which is always the last randomly generated some number. This seed is not very tough to guess for an advanced hacker. once this seed is guessed,, any password or information based on random number generation can be easilt cracked and maligned.

following code is abridged code of rand() function implementation referenced from the book The C programming Language written by Brian Kernighan and Dennis Ritchie

unsigned long int next = 1;
int rand(void)
{
    next = next * 1103515245 + 12345;
    return (unsigned int)(next / 65536) % 32768;
}

This type of function is generally called linear congruential function. As you can notice yourself, that these type of linear congruential functions are very much predictable and are not recommended for security sensitive applications. If you look at the above given code, it is obvious that if the underlying environment does not change, then the random number generation can easily be guessed as it will generate same random number on running the application again and again.

Any type of good random number generator should adhere to three basic properties:

1. Generate evenly distributed numbers
2. The generated number should be unpredictable
3. It should use a long cycle of range of numbers

Linear congruential functions just suffice the first property but fail miserably in the other two, thus, making themselves unusable for secure random number generation.In the early era of internet, people have used the rand() function, and hackers have exploited it at leisure.

To Solve this problem, most of the platforms support Cryptographic Random Numbers these days. For example, CryptGenRandom is provided by almost all the Windows platforms. These type of Cryptographic Random numbers are completely random as the seed used in them is also unknown to the programmer. It is completely random because it uses the system properties(system entropy) to generate the seed, which is then hashed used a hashing algorithm like SHA-1/MD4/MD5 etc. This implementation is completely platform dependent. For example: quite a few parameters used by Windows platforms are like

1. Current Process ID
2. Current Thread ID
3. GetLocalTime()
4. CPU counters
5. Allocated Process Memmory at initial time
6. Page Fault count
7. etc etc etc….

Due to these large number of parameters and then, applying the hashing algorithms, the seed becomes almost random and unpredictable, thus, making it next to impossible to be decrypted.

Crypt Random Numbers and algorithms are part of FIPS (Federal Information Processing Standard) standard. The above mentioned function is a part of FIPS 186-2 standard.

Talking about Cryptographic Random numbers is a fairly vast topic and I would like to continue in my next post.

© Safer Code | Predicting the rand() and using Cryptographic Random Numbers

Related posts

• And So It Begins… (0)
• All Input is Evil (3)
• Using Enum Pattern in Java < 1.5 (1)
• Improper Variable Initialization (0)
• “De-Bugging” Code before Check-in (0)

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

There are a few very basic things in C that are widely misunderstood by programmers of all caders. This is not because these things are very complex, but because books and teachers do not give them their due importance while teaching beginners and the misconceptions stick even years later. A few of these are like the keywords “volatile” (covered in next post) and “const”.

Look at the following piece of code:

#include <stdio.h>
int main()
{
const int a = 1;
a = 2;
printf("%d\n", a);
return 0;
}

You’d be quick to point out (correctly) that the above code wouldn’t compile. It would fail with an error on the lines of “assignment of read-only variable a” because a is now a “constant” because of the const type qualifier attached to it. And now comes the issue. Many start assuming (or might even be explicitly taught) that the value of a cannot be changed now. Did you think so too? Well, you thought wrong. Look at the following code:

#include <stdio.h>
int main()
{
const int a = 1;
int *b = &a;
*b = 2;
printf("%d %d", a, *b);
return 0;
}

Now, this program will compile (with a warning though, which can be removed by typecasting &a to int*) and will print the output as …any guesses? Well, lets see this “output” part later below. But how did that compilation go through?

Basically, by qualifying a variable as const, you are getting a gaurantee from the compiler that the value of that memory location cannot be changed “through that name” but can still be changed by any external program or even with the same program through another name.

But the story just doesn’t stop there. Some would say that this is impossible because by when you declare something as const, the compiler will put it in read only memory. This might be true or might not be because it is not specified in the C standard and is totally implementation dependent.

Now, lets come back to the “output” part, as in what actually would be printed on the console. Well, it could be anything because the C standard states that:

If an attempt is made to modify an object defined with a const-qualified type through use of an lvalue with non-const-qualified type, the behavior is undefined.

So, you’d be lucky if your computer doesn’t grow a tail and starts dancing drunk to the tune of a wild african native song . So, you could see the output as “1 1” or “2 2” with the most interesting one being “1 2”. Woah, how did that happen. It’s simple actually and if you were to see such an output, just assemble the code instead of compiling and see the assembly listing. I’ll explaing the reason here with a bit of background. Basically, there are 2 important uses of const keyword in programming:

1. To stop the programmer from mistakenly overwriting some data (e.g. a utility function that just compares 2 strings doesn’t need to modify them).
2. To allow the compiler to optimize the code for performance when you know for sure that the value of a variable would not change.

So, the “weird” output you see might be an outcome of the 2nd point above. Since you are telling the compiler that the variable is “read only”, it can optimize accesses to it in many ways, 2 of which are listed below:

1. It caches the variable’s value into a register and even though the write access to a through *b actually modifies the content of memory pointed to by a, the read access while printing the value of a still gets it from the register.
2. It could even replace the variable “a” by a constant value “1” anywhere it is used in the program.

So, there we go. I hope now you fully understand the concept behind the “const” keyword. I’ll take up even more infamous “volatile” next time. Do write in with your queries.

© Safer Code | "const" Keyword Explained

Related posts

• Volatile: C Keyword Myths Dispelled (12)
• Tweak Your Code For Speed: Unroll Those Loops Part 1 (5)
• Optimizing Switch-Case Statements In C For Speed (11)
• And So It Begins… (0)
• Validating Untrusted String Inputs (1)

Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email

One of the ways to optimize your code for speed is to unroll the loops you have in your program. If you don’t know what loop unrolling is, then see the following simple example, where we are trying to copy a 5 element long string:
A Simple Loop:

for (i = 0 ; i < 5; ++i)
{
    *j++ = *k++;
}

The same loop unrolled:

*j++ = *k++;
*j++ = *k++;
*j++ = *k++;
*j++ = *k++;
*j++ = *k++;

Now, the unrolled version is definitely going to be faster because of the following reasons:

1. There are no branches any more. In a loop, the compiler has to insert branches to jump back to the for statement.

2. There are no condition checks. In a loop, the value of i is checked every time to see what to do next.

3. A third rather hidden, but really important, advantage is that unrolled code can be pipelined efficiently by the processor hence resulting in faster execution.

The above code in itself might not show you any perceivable difference in execution time, but it does become crucial when the loops are of much higher magnitude and especially in embedded/real time scenarios.

Now, the loop unrolling can be done by the compiler or manually by the coder. In this part, we will see how to facilitate compiler to carry out loop unrolling efficiently.

1. Turn on your compiler’s optimization switches.

2. Find out if there are any pragmas available through which you can pass additional information to the compiler to help it in unrolling the loops. This information could be in the form of minimum no. of times the loop will be executed, maximum number of times the loop will be executed, is the number of times the loop will be executed a multiple of some particular number, etc. How this information helps the compiler will become clear in the next part of this series when we will tell you how to manually unroll the loops.

3. Try to keep the loop implementation in such a way that the variables written in one iteration are not read in the future iterations. e.g. in the above example, the variable “i” should not be modified within the loop. This would ensure that any given iteration of a loop is independent of the past values of i and hence can be easily pipelined.

4. Try to take out epilog and prolog from the loop. This refers to the statements which are not executed on every iteration of the loop but only at the starting or at the end of the loop. e.g. see the following example:

for(i = 0; i < 5; ++i)
{
    if(i == 0)
    {
         *j++ = *w;
         continue;
    }
    *j++ = *k++;
}

In this code, when i is 0, we carry out some special code. This could be rewritten as:

*j++ = *w;
for(i = 0; i < 4; ++i)
{
    *j++ = *k++;
}

5. Keep the loop body small, if you want to reap the benefits of pipelining. Many people might tell you to group the code that is executed same number of times into a single loop. But I’d say that if the 2 piecs of code are unrelated, it is better to keep them separate in 2 different loops in your c code. Because this will not affect the compiler from unrolling them (rather might help it in doing this, actually) but also allow it pipeline your code efficiently.

6. Try not to have external branches (like goto, function calls, etc) in your loop body. This also helps the compiler in pipelining the code.

7. The last advice is to avoid nested loops. Because in nested loops, the compiler will unroll only the outer loops, leaving the inner loops untouched. If you can’t avoid such conditions, it is generally recommended that you unroll the inner loops manually.

This is it, for this time. We will talk about manual loop unrolling next week. Let us know your queries and comments, and also about what topics should would like to know about next.

© Safer Code | Tweak Your Code For Speed: Unroll Those Loops Part 1

Related posts

• Optimizing Switch-Case Statements In C For Speed (11)
• Volatile: C Keyword Myths Dispelled (12)
• And So It Begins… (0)
• "const" Keyword Explained (17)
• Validating Untrusted String Inputs (1)