1 Configuration and setup

This first chapter is purely optional. If you already know how to build C code, especially if you’re familiar with working at the command prompt, stop wasting time and merrily skip up to chapter 2. Otherwise, slug it out and

• Review the C language development cycle

• Use an integrated development environment (IDE) to build code

• Explore the excitement of command-line programming in a terminal window, just like Grandpa did

• Review options for linking in libraries and supplying command-line arguments

The purpose of this material is for review, though if you’ve never used a command line to program, you’re in for a treat: I find command-line programming to be fast and easy, specifically for the tiny programs created in this book. This code is well suited for the command-line environment.

Still reading? Good. This chapter serves as a review when your C programming skills are rusty or if you just want to confirm that what you know is up to par for successfully navigating the rest of the book. I appreciate that you’re still here. Otherwise, these pages would be blank.

And why do skills get rusty? Is it the iron and oxygen? The field of computer jargon needs to plant new terms for poor skills, something highly offensive and obnoxious to the point of being widely accepted. I’ll ruminate on the topic, and maybe add a quiz question along these lines at the end of the chapter.

1.1 The C development cycle

According to ancient Mesopotamian tablets currently on display in the British Museum, four steps are taken to develop a C language program. These are illustrated in figure 1.1, where you can plainly see the C development cycle written in cuneiform.

Figure 1.1 The C development cycle, courtesy of the British Museum

As a review, and because neither of us knows Babylonian, here is the translation:

1. Start by creating the source code file.

2. Compile the source code into object code.

3. Link in a library to create a program file.

4. Finally, run the program for testing, disappointment, or delight.

Step 4 is a rather liberal translation on my part. The original reads, “Run the program and rejoice by consuming a cow.” I have also omitted references to pagan deities.

These steps present a simple overview of the process. The steps are more numerous due to inevitable errors, bugs, booboos, and lack of cows. The following sections describe the details.

1.1.1 Editing source code

C language source code is plain text. What makes the file a C source code file and not a boring ol’ text file is the .c filename extension; all C source code files use this filename extension. Eyeball code uses the .see extension. Naval code uses .sea. Know the difference.

Use a text editor to craft your source code. Do not use a word processor, which is like using a helicopter to prune a tree. Don’t let the exciting visual image dissuade you; your goal is to use the best tool for the job. Any plain-text editor works, though the good ones offer features like color-coding, pattern matching, and other swanky features that make the process easier. I prefer the VIM text editor, which is available at vim.org. VIM is available as a both a text mode (terminal window) program and a GUI or windowed version.

IDEs feature a built-in text editor, which is the point of the I in IDE: integrated. This editor is what you’re stuck with unless an option is available to change it. For example, in Visual Studio Code, you can obtain an extension to bring your favorite editor commands into the IDE.

As a tip, the .c file extension defines a C language source code filetype, which is often associated by the operating system with your IDE. On my system, I associate .c files with my favorite VIM text editor. This trick allows me to double-click a C source code file icon and have it open in my text editor as opposed to having the IDE load.

1.1.2 Compiling, linking, building

After writing the source code, you build the program. This process combines two original steps that only a handful of programmers at the Old Coder’s Home remember: compiling and linking. Most code babies today just think of compiling, but linking is still in there somewhere.

After the source code file is as perfect as you can imagine, you compile it into object code: the compiler consumes the text in the source code file, churns through it, and spews forth an object code file. Object code files traditionally have a .o (“dot-oh”) filename extension unless your compiler or IDE opts for the heretical .obj extension.

Items in your source code that offend the compiler are flagged as warnings or errors. An error terminates the process with an appropriately rude but helpful message. A warning may also thwart the creation of object code, but often the compiler shrugs its shoulders and creates an object code file anyway, figuring you’re smart enough to go back and fix the problem. You probably aren’t, which is why I admonish you to always take compiler warnings seriously.

Object code is linked or combined with the C library file to build a program. Any errors halt the process, which must be addressed by re-editing the source code, compiling, and linking again.

