Pointers in C + Arduino Tutorial

[netwinder]

Hello EEVBlog fourm!

Reading through code online I got tired of seeing overly complicated code that could easily benefit from pointers. So I wrote a tutorial on it http://advtech.ca/index.php/arduino-c-pointers/ Tell me what you think

[nctnico]

Oh please stop!!! Pointers are the enemy of robust code. Too much can go wrong with pointers and that is why seasoned programmers avoid pointers as much as possible. Ever heard about buffer overflows and random crashes? That is the evil called pointers at work!

[helius]

I tend to agree, but in a language like C or Wiring there is not much you can do without them. With advanced C++ template metaprogramming it is possible to get away from pointers.

[Ian.M]

OTOH C arrays without extra bounds checking code for the index are just as dangerous, and as you cant pass arrays by value and sizeof() only works on the original array in the module its defined in, its a real PITA defining:

Code: [Select]

const unsigned int array_size=sizeof(array)/sizeof(array[0]);for each array in each source module, then adding extern declaration for all the array_size consts to the headers, and passing the array size with the array to every function that uses it so you can actually do the bounds checking to make it safe.

C++ is a little better as you can localise the code that accesses the array more easily without adding cruft to its interfaces, but when you get down and dirty, the implementation is just as fugly + the compilers are generally less trustworthy.

TLDR: Don't write code that needs repeated data structures and an absolute guarantee of no rogue memory accesses in C or C++.     

[Maxlor]

It's a nice tutorial. If you are looking for additional things to put in it, here are some suggestions:

- Be a bit more explicit about the difference of * in a declaration and when used as an operator.
- Discuss some common use cases of pointers; you show some examples, but none of them show the benefit of actually using pointers. I'm thinking that you could discuss:
  -- The most common example of pointer usage in all of C, strings!
  -- Output parameters on functions
  -- Being able to write more generic code, through, say, having 3 different configurations in 3 structs of the same type, then switching between them through a pointer at runtime.
  -- How using pointers instead of by-value parameters is more efficient; you should show this with structs though, not arrays.
- Actually I think that using pointer arithmetics instead of array indexing is less clear and should be avoided. There is one common use of pointer arithmetics though: STL-style iterators. Maybe explain how those work?
- char **argv. Or generally, why you sometimes see ** (array of C strings, or returning a pointer as an output parameter.)
- Discuss some of the more common types of program crashes caused by incorrect pointer usage, i.e. show which error leads to which crash, so people recognize the cause more easily.

That's all I can think of at the moment. Also, don't get discouraged by the people hating pointers. You can't avoid them if you're using C, and certainly not if you want to read and understand other people's code. Learning about them is a good thing.

[langwadt]

OTOH C arrays without extra bounds checking code for the index are just as dangerous,

that is probably because arrays and pointers go together as in; 

array == &array[0]

[Ian.M]

Yes that's the general issue, but the two are not strictly identical as in the original source module sizeof() can get the total array size from the array name, but not from &array[0].   That's just one of the nasty traps for the unwary in C and C++, compounded by the fact that it cant get the array size from an extern declaration that doesn't explicitly include the size, which leads to madness like:
-header-

Code: [Select]

#define ARRAY_SIZE=7
extern int array[ARRAY_SIZE];
-module-

Code: [Select]

int array[]={ 65, 66, 71, 34, 90, 23, 11};
assert(ARRAY_SIZE==sizeof(array)/sizeof(array[0]));
just to attempt to confirm the initialiser list matches the expected array size.

[hamster_nz]

Oh please stop!!! Pointers are the enemy of robust code. Too much can go wrong with pointers and that is why seasoned programmers avoid pointers as much as possible. Ever heard about buffer overflows and random crashes? That is the evil called pointers at work!

Any code is the enemy of robust code... I for one do not want to give up dynamic memory allocation.

Buffer overflows don't even need pointers...

Code: [Select]

   char buffer[10];
   for(i = 0; i < 11; i++)
     buffer[i] = 0;


[helius]

Buffer overflows don't even need pointers...

If you refer to the C standard, that code uses a pointer that is the result of the standard conversion of buffer. The only cases where array variables are not converted to pointers are when they are defined, or inside a sizeof expression.

[hamster_nz]

Buffer overflows don't even need pointers...

If you refer to the C standard, that code uses a pointer that is the result of the standard conversion of buffer. The only cases where array variables are not converted to pointers are when they are defined, or inside a sizeof expression.

I understand what you are saying, but as that example code was to illustrate the removing pointers from your source code does not eliminate buffer overruns - the ability to overflow any storage allocations is a side effect many aspects of the language.

I would conjecture that avoiding pointers might encourage buffer overflows in any moderately complex code, as without pointers you can't dynamically allocate storage for data that has an unknown size at compile time. Code then becomes littered with stuff like "char file_name[128]" and other statically allocated buffers that can be abused. better to:

Code: [Select]

  char *path_name;

  path_name = malloc(strlen(dir_name)+1+strlen(file_name)+1);
  if(path_name == NULL)
    return -1;

  sprintf(path_name,"%s/%s", dir_name, file_name);

  /* Use the path_name to do stuff */

  free(path_name);

You can't overflow path_name in that code...

[Mechatrommer]

Oh please stop!!! Pointers are the enemy of robust code.

barking at the wrong tree? instead of barking at one ownself? yeah keep blaming the tools. what i recently have is a program made out of a so called robust language, its a species of a snake. every time running it to make a usefull job, i almost always want to pull my hair out, the efficiency of the algorithm is close to 1%, too darn slow, for simply merging 2 polygons. to add insult to the pain, its the only free tool that can do the job out there.

[helius]

I understand what you are saying, but as that example code was to illustrate the removing pointers from your source code does not eliminate buffer overruns - the ability to overflow any storage allocations is a side effect many aspects of the language.

Agreed; my point is that it is really impossible to avoid pointers for all but the simplest programs in this language. So even if you think you have done it, that is not likely the case. (Does your program have a main(char, char**)?) Does your example actually demonstrate the removal of all pointers from a program? I would suggest not, since in C when arrays are used, it's almost always as pointers. To not use any arrays as pointers makes them largely useless.

I would conjecture that avoiding pointers might encourage buffer overflows in any moderately complex code, as without pointers you can't dynamically allocate storage for data that has an unknown size at compile time. Code then becomes littered with stuff like "char file_name[128]" and other statically allocated buffers that can be abused.

Since I've shown that "avoiding pointers" is a flat impossibility, we have no reason to speculate on its effects. The static allocation of buffers is a different topic and I don't think you have made a strong case: in practice, dynamically allocated buffers are equally subject to overflows in C because it is not trivial to calculate the required size. They add an additional bug source because each dynamic allocation must be explicitly tested for failure and the program must choose what to do.

[Mechatrommer]

havent they learnt about making type-safe, or auto boundary checking, or even memory management built in "data-class"? if anyone want to customized boundary-checked type-safe data type, that certainly can be made in C++, that other languages are very remotely incapable in this regard. how do they think that safe-data-types on the other languages are made?

[hamster_nz]

I understand what you are saying, but as that example code was to illustrate the removing pointers from your source code does not eliminate buffer overruns - the ability to overflow any storage allocations is a side effect many aspects of the language.

Agreed; my point is that it is really impossible to avoid pointers for all but the simplest programs in this language. So even if you think you have done it, that is not likely the case. (Does your program have a main(char, char**)?) Does your example actually demonstrate the removal of all pointers from a program? I would suggest not, since in C when arrays are used, it's almost always as pointers. To not use any arrays as pointers makes them largely useless.

I did say "source code", and I believe that "int main(void)" is accepted by most compilers if you don't want to use command line arguments.... and of course you would be a fool to avoid pointers most of the time (however for some situations that is the best thing to do...).

Which brings us back to Nctnico's the original post on not using pointers, and why I feel it is too harsh...

Pointers in C are a very sharp tool, and you need to be careful where and when you wave the around. However telling everybody to chop trees with a blunt axe because they might cut themselves is just silly.

[Keicar]

Misuse of pointers is the source of much pain & suffering, it's true - and they do make it pretty easy to stab yourself in the eye, but the solution to this does not lay in fostering ignorance. Sure, when you first learn a technique you're liable to overuse it (Maslow's Hammer springs to mind) - but eventually you learn the pitfalls, and adopt a disciplined approach - but you can only do that based on knowledge. And if you ever have to work on other people's code, you always face the possibility of coming up against someone's nightmarish sh*tstorm of indirection, so it's best to be prepared with a full working knowledge of your chosen language.

[obiwanjacobi]

The potentially dangerous but powerful tools a language offers should be kept in check.
If you have to think about all the details with every line of code you type, it wil be tiresome fast. That is why I like to encapsulate that stuff. Now that is not a free ride either, but when carefully constructed can make your life easier.

Here is my solution for an array for instance.
http://atl.codeplex.com/SourceControl/latest#Source/Code/ArduinoTemplateLibrary/Array.h

(You 'store' the size with the instance and you perform bounds checks)
I know it's not C but C++... I personally don't see any advantage in using C - unless that is the only compiler you have...

[netwinder]

Sorry about getting back so late - I would have enjoyed contributing to this discussion.

It's a nice tutorial. If you are looking for additional things to put in it, here are some suggestions:

- Be a bit more explicit about the difference of * in a declaration and when used as an operator.
- Discuss some common use cases of pointers; you show some examples, but none of them show the benefit of actually using pointers. I'm thinking that you could discuss:
  -- The most common example of pointer usage in all of C, strings!
  -- Output parameters on functions
  -- Being able to write more generic code, through, say, having 3 different configurations in 3 structs of the same type, then switching between them through a pointer at runtime.
  -- How using pointers instead of by-value parameters is more efficient; you should show this with structs though, not arrays.
- Actually I think that using pointer arithmetics instead of array indexing is less clear and should be avoided. There is one common use of pointer arithmetics though: STL-style iterators. Maybe explain how those work?
- char **argv. Or generally, why you sometimes see ** (array of C strings, or returning a pointer as an output parameter.)
- Discuss some of the more common types of program crashes caused by incorrect pointer usage, i.e. show which error leads to which crash, so people recognize the cause more easily.

That's all I can think of at the moment. Also, don't get discouraged by the people hating pointers. You can't avoid them if you're using C, and certainly not if you want to read and understand other people's code. Learning about them is a good thing.

Thanks for the feedback  , tonight I'll see to updating the post to include some of those topics. And I'll adress some of the pointer concerns down below.

Oh please stop!!! Pointers are the enemy of robust code. Too much can go wrong with pointers and that is why seasoned programmers avoid pointers as much as possible. Ever heard about buffer overflows and random crashes? That is the evil called pointers at work!

The enemy of robust code? I agree that adding pointers may make things more complicated, but pointers haven't been around for decades just to be an amusement to computer scientists around the world - they are incredibly useful and they can heavily simplify the development of alot of complex applications.
An analogy for you (its a tad exaggerated, my apologies in advance) but not using pointers just because "Too much can go wrong" is like using addition to solve a multiplication problem. Sure addition will yield the same results - but at what cost... (time, is the answer).
Just an example, but I hope you see the comparison

Plus if pointers are so unstable and broken, how do you think the Linux Kernel works? Sure we are talking about two different worlds here, micro controllers and kernels. However the Linux kernel is practically built using pointers *and many many other things*

I tend to agree, but in a language like C or Wiring there is not much you can do without them. With advanced C++ template metaprogramming it is possible to get away from pointers.

Agreed 

[nctnico]

Why do you think large application are written in language like Lua, Java and C#? Yes, mainly because these languages don't have pointers and have managed variables. The next thing that will hit the microcontroller scene is moving away from C to C++ and lightweight versions of languages like Lua, Java or C#. Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

[John Coloccia]

 

If you're going to get involved in embedded engineering, you should probably learn how to use pointers without running into all the problems nctnico seems to run into. If nothing else, there's a great deal to be said for having so much C code available that you can draw from and use on practically any platform.

[ehughes]

Why do you think large application are written in language like Lua, Java and C#? Yes, mainly because these languages don't have pointers and have managed variables. The next thing that will hit the microcontroller scene is moving away from C to C++ and lightweight versions of languages like Lua, Java or C#. Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

Can you name a few examples?        C# and Java cannot be lightweight.  Ever.    I have used plenty of buggy C# ad Java programs that leak memory and crash often.  The issue is the programmer and the process, not the language.

I have been hearing about the death of C for awhile now.      The data shows the opposite.

http://webpages.uncc.edu/~jmconrad/ECGR4101-2015-08/Notes/UBM%20Tech%202015%20Presentation%20of%20Embedded%20Markets%20Study%20World%20Day1.pdf

[nctnico]

If you're going to get involved in embedded engineering, you should probably learn how to use pointers

I don't get the elitist attitude from your post. Generally speaking pointers are the least well understood mechanism by students. Creating robust software is all about avoiding pitfalls and not telling people they should have watched out when it is too late.

[Mechatrommer]

Why do you think large application are written in language like Lua, Java and C#?

yes because the professional programmers dont want to deal with low level stuffs that they deemed think unecessary. they want to get it done quickly. done quickly = money quickly. there are some rational to this though.

Creating fast code isn't important anymore

with this type of mentality, the school of algorithm that we learnt all this while will be dead, not every datatype built into the managed language can be handle a particular purpose, not with ideal efficiency at least, imho. then we'll have a bunch of new breed of programmers that only rely on built in data type and produce snail speed applications. what concerned me is if this new breed will produce still buggy but darn less efficient program like what i've experienced recently (but granted its a free tool).

CPU power is cheap

not so with the recent broke down of Moore's Law.. though there are some (big) area like user interface (GUI) and the program's housekeeping job where this mentality is correct, but not in every area, such as cpu and process intensive operations.

[John Coloccia]

If you're going to get involved in embedded engineering, you should probably learn how to use pointers

I don't get the elitist attitude from your post. Generally speaking pointers are the least well understood mechanism by students. Creating robust software is all about avoiding pitfalls and not telling people they should have watched out when it is too late.

Indirection is the heart and soul of programming. It doesn't much matter if it's done with pointers or some other way. What is least understood by students  is neither here nor there. "Don't use transistors...they're too hard."

[netwinder]

Why do you think large application are written in language like Lua, Java and C#? Yes, mainly because these languages don't have pointers and have managed variables. The next thing that will hit the microcontroller scene is moving away from C to C++ and lightweight versions of languages like Lua, Java or C#. Creating fast code isn't important anymore and projects grow too complex to allow for a stupid mistake to mess things up. CPU power is cheap, missing the product release date or needing to recall products is not.

I'm sure getting a prototype up and running with Lua, Java, C#, etc does work - however I'm talking strictly in terms of rapid prototyping. You realize that Lua, Java, C# are built on C? I don't believe theirs a processor / micro controller out there that naively runs off of the Java virtual machine (I could be wrong though)

[obiwanjacobi]

I too can see using a different langauge that compiles down to native. So you can use C#, Java or Swift or whatever to have a strong typed, type-safe and controlled (managed) langauge, but still go down to native instructions (either at compile time or at runtime - almost too late compilation ;-) ) The overhead would be relatively minimal. And the parts that really require hand-optimized assembly need to be done by a pro anyway. Time to market coulld decrease and cost of testing could go down.
I tend to agree with Nico.