C development on Linux – Building a program – X.

Introduction

After all that theory and talking, let’s start by building the code written through the last nine parts of this series. This part of our series might actually serve you even if you learned C someplace else, or if you think your practical side of C development needs a little strength. We will see how to install necessary software, what said software does and, most important, how to transform your code into zeros and ones. Before we begin, you might want to take a look at our most recent articles about how to customize your development environment:

Read more

C development on Linux – Coding style and recommendations – IX.

Introduction

You may wonder what is meant by the title. Code is code, right? It’s important to be bug-free and that’s that, what else? Development is more than writing code and testing/debugging it. Imagine you have to read someone else’s work, and I suppose you already done that, and all the variables are named foo, bar, baz, var, etc. And the code isn’t commented nor documented. You will probably feel the sudden urge to invoke unknown gods, then go to the local pub and drown your sorrows. They say that you should not do unto others what you don’t want done unto you, so this part will focus of general coding guidelines, plus GNU-specific ideas that will help you have your code accepted. You are supposed to have read and understood the previous parts of this series, as well as solve all the exercises and, preferably, read and wrote as much code as possible.

Recommendations

Before starting, please take note of the actual meaning of the word above. I don’t, in any way, want to tell you how to write your code, nor am I inventing these recommendations. These are the result of years of work by experienced programmers, and many will not just apply to C, but to other languages, interpreted or compiled.

Read more

C development on Linux – Comparison between C and other programming languages – II.

Introduction

Since in our first part of this article we said we expected you, the reader, to have some programming knowledge, in this part we want to help you get a on where C stands in comparison to other programming languages you might know. The choice of those languages was pretty tough because of various criteria, but in the end we stopped at C++, Perl and Python. Since programming languages can be classified in lots of ways (depending on paradigm, syntax or style, for example), we didn’t try to find languages that are in the same category as C. Instead, since the aforementioned languages are pretty popular in the Linux world, we chose them, mentioning what every language’s place is in the great scheme, what it’s generally used for and of course, the differences between them and C. This article will be structured as follows: we’ll start with important elements of every language, like variable declaration, typing or structure and compare that with how it’s done with C. Thusly we hope to give you an idea about the language before we start. The parts this article is made of will be exactly like the announced structure of this article, to make comprehension easier.

The comparison

Types, operators, variables

C++

C++ was initially named “C with classes”, which says a lot about its’ relation with C. It is widely seen as a superset of C ( thus C++ the unary increment operator ++ ) , introducing object-oriented programming features. Types are essentially used the same, with bool being introduced in C++ for boolean operations. Basically, when talking about C and C++ differences, most of those come from the OOP concepts C++ has and C does not. For example C++ has operator overloading, an OOP-specific term, which means that an operator may have different implementations depending on the data it’s operating on. For example, in C++ you can do this:

 
a << 2

Now, if a is an integer, this will do a bitwise operation on it (left shift by 2), but if a is an output stream, the above line will try to write a ‘2’ to it. This kind of behavior is one of the reason C++ is criticized for allowing poor programming practices. Variables and constants are declared the same way as in C.

Read more

emacs

Programmer’s friend – the editor: Part 2 – emacs

Introduction to part two

In part one we introduced you to Linux editors and gave a storm course on vim. It’s now time to dismantle the rumors that we’re subjective and talk about the other side, emacs. In some ways, the two editors are opposite one another, mainly from historical reasons, as you will see. We hope you will enjoy this tour and that we’ll help you make up your mind.

Introduction and using emacs

I remember writing somewhere in one of my articles that I won’t under no circumstances reveal what’s my editor/WM/DE/Hollywood actor of choice. Not because I consider myself important, but because I want to avoid any flame material. The true reason for which emacs has an entire article’s space, while vim has only half (or less) is the differences between them, and this is what we’ll talk about right now.

History

vim, through its’ predecessor, vi, is very much linked to Unix in terms of evolution, just like emacs is with the GNU movement. Here’s a crucial difference that influenced the design of the two editors. When Bill Joy developed vi in 1976, hardware resources were scarce, and every character sent to the terminal mattered. In order to imagine what we’re talking about, imagine that vi version 2.0 was still (almost) too big to fit inside the memory of a PDP-11/70. So this is the reason why vi(m)’s commands are short and perhaps cryptic for a beginner, and maybe that’s why it has its’ well-known simplicity. emacs is a wholly different story. It has over 2000 (yes, two thousand) built-in commands and many critics acuse it for its’ size and overly complex commands. The name stands for “Editing MACroS”, but it’s said that it also has to do with a certain ice cream store in Cambridge, MA. Why Cambridge? Because the man responsible for emacs is none other than Richard Stallman, aka RMS, who was working at MIT at the time. That leads to one conclusion: working at MIT equals Richard had access to more powerful hardware, where characters or buffer space weren’t an issue, at least not in the amount Bill Joy had to deal with. So although the first year of existence is the same – 1976 – access to hardware made a difference. Not the only one, but an important one, for sure.

Read more

vim

Programmer’s friend – the editor: Part 1 – Introduction and vim

Introduction

As we’re nearing the end of the C series it becomes more and more obvious that we need to learn more about the tools, about the practical side of programming. And one essential aspect is the editor. Of course, that’s not to say that the editor is only needed when programming. While Linux has GUIs more and more advanced, given its’ heritage you will sooner or later have to use the command line and an editor you are comfortable with to edit some config file. So choosing and knowing at least one editor that’s available for Linux is more than important. Here’s what our article is here to do, and the only thing expected from the reader is patience and some free time.

A theoretical background

Don’t worry: while the subtitle might seem a little demanding, don’t expect fancy and hard-to-read terminology. But we felt the need to have a little introduction from a more technical point of view.

Linux offers a choice of editors that is too wide at times. How so? Well, if you are a beginner, you will need an editor and start searching the net with terms like “Linux editor”. In a matter of seconds you will find blog posts, forum posts, mailing list posts, articles and tutorials on the matter, each and every one telling you how editor X is the best and the other editors are no good. Confusion will ensue in a matter of minutes. This is where what you’re reading right now (hopefully) helps. We want to give you a short classification of available Linux editors, then give you a blitz tutorial on the most popular: vim and emacs.

GUI or CLI?

Although we don’t really appreciate giving advice and prefer respecting everyone’s taste, here’s a piece of advice: forget about “use that editor, it’s more 31337 than the others! You will be so k3w1, d00d!”.

Read more

C development on Linux – Getting a package in the official Debian repositories – XII.

Introduction

This is the last installment of our C development series, and arguably the most non-technical one. If you followed us from the beginning and practiced as much as possible, you now have some basic knowledge on C development and how to package your (favorite) application for two of the most used Linux distribution families, Debian and Redhat. This article is about the community, how to contribute, how to collaborate and finally, how to get your package in the official Debian archives. If you read the previous articles in the series you won’t need any other technical knowledge; all you need is the will to put your knowledge to work for community’s benefit.

Getting started

You have an application, you packaged it and now you’re anxious to upload it to the Debian archives (by the way, many of the ideas presented here apply to many Open Source projects: what differs usually is the way of doing things). We’d say not so fast. Take a minute to breathe and find ways to make yourself known to the community. Take some time to read the Debian New Maintainer’s Guide, if you haven’t already, and remember the key word here: community. Everyone is a volunteer, and we chose Debian especially because of its democratic views, and nobody is paid or forced in any way to do your bidding. Anyway, since we know how much you like to read guides and manuals, part of this article will consist of some sane advice regarding collaboration. First, get used to get by on your own. Nobody likes a person that, when he or she hits the first sign of trouble, instead of going to the best Internet friend, $SEARCH_ENGINE, start polluting the forums, mailing lists and IRC channels with puerile questions like “What gcc flags do I need to compile my code for i686?”. The only thing you will gain is a less than friendly RTFM and lots of missing geek points. Yes, we know that the gcc manual is big and a sure shot for headaches, but reading the manual, then searching the net first is the Right Way (TM). No exceptions. You will make a first good impression when you show the other developers that you made your homework. On the other hand, giving beginners a hard time, especially when such behavior is not called for, will not get you any popularity. Remember that you were once like them, remember that you, as we all, still have a lot to learn, and perhaps point the person towards a resource you think is helpful. In this context, remember that word again: community. Your work doesn’t mean much, despite the fact that it means the world to you, unless the community finds it useful. Collaborate with them and be ready to accept feedback, and be thankful for it, even though you might not like what you hear. Leave your pride at the door and remember that the best and maybe only way to make your software better is community feedback. But don’t fall into extremes, and try to be impartial. Perhaps some people will try to put you down just for the fun of it: ignore them and concentrate on constructive criticism.

Read more

C development on Linux – Packaging for Debian and Fedora – XI.

Introduction

You’re already in the know regarding the C programming language. You got the taste of it and felt like you want to go further and write your own. Or maybe help the community and package that favorite software of yours for the distribution you like and use. Regardless of the situation, this part of the C development series will show you how to create packages for two of the most popular distributions, Debian and Fedora. If you read our articles so far and you have some solid knowledge of the command line, and you can say that you know your distro of choice, you’re ready.

Before we go further…

Let’s get some concepts and general ideas out of the way, just so we make sure we are on the same page. What we are about to outline here is available regardless of the project you decide to package (or contribute) for, be it Arch, NetBSD or OpenSolaris. The idea is: be careful. Check the code, whether it’s yours or not, and make sure you remember that perhaps lots of people will use your code. You have a responsibility on your hands, and a pretty big one at that. If you doubt this, reverse places for a second: a package maintainer isn’t careful when inspecting code and some sneaky, but grave bug makes his way installed on your computer. It’s sneaky, as it only manifests itself on certain hardware and in certain situations, but it’s grave enough to delete all the files resident inside your home folder. You happen to have that exact combination of hardware and mayhem ensues, as you forgot to write to DVD those pictures from your holiday. You get angry, your first reaction is to manifest negative feeling towards the operating system (or distribution) and so, following your decision to change distributions immediatley, that distro loses one user, all because one person’s lack of attention and thoroughness.

Debian

Given Debian’s excellent documentation, we won’t be able to cover all the things one needs to become a developer. After all, this is not what we wanted. What we wanted is to show you basically how to get from a tarball to a .deb. Becoming a Debian developer takes lots of time and involves you helping out the community via IRC or mailing lists, reporting and helping fixing bugs, and so on, so that is not the object of our article. Have a look at the documentation the project provides for more insight. The Debian policy, New maintainer’s guide and the Developer’s reference are more than important for starting up, they must be like some kind of a book you sleep under the pillow with.

Your first stop should be, as outlined above, the policy, where you MUST acquaint yourself with the filesystem hierarchy, the archives, the fields in a control file and specific items to be remembered regarding diferent categories of software: binaries, libraries, source, games, documentation, … Remember that a .deb file is nothing more than an archive, and it’s made of two parts: the control part, with the control file and the install/ uninstall scripts, and the payload, where the files to be installed reside. It’s not as hard as one would think it is. It’s a very good idea that you download a .deb file, even better if it’s packing some software you are familiar with, and start looking inside to see what’s what. [HINT] – You can use the control file to create your own, as long as you’re careful. As an example, let’s take vim. deb files are nothing but ar(1) archives, so they can simply be unpacked by using the following linux command:

 $ ar vx vim-nox_7.3.547-5_amd64.deb

Read more

C development on Linux – Basic I/O – VIII.

Introduction

With this part of our C development on Linux article we are getting ready to get out of the theoretical zone and enter the real life one. If you followed the series until this point and tried to solve all the exercises, you will now have some idea about what C is about, so you need to get out in the wild and do some practical stuff, without which theory doesn’t have much value. Some of the concepts you’ll see below are already known, but they are extremely important for any C program on any Unix-like OS. Yes, the information is valid regardless of the OS, as long as it’s some kind of Unix, but if you’ll stumble onto something Linux-specific, you will know. We will treat concepts like standard input, output and error, in-depth printf() and file access, among others.

Read more

C development on Linux – Structures – VII.

Introduction

We will continue in this part of our tutorial with the complex data types in C, and we will talk about structures. Many modern programming languages offer them, one shape or another, and so does C. As you will see later, structures allow you to manipulate data easier, by allowing you to store different variables of (possibly) different types under one single “roof”.

Beginning structures

Although I wanted to postpone the definition part for this sub-chapter, it seems like I couldn’t wait and included it in the introduction. Yes, folks, that’s what a structure is, and you will see in a whim how useful it is when I will show you some examples. One interesting parallel is the one referring to a database table: if you have a table called users (the unique name), then you will put in that table the exact data which pertains directly to the users: age, gender, name, address, and so on. But these are different types! No problem, you can do that with a table, just as you can do it with a struct: age will be an integer, gender will be a char, name will be a string and so on. Then you will be able to access the members of the table easily, by referring to the name of the table/member. But this is not a database course, so let’s move on. But before that, let’s take a short look at a logical aspect: you are invited to create structs with members that have something in common from a logical point of view, like the example above. Make it easier for you and the people that will later look at your code. So, let’s see how our users database table would translate in a C struct:

Read more

Pointer to array

C development on Linux – Pointers and Arrays – VI.

Introduction

We have come to a crucial point in our series of articles regarding C development. It’s also, not coincidentally, that part of C that gives lots of headaches to beginners. This is where we come in, and this article’s purpose (one of them, anyway), is to debunk the myths about pointers and about C as a language hard/impossible to learn and read. Nonetheless, we recommend increased attention and a wee bit of patience and you’ll see that pointers are not as mind-boggling as the legends say.

Definitions and warnings

It seems natural and common sense that we should start with the warnings, and we heartily recommend you remember them: while pointers make your life as a C developer easier, they also can introduce hard-to-find bugs and incomprehensible code. You will see, if you continue reading, what we’re talking about and the seriousness of said bugs, but the bottom line is, as said before, be extra careful.

A simple definition of a pointer would be “a variable whose value is the address of another variable”. You probably know that operating systems deal with addresses when storing values, just as you would label things inside a warehouse so you have an easy way of finding them when needed. On the other hand, an array can be defined as a collection of items identified by indexes. You will see later why pointers and arrays are usually presented together, and how to become efficient in C using them. If you have a background in other, higher-level languages, you are familiar with the string datatype. In C, arrays are the equivalent of string-typed variables, and it is argued that this approach is more efficient.

Read more

C function prototype, definition,call

C development on Linux – Functions – V.

Introduction

The C standard library offers a plethora of functions for many usual tasks. Also there are lots of libraries for extra functionality, like GUI design (GTK+) or database interfacing (libpq). However, as you advance in the C programming world, you will soon find yourself repeating the same instructions in the same order over and over again and that will become time-consuming and inefficient. So you can just wrap all those instructions in a function and just call said function when you need it. Here’s what you’re gonna learn by reading this article, plus some useful tips that will make your life easier.

Creating your functions

For a simple start, let’s say you wanna write a calculator. We won’t focus on the interface (GUI vs curses vs slang vs CLI) as we’re interested on the internals. It would be clunky to not create a function for every operation you decide to support, unless there is one already, like pow() , defined in math.h, which returns the result of a base raised to a power. So, for example, for addition you will have a function named add() that takes two arguments, at least for now, and returns the result. So when the user chooses to add the number (s)he introduced, you just call the function with the numbers the user entered and you needn’t worry about anything else. These three terms that I wrote in italics are essential in understanding functions. A function usually (but not always) takes something, does a number of operations on that something and spits out the result. “Not always” because main(), as you could see before, can be called with no arguments, and there are other examples as well. But for now, let’s focus on our examples. The numbers that need to be added together are the arguments, that “something” you give the function for processing. The processing part is in the body of the function, when you tell it to add the numbers together. After that, the “spitting out” part is called returning a value, which is, in our case, the result of the addition.

Read more

while loop interactive C

C development on Linux – Flow Control – IV.

Introduction

You have already been exposed to a small part of what flow control is in our previous part, namely the section about relational operators. As you start writing more complex programs, you will feel the need to control the order in which your program executes various parts.
Flow control is present in most programming languages in one form or another, and what you’re about to read here is essential to writing C programs.

if/else/else if

This part of flow control is probably the most intuitive and simpler, although you can easily fall to the dark side and start writing unintelligible code with ifs. The idea is simple: if (condition_is_true) do_something; else do_something_else; . So it’s all about logic, binary logic that is, in which an expression can have two values: true or false. If you used C or Java, you’re used with the bool datatype. A bool variable can be only true or only false at a given moment. But C, although it doesn’t have the bool datatype, makes it easy to deal with binary logic, as you will see.

Read more