These days, the original separate steps of compiling and linking are combined into a single step called building. Compiling and linking still take place. No matter how many steps it takes, the result is the creation of a program.

Run the program.

I’m quite nervous when my efforts survive the building process with no warnings or errors. I’m even more suspicious when I run the program and it works properly the first time. Still, it happens. Prepare to be delighted or have your suspicions confirmed. When things go awry, which is most of the time, you re-edit the source code file, compile, link, and run again. In fact, the actual C program development cycle looks more like figure 1.2.

Figure 1.2 The true nature of the program development cycle. (Image courtesy of the California Department of Highway Safety.)

For trivia’s sake, the original C compiler in Unix was called cc. Guess what it stands for?

The original Unix linker was named ld. It probably stands for “link dis.” The ld program still exists on today’s Linux and other Unix-like systems. It’s called internally by the compiler—unless the code is riddled with errors, in which case the compiler calls its friend Betsy to giggle about how horrible your C code reads.

Okay. The ld program most likely is short for Link eDitor. Please stop composing that email now.

1.2 The integrated development environment (IDE)

Most coders prefer to work in an integrated development environment, or IDE—this program is software used to create software, like a toaster that makes toasters but also makes toast and bread.

The IDE combines an editor, a compiler, and a running environment in a single program. Using an IDE is a must for creating GUI programs where you can build graphical elements like windows and dialog boxes and then add them to your code without the toil of coding everything by hand. Programmers love IDEs.

1.2.1 Choosing an IDE

You don’t need an IDE to craft the programs presented in this course. I suggest that you use the command prompt, but you’re stubborn and love your IDE—and you’re still reading—so I’m compelled to write about it.

The IDE I recommend for C programming is Visual Studio Code, available at code.visualstudio.com. It comes in Windows, macOS, and Linux flavors.

Visual Studio Code can be overwhelming, so I also recommend Code::Blocks, available at codeblocks.org. Its best version is available only for Windows. Ensure that you obtain a version of Code::Blocks that comes with a compiler. The default is MinGW, which is nice. Better, get clang for Windows, which can be obtained at the LLVM website: llvm.org. You must manually cajole Code::Blocks into accepting clang as its compiler; details are offered in the next section.

If you’re using Linux, you already have a compiler, gcc, which is the default. Even so, I recommend obtaining the LLVM clang compiler. It’s incredibly sophisticated. It features detailed error messages plus suggestions for fixing your code. If I were a robot, I would insist that clang be used to compile my brain’s software. Use your distro’s package manager to obtain this superb compiler at once!

1.2.2 Using Code::Blocks

Though I prefer Visual Studio Code, I recommend Code::Blocks if you’re just starting out. Before you build your first program in the Code::Blocks IDE, confirm that the path to the compiler is correct. For a standard installation, the path is:

C:Program Files (x86)CodeBlocksMinGWin

Ensure that this address is specified for Code::Blocks to locate the default compiler, MinGW, which I just mentioned. Or, if you’ve disobeyed the setup program’s suggestions, set the proper path to your compiler. For example, be spicy and use LLVM clang as your compiler. If so, set the proper path to that compiler so that Code::Blocks doesn’t barf every time you click the Build button.

To set the path, heed these directions in Code::Blocks. Don’t be lazy! The missing compiler error message is one of the most common email complaint messages I receive from readers who can’t get Code::Blocks to work. Follow these steps in Code::Blocks:

1. Choose Settings > Compiler.

2. In the Compiler Settings dialog box, click the Toolchain Executables tab.

3. Write (or paste) the compiler’s address into the Compiler’s Installation Directory text box.

4. Click OK.

The IDE should be happy with the compiler after you work through these steps. If not—yep, you guessed it—get some cows.

Once the compiler is set, you use Code::Block’s built-in editor to create your code. The editor uses color-coding, matches parentheses and other pairs, and features inline context assistance for C library functions. All good.

After creating—and saving—your source code, Code::Blocks uses a Build command to compile and link the source code. Messages are output in another part of the window where you read whether the operation succeeded or failed.

Figure 1.3 shows the Code::Blocks workspace. Its presentation can be customized, though in the figure look for the callout items of the buttons used to build or run or do a combined build-and-run.

Figure 1.3 Important stuff in the Code::Blocks IDE window

Like all IDEs, Code::Blocks prefers that you create a new project when you start to code. The process works like this:

1. Click File > New > Project.

2. From the New From Template window, select the Console Application icon, and then click the Go button.

3. Select C as the programming language, and then click Next.

4. Type a title for the project, which is also the name of the project folder tree.

5. Choose the folder in which to create the project.

6. Click Next.

7. Select to create a Release configuration. You don’t need the Debug configuration unless you plan on using the Code::Blocks debugger (which is really quite cool, but no).

8. Click Finish to create the project skeleton.

Code::Blocks spawns all kinds of folders and creates a prewritten source code file, main.c. You can replace the contents of this file with your own stuff. I find this entire process tedious, but it’s how an IDE prefers to work.

As an alternative, you can use the File > New > Empty File command to open a new source code file in the editor. Immediately save the file with a .c filename extension to activate the editor’s nifty features. You can then proceed with creating an individual program without enduring the bulk and heft of a full-on project.

Existing files—such as those you steal from GitHub for this book or for other, nefarious purposes—can be opened directly. The point of opening any file directly is that you don’t need the bulk and overhead of creating a project to create such small programs.

To perform a quick compile and link in Code::Blocks, click the Build button. This step checks for warnings and errors but doesn’t run the created program. If things go well, click the Run button to view the output in a command prompt window, such as the one shown in figure 1.4.

Figure 1.4 The command prompt window

Close the command prompt window when you’re done. Remember to do this! A common problem some people have with Code::Blocks is that they can’t see the output window. This dilemma most likely occurs because an output window is already open. Ensure that after test-running your programs, you close the wee li’l terminal window.

If you’re feeling cocky, you can use the combo Build-and-Run button (refer to figure 1.3) instead of working through the separate Build and Run commands. When you click Build and Run, the code builds and immediately runs, unless you riddled the thing with errors, in which case you get to fix them.

1.2.3 Using XCode

The XCode IDE on the Macintosh is a top-flight application used to build everything from macOS programs to those teensy apps that run on cell phones and wristwatches for the terminally hip. You can use this sophisticated tool to write the simple command-line, text mode utilities offered in this book. It’s kind of impractical, given the power of XCode, but this hindrance doesn’t prevent millions of Apple fans from doing so.

If your Macintosh lacks XCode, you can obtain a copy for free from the App Store. If prompted, ensure that you choose to add the command-line tools.

To create a text mode C language project in XCode, heed these directions:

1. Choose File > New > Project.

2. Select the Command Line Tool template for the project.

3. Click Next.

4. Type a name for the project.

5. Ensure that C is chosen as the language.

6. Click the Next button.

7. Confirm the folder location.

8. Click the Create button.

XCode builds a project skeleton, providing the main.c file, complete with source code you can gleefully replace with your own.

Alas, unlike with other IDEs, you cannot open an individual C source code file and then build and run it within XCode. This reason is why I recommend using command-line programming on the Mac, especially for the small, text mode utilities presented in this book. Refer to the next section.

To build and run in XCode, click the Run icon, shown in figure 1.5. Output appears in the bottom part of the project window, as illustrated in the figure.

Figure 1.5 XCode’s window. (Squint to view clearly.)

While the project files may dwell in the folder you chose earlier in step 7, the resulting program is created and buried deep within XCode’s folder system. This attempt at concealment makes it inconvenient for running and testing command-line programs demonstrated in this book. Specifically, to set command-line options or perform I/O redirection at the prompt requires jumping through too many hoops. To me, this awkwardness makes using XCode as your IDE an option limited to masochists and the fanatical Apple type.

1.3 Command-line compiling

Welcome to the early years of computing. It’s nostalgic to edit, build, and run C programs in text mode, but it works well and is quite efficient. You must understand how the command line works, which is something I believe all C programmers should know innately. Truly, it’s rare to find a C coder worthy of the title who lacks a knowledge of text mode programming in Unix or Linux.

1.3.1 Accessing the terminal window

Every Linux distro comes with a terminal window. MacOS features a terminal program. Even Windows 10 comes with a command shell, though it’s better to install the Windows Subsystem for Linux (WSL) and use an Ubuntu bash shell for consistency with the other platforms. Never have the times been so good for text mode programming. Crack open a Tab and kick off your sandals!

• To start a terminal window in Linux, look for the Terminal program on the GUI’s program menu. It may be called Terminal, Term, Xterm, or something similar.

• On the Mac, start the Terminal application, which is found in the Utilities folder. Access this folder from the Finder by clicking Go > Utilities from the menu or by pressing the Shift+Command+U keyboard shortcut.

• In Windows 10, open the Microsoft Store and search for the Ubuntu app. It’s free to download, but to make it work you must also install the WSL. Directions for installing the subsystem are splattered all over the Internet.

The Windows 10 Ubuntu app is shown in figure 1.6. Like all other terminal windows, it can be customized: you can reset the font size, the number of rows and columns, screen colors, and so on. Be aware that the traditional text mode screen supported 80 columns by 24 rows of text.

Figure 1.6 Linux in Windows—such sacrilege

If you plan on using the terminal window for your program production, I recommend keeping a shortcut to the Terminal program available for quick access. For example, in Windows, I pin a shortcut to the Ubuntu shell on the taskbar. On the Mac, I have my Terminal window automatically start each time I sign into OS X. Directions for accomplishing such tasks are concealed on the internet.

1.3.2 Reviewing basic shell commands

I bet you know a few shell commands. Good. In case doubt lingers, table 1.1 lists some commands you should be familiar with to make it easy to work at the command prompt. These are presented without context or further information, which helps maintain the command prompt’s mysterious and powerful aura.

Table 1.1 Shell commands worthy of attention

Each of the commands listed in table 1.1 has options and arguments, such as filenames and pathnames. Most everything is typed in lowercase and spelling errors unforgivable. (Some shells offer spell-check and command completion.)

Another command to know is make, which helps build larger projects. This command is covered later in this book. I’d list a chapter reference, but I haven’t written the chapter yet.

Also important is to know how the package manager works, though with many Linux distros you can obtain command-line packages from the GUI package manager. If not, familiarize yourself with how the command-line package manager works.

For example, in Ubuntu Linux, use the apt command to search for, install, update, and remove command-line software. Various magical options make these things happen. Oh, and the apt command must be run from the superuser account; onscreen directions explain the details.

My final recommendation is to understand the file-naming conventions. Spaces and other oddball characters are easy to type in a GUI, but at the command prompt, they can be nettlesome. For the most part, prefix spaces with the backslash character, , which acts as an escape. You can also take advantage of filename completion: in bash, zsh, and other shells, type the first part of a filename, and then press the Tab key to spew out the rest of the name automatically.

File-naming conventions also cover pathnames. Understand the difference between relative and absolute paths, which helps when running programs and managing your files.

I’m sure you can find a good book somewhere to help you brush up on your Linux knowledge. Here is an obligatory plug for a tome from Manning Publications: Learn Linux in a Month of Lunches, by Steven Ovadia (2016). Remember, it’s free at the library.

1.3.3 Exploring text screen editors

To properly woo the command prompt, you must know how to use a text mode editor. Many are installed by default with Linux. Those that aren’t can be obtained from your distro’s package manager. On the Mac, you can use the Homebrew system to add text mode programs that Apple deems unworthy to ship with its operating system; learn more about Homebrew at brew.sh.

My favorite text mode editor is VIM, the improved version of the classic vi editor. It has a terminal window version that runs in text mode as well as a full GUI version. The program is available for all operating systems.

The thing that ticks off most coders about VIM is that it’s a modal editor, which means you must switch between text editing and input modes. This duality drives some programmers crazy, which is fine by me.

Another popular text mode editor is Emacs. Like VIM, it’s also available as a text mode editor as well as a GUI editor. I don’t use Emacs, so I am unable to wax eloquent upon its virtues.

Whatever text editor you obtain, ensure that it offers C language color-coding as well as other helpful features like matching pairs: parentheses, brackets, and braces. With many editors, it’s possible to customize features, such as writing a startup script that properly contorts the editor to your liking. For example, I prefer a four-space tab stop in my code, which I can set by configuring the .vimrc file in my home directory.

1.3.4 Using a GUI editor

It may be scandalous, but it’s convenient to use a GUI editor while you work at the command prompt. This arrangement is my preferred programming mode: I write code in my editor’s glorious graphical window and then build and run in the dreary text mode terminal window. This arrangement gives me the power of a GUI editor and the ability to examine text mode output at the same time, as illustrated in figure 1.7.

Figure 1.7 A desktop with an editor and a terminal window arranged just so

The only limitation to using a GUI editor is that you must remember to save the source code in one window before you build in the other. This reminder isn’t as much of an issue when you use a text mode editor running in the terminal, because you save when you quit. But when bouncing between two different windows on a desktop, it’s easy to forget to save.

1.3.5 Compiling and running

The command-line compiler in Linux is gcc, which is the GNU version of the original cc compiler from the caveman days of Unix. As I wrote earlier, I recommend using the clang compiler instead of gcc. It offers better error reporting and suggestions. Use your distro’s package manager to obtain clang or visit llvm.org. For the remainder of this chapter, as well as the rest of this book, my assumption is that you use clang as your compiler.

To build code, which includes both the compiling and linking steps, use the following command:

clang -Wall source.c

The compiler is named clang. The -Wall switch activates all warnings—always a good idea. And source.c represents the source code filename. The command I just listed generates a program file, a.out, upon success. Warnings may also yield a program file; run it at your own peril. Error messages indicate a serious problem you must address; no program file is generated.

If you desire to set an output filename, use the -o switch followed by the output filename:

clang -Wall source.c -o program

Upon success, the previous command generates a program file named program.

The compiler sets the program’s executable bit as well as file permissions that match those for your account. Once your program is created, it’s ready to run.

To run the program, you must specify its full pathname. Remember that in Linux, unless the program exists in a directory on the search path, a full pathname must be specified. For programs in the current directory, use the ./ prefix, like so:

./a.out

This command runs the program file a.out, located in the current directory, as shown here:

./cypher

This command runs the program name cypher, again located in the current directory.

The single dot is an abbreviation for the current directory. The slash separates the pathname from the filename. Together, the ./ forces the shell to locate and run the named program in the current directory. Because the program’s executable bit is set, its binary data is loaded into memory and executed.

1.4 Libraries and compiler options

As someone who aspires to improve the craft, you must be aware of the assortment of compiler options—specifically, those that link in libraries. These libraries expand a mere mortal C program into realms of greater capabilities.

All C programs link in the standard C library. This library contains the horsepower behind such functions as printf(). Yet, it’s a common misconception among beginning C programmers that it’s the header file that contains the oomph. Nope. The linker builds the program by combining object code (created by the compiler) with a C language library.

Other libraries are also available, which are linked in addition to the standard C library to build complex and interesting programs. These libraries add more capabilities to your program, providing access to the internet, graphics, specific hardware, and a host of other useful features. Hundreds of libraries are available, each of which helps extend your program’s potential. The key to using these libraries is to understand how they’re linked in, which also raises the issue of compiler options or command-line switches.

As you may expect, methods of adding options and linking libraries differ between the IDE and command prompt approaches to creating programs.

1.4.1 Linking libraries and setting other options in an IDE

One area where using an IDE becomes inconvenient is the task of setting compiler options or specifying command-line arguments. Setting the options includes linking in a library. You must not only discover where the linking option is hidden but also confirm the location of the library on the filesystem and ensure that it’s compatible with the compiler.

I don’t have the time, and it’s really not this book’s subject, to get into specifics for each IDE and how they set command-line arguments for the programs you build or how specific options are set, such as linking in an extra compiler. After all, I push command-line programming enough—get the hint! But if you insist, or you just enjoy seeing how difficult things can be, read on. For brevity’s sake, I’ll stick with Code::Blocks because I know it best. Other IDEs have similar options and settings. I hope.

Compiler options in Code::Blocks are found in the Settings dialog box: click Settings > Compiler to view the dialog box, shown in figure 1.8. This is the same location where you specify another library to link.

Figure 1.8 Finding useful stuff in the Code::Blocks’ Settings dialog box

Preset options are listed on the Compiler Flags tab, illustrated in figure 1.8. This tab is a subtab of the Compiler Settings tab, also called out in the figure. The command-line switches for each option are shown at the end of the descriptive text.

Use the Other Compiler Options tab to specify any options not found on the Compiler Flags tab. I can’t think of any specific options you might consider adding, but this tab is where they go.

Click the Linker Settings tab (refer to figure 1.8) to add libraries. Click the Add button to browse for a library to link in. You must know the folder in which the library file dwells. Unlike command-line compiling, default directories for library files aren’t searched automatically. Ditto for header files, which are often included in the same directory tree as the libraries.

To specify command-line arguments for your programs in Code::Blocks, use the Project > Set Programs’ Arguments command. The problem here is that the apostrophe is misplaced on the menu; it should read Program’s. I mention this because my editor will query me otherwise.

After choosing the grammatically incorrect Set Programs’ Arguments command, you see the Select Target dialog box. Use the Program Arguments text field to specify required arguments for the programs you run in the IDE. The limitation here is that your command-line program must be built as a project in Code::Blocks. Otherwise, the option to set command-line arguments is unavailable.

Please be aware that the tiny programs presented in this book are designed to run at the command prompt, which makes it weird to set arguments in an IDE. Because the IDE creates a program, you can always navigate to the program folder to run the program directly at a command prompt. If possible, discover whether your IDE allows you quick access to the folder containing the program executable. Or just surrender to the inevitable ease and self-fulfilling joy of programming in a terminal window.

1.4.2 Using command-line compiler options

It’s easy and obvious to type compiler options and program arguments at a command prompt in a terminal window: no extra settings, menus, mouse clicks, or other options to hunt for. Again, these are many of the reasons programming at the command prompt makes sense for the programs presented in this book, as well as for lots of tiny C projects.

Of the slate of command-line options, one worthy of note is -l (little L). This switch is used to link in a library. The -l is followed immediately by the library name, as in:

clang -Wall weather.c -lcurl

Here, the libcurl library, named curl, is linked along with the standard C library to build a program based on the weather.c source code file. (You don’t need to specify the standard C library, because it’s linked in by default.)

To specify an output filename, use the -o switch as covered earlier in this chapter:

clang -Wall weather.c -lcurl -o weather

With some compilers, option order is relevant. If you see a slew of linker errors when using the -l switch, change the argument order to specify -l last:

clang -Wall weather.c -o weather -lcurl

At the command line, the compiler searches default directories for locations of library files as well as header files. In Unix and Linux—but not OS/X—these locations follow:

• Header files: /usr/include

• Library files: /usr/lib

Custom library and header files you install can be found at these locations:

• Header files: /usr/local/include

• Library files: /usr/local/lib

The compiler automatically searches these directories for header files and libraries. If the library file exists elsewhere, you specify its pathname after the -l switch.

No toil is involved in specifying command-line arguments for your programs. Unlike an IDE, the arguments are typed directly after the program name:

./weather KSEA

Here, the weather program runs in the current directory with a single argument, KSEA. Simple. Easy. I shan’t use further superlatives.

1.5 Quiz

I decided against adding a quiz.