Chris' C Programming Notes

There are many useful functions in standard libraries. It looks like Wikipedia has a pretty good list of Posix C libraries. This is a specification of libraries a sane system should provide. Here are some of the classic ones with some of the defined functions listed.

All kinds of mischief can be had with preprocessor tricks. Generally it seems that this should only be used to manage the software development aspect of the program and not the program’s actual functionality. Here’s an example of a preprocessor macro in use:

To see what this preprocessor macro does, see below.

Other preprocessor tricks would be stuff like general constants that should be flexible depending on how someone might want to compile the program:

Often there is a big maze of include files and it’s easy to have one place include a library and then another place try to do it too resulting in some kind of clash. The following checks to see if the special library has been loaded and if not, it loads it. Subsequent uses of this will be ignored.

Another time this is useful is to disable chunks of code that might be present for testing.

This particular example is shown more fully at my libpcap notes.

Preprocessor macros can be useful for debugging messages too.

Just set the value to 0 to turn off verbose messages. This allows the programmer to set up a bunch of diagnostic print statements that can be turned on or off easily.

Similarly you can "comment out" large blocks of code by wrapping it in a #ifdef block.

With this you can also #define settings as a GCC option with -DPROBE2 but that just acts as a define at the beginning of your code so subsequent defines will override this.

While there is no shortage of tricksy ways to use the preprocessor for debugging, it seems to come down to sticking to a few guidelines.

Sometimes the problem is with the preprocessor swamp and you need to get some idea about what’s going on. For example, maybe you’ve got an #ifdef but you don’t know if it is getting hit.

This is a compile time message. Use #error "message" if you want it to actually halt compilation.

Related to the hackish messes one can make with the preprocessor are C++ templates. How can template functionality be done in plain C? This excellent article explores several different methods, mostly using the preprocessor but also with fancier techniques. So if you love templates, that’s no reason you can’t use C!

There are logical operators too.

Here’s an explicit run down of how they behave.

An interesting thing about C functions is that it is not a great idea to nest them. I did not know this until I tried it — to limit the function’s scope to the parent function — and got an error. Turns out that there is some GCC extension to make such things work, but if you have to go to such heroics, you know you’re not on the path of what could be called "normal C". It turns out that there is a lot more complexity hiding in this functionality than I (someone whose own programming language trivially handles nested functions until RAM runs out) initially imagined. This example by Knuth is an interesting demonstration.

Unlike the much worse situation with C++ the situation with const in C is only extremely confusing and prone to error. Basically if you’re really, really serious about something being really truly immutable, you should just not create a "variable". Just literally say the thing every time. So if you want to use the value for pi, just say "3.14159265358979323846" everywhere. That is a lot to type and prone to error, so C conceptually provides a way to do this that’s about as clever as using sed — just use preprocessor macros.

The const specifier is for things where you don’t know what it will be, but once it is initialized, it will never change. For example, it can be applied to things like this.

Here the number of arguments will be different depending on how the program is executed, but once the value is established, argc will be locked for the duration of the execution. Without out const you could, say, decrement the argc as you dealt with each argument; as shown, you can not.

Things get icky when slapping a const on pointers. This means that the pointer is constant but the stuff that it points to is not.

So here we’re saying that a always points to some address &a and never anywhere else no matter what.

This order has a different meaning.

Here the pointer is not const and in theory could change to point to a new address location. However, in both of those locations, you’ll want to be finding a constant character. If you try to change that character, i.e. the contents, it will fail. So basically you can’t do anything like this.

To parse these tricky declaration puzzles, start at the variable and spiral outward starting to the right (e.g. "b is a pointer to a char which is constant" or "a is a constant pointer to a char"). Here is a very good web resource for untangling this mess called "C gibberish → English".

Untyped pointers can be created with the void type.

To dereference such a pointer, it must be type cast with something. In this example the contents of two different kinds of variables, ib and fb, are set from the dereferencing of the same pointer.

A[i] is the same as (*((A)+(i)))

So these are equivalent.

You can load the array at definition.

I’m pretty sure you can’t define the array and then later set it with {0,0,0} or something like that. Just keep in mind why strcpy and memcpy exist. Here’s a way to use memcpy to initialize an array.

Here are ways to initialize arrays that are possibly compiler specific.

Brackets are actually a postfix operator for manipulating the array specified by the operator. (Confusing? Yes.)

Elements of arrays are stored in successive pointer address locations.

Find the length of an array:

Both of these syntax styles work.

It looks like the inner braces are for decoration only.

Hard to know whether to include this one here or at dynamic memory but it seems that the old limitation of needing to preallocate array memory has been relaxed a bit with C99. Official GCC documentation about arrays whose size can be specified at runtime.

Here’s a sample that demonstrates this crazy thing actually works.

Running the command with an argument of 1000000 does work fine. However, running the command with an argument of 10000000 produces an unhelpful "Command terminated" message.

If you use the GCC option -Wvla then this code will produce a warning (but otherwise compile fine): "warning: ISO C90 forbids variable length array ‘vals’ [-Wvla]"

Some people believe that VLAs are a performance drag.

Some security people believe that it allows you to exhaust the stack and then write naughty security problems into memory and then jump to them and take over the operations. Apparently they have been aggressively weeded out of the Linux kernel.

Linus himself says: "…using VLA’s is actively bad not just for security worries, but simply because VLA’s are a really horribly bad idea in general in the kernel."

There’s even a GCC thing where you can put variable length arrays in structs. Here is what Linus has to say about that. "The feature is an abomination. I thought gcc only allowed them at the end of structs, in the middle of a struct it’s just f*cking insane beyond belief."

Use sparingly if you must.

A character array is just what it sounds like with no serious mystery.

This produces a memory reservation, on the stack, for 50 char type objects addressable by index just as an array should be.

You can even do something like this to initialize it in the declaration.

That fills the first 6 with characters but leaves the last 44 undefined (use memset if that’s a problem). This does the exact same thing.

There a string literal is used, temporarily, to provide the character constants to define the array.

The confusing part about this is that you can not redefine the string in an obvious way that looks very similar but is not.

You can pick at each member of the array with myarray[0]= 'T' and so on.

If you omit the size to initialize to, it is computed from the length of your string literal initializer.

Note that it adds one more to store the NUL termination string it thinks you will appreciate. If you provide a length (like [50] shown above) then it will assume you’ll fit your full string and the nul terminator in the 50, and sizeof will return 50. So if you need the alphabet to be used in string functions, you need this.

Or simply do this which is the same thing.

Like arrays in general myarray is the same as &myarray. In other words, it is just an address where some same-sized chunks of stuff are allocated.

Compilers are weird but in theory, this kind of character is stored on the stack where it is accessible to changes.

Other programming languages do a really good job of hiding the gory details of using strings. C does a really good job of not hiding such details. This can be a challenge until you get the hang of it. A common scenario is you want to preserve a copy of a string in case the primary copy gets mutated. You can’t just say something like char *stmp=s; and think you’re done! The new string must be declared and its size must be explicitly provided so that memory can be carved out to store it. Here is a way that has worked for me.

This copies the contents of s into the stmp variable which has just been created and explicitly set up with the same amount of memory as s.

This syntax defines a pointer to a string literal.

An ordinary string literal has a type "array of n const char". Note the const; this means that this kind of string is stored in a way that modification is not correct. It might compile in weird cases, but don’t do it!

The underlying storage, unlike a character array, is in some kind of read only memory. All you can do is change what the pointer points to. This is ok for many applications because you often want to replace a string with another. Though this smells like the string is mutable, you are really changing the variable pointer to point to a different constant array. Using the myptr definition above this now works.

This implies that myptr and &myptr are not the same the first is a pointer to the latter’s array address (where the read only array really lives). You can’t reach into the array with the pointer index because it’s the wrong pointer. So this does not work.

If you want fancy string capabilities, you might need a custom library to do what you want. Here is an interesting one.

Need to find out how long a string is or if it is not empty, use strlen() which is in string.h.

Before C can be made into anything useful, you really need to create some tools to make certain tasks easier to implement. One theme that comes up over and over in more substantial programming tasks is the need to hold an arbitrary bunch of data somewhere. Since C requires very explicit declarations of all memory used, this can be challenging to always attend to it. It is therefore useful to create some templates that can get you into more interesting parts of the problem quickly.

Here is an implementation of a simple stack system. The stack is fed data with a Push() command, that is data is appended to the end of the stack (a FILO queue). Data is retrieved (and removed) from the stack with a Pop() function. Note the type definition cargo_type allows the stack to carry whatever kinds of data types you want simply by redefining this.

This program is also an example of passing function arguments by reference. It needs a pointer, so the pointer is pointed to by another pointer which gets sent to the function. When the transporter pointer is dereferenced, the original pointer that was supposed to show up at the function is ready to go. The reason this is necessary is that C function arguments are copied over and if you copy a pointer, it’s a different pointer (even if it points to the same place). If you inserted a new node between a function copy of the pointer to the list and the list, then you’d lose track of the (complete) list when the function variable’s memory was freed on function exit.

Also known as hashes, dictionaries (dict), Maps, etc. Although C does not have a first class data type for named arrays, the reason seems pretty clear to me — the creators of C just couldn’t imagine anyone dumb enough to need that. Of course they understood how terrifically useful such a feature is, but they also understood how trivial it would be to implement it from scratch using essential language features.

Why do I believe this? Go have a look at page 134 of the first edition of "The C Programming Language" by Kernighan and Ritchie, often simply called "The K&R Book" in C lore. There you will find section 6.6 called Table Lookup. In the two pages that follow, the motivation, and rationale for implementing associative arrays in true idiomatic C are provided. These two pages also include code for a complete implementation.

If that doesn’t humble you into focusing more on your deficiencies than the ones you perceive in C, I don’t know what will.

Here is an implentation and discussion, including alternatives. The specific hash function K&R use is really just for illustration and some people object to it; other reasonable looking hash functions can be found at the bottom of this page.

To get a random number between 1 and 100 do something like this:

You need the srand() to seed the random number generator. The rand() function returns random numbers between 0 and RAND_MAX. If you need a random number between 0 and 1, another way to do that would be to do rand()/(RAND_MAX+1).

If you are using a proper operating system (like Linux or a fruit-based computer) there is a managed resource that collects entropy for use by various processes in establishing randomness. This source of randomness is presented as a file by the kernel and automagically filled with pretty high quality random numbers (see man random for gory details). Here is a way to get random numbers using a seed pulled from this source:

A good illustration of the difference can be seen by running these numerous times very quickly. If run 10,000 times, a random number between (and including) 1 and 100 should pop up roughly 100 times. You can see that producing random numbers from the OS’s seed does roughly that. The time based one, however, does a terrible job. Most of the time it will produce zero results with a particular preselected number ("88" in the following example).

This is because over the course of a few seconds to run, the time only changes a few times and most of the values will be from only a handful of seeds. Ironically, this problem is worse on higher performance machines.

Sometimes you’re doing something like writing images with libpng and it wants to create them with absurd restrictive permissions. To change this behavior, you need to add these lines.

Then make sure you delete any files you may have previously written because this will not affect existing files, just creation.

Note that the open() function takes a umask argument which might simplify things in easy cases where you’re doing the writing explicitly.

Normally the compiler doesn’t reinvent the wheel for every tiny detail your program could possibly need. If there are normal things used by pretty much all normal programs, the compiler just dynamically links your code to a standard library object file that shares duty with other programs. This means that you’ll need to have those files available to run your executable. Normally this isn’t a problem because they’re always there or your system probably wouldn’t work.

But sometimes you need to send an executable into a situation where the libraries you use every day may not be available. Maybe it’s an old system. Maybe it’s a weird distribution. Maybe just the version numbers are messing with you. Or even just the paths are different.

To have the compiler create an executable with all the CPU op codes necessary for your software to work in isolation, you’ll need the -static option. Don’t confuse this with the -s option, which I believe is for stripping out strings and symbols. The -s option makes your code smaller and slightly harder to debug; the -static option makes your code much bigger and you should probably not be doing active development with it.

Something like this:

Also with #include <stdio.h> assumed, you can also use this.

What if you get the dreaded Segmentation fault? This means something bad happened at run time. Most errors are caught at compile time but sometimes your program looks fine to the compiler and does a silly thing once you actually fire it up. Besides mystical intuition the best methodical way to analyze the problem is to have the system create a memory dump at the time of the error and then use a special tool to look through this memory file to figure out what went wrong. To get a misbehaving program to create a core dump file compile like this:

Or if you’re definitely going to use gdb:

If it still has a seg fault and you’re not getting a (core dumped) message appended to it, try changing your environment with:

ulimit -c unlimited

This removes any restriction on the size of core files allowed by the shell.

Assuming you have a core dump called core, run gdb like this:

The core should load and allow you to investigate it. It might just tell you about the error and where it occurred.

Or if you don’t need a core dump, you can just run gdb sketchy and type run to run the program and see if your error happens in a more interesting and verbose way. Here are some of the important commands to be aware of when using gdb.

Here’s a nice guide to practical gdb use. More on TUI mode.

According to the man page, Valgrind "is a flexible program for debugging and profiling Linux executables. It consists of a core, which provides a synthetic CPU in software, and a series of debugging and profiling tools." Practically, it can be very handy in troubleshooting insidious memory errors.

On Debian you can simply apt install valgrind. To use it, just run your executable through it. So my code and argument ./cnow cnow.cno becomes this.

This should show a bunch of helpful hints prefixed with the PID.

As you can see here, this code is not doing daft things with memory. Yay! Compare with this code.

It is good form to make sure all your code runs without Valgrind leak errors. If problems are detected, try it with valgrind -v or valgrind --leak-check=full for a deeper analysis.

For more details, see the full documentation for Valgrind.