Parameters, Arguments and Options

There is a confusing concept about each one. You use this all the time, you know exactly how they work, but until the moment to try to write about it, you get asking yourself: “parameter or argument”? To this list, I added Options too. Why? Because parameter is often used when you are reading man pages.

You can read the differences between then in Wikipedia or in other places, but I’ll try a simpler, more visual approach. There are two main contexts where you use these terms: in 1) programming and in 2) command-line interface context.

Programming Context

  • ¬†(formal) parameter: is the variable in a function definition or in a prototype declaration, and is used to denote type. Example:

  • ¬†(actual) argument: is the value or expression in a function call, and is used to denote an instance. Example:

 Command-line Interface Context

In this context, the terms CLI argument or parameter are used interchangeably. The intent is to detail some terminology, not all possibilities, such as --longoptions and other combinations. Take for example the following:

$ cmd -xarg something

  • -x is an option, called also switch or flag, which is a parameter/CLI (command-line interface) argument
  • -xarg (or -x arg) is an option plus its option argument (sometimes optional), which is a parameter/CLI argument
  • something is a parameter/CLI argument
  • -xarg something (the whole thing after cmd) is also a parameter/CLI argument

It’s a logic exercise.

Calling C from Lua

The same title of the Chapter 26 of Roberto Ierusalimschy book Programming in Lua. Although the chapter (and all the book) is very clear, what is not so clear is where the pieces fit together and what to do to really call C from Lua, how to compile the library, etc.

It’s pretty comprehensible he didn’t cover this: Lua runs on a variety different environments and it’s impossible to cover them all. Here I’ll cover a POSIX-compatible (pretty much a Unix-like, although there are non-Unix systems which are compatible too) system. Windows uses a very different approach.

First, fit all C pieces together. If this sounds ilogical, read the chapter. This is a complement, not the whole history.

Note the line 22 highlighted above. You should link your library against Lua 5.1. Starting from 5.2, it uses a new function called luaL_newlib(). If you want to link agains Lua 5.2, it’s just a matter to uncomment line 23 and to comment line 22.

You should locate where your Lua headers are installed. For third-party packages, they’re normally under /usr/local/include. Since I usually have both Lua 5.1 and 5.2, they are separated. In my case, they are in /usr/local/include/lua-5.1. This directory will serve as a parameter to the gcc -I option.

You should also locate where your shared libraries are. For third-party packages, they are usually under /usr/local/lib. This directory will serve as a parameter to the gcc -L option.

Shared libraries in the directory specified with -L have a lib*.so.* pattern. As an example, if your shared library file is called, your library is called lua5.1. If you don’t have a good understanding of it, this should help.

OK, we are ready to go. To compile your library, run the following command:

$ gcc -shared -I/usr/local/include/lua-5.1 -lm mylib.c

Some explanation of what options tells what to gcc:

  • -I and -L were explained above
  • -shared option tells gcc to create a shared library instead of an executable
  • -llua5.1 to link against Lua 5.1
  • -lm since we are using functions from the Standard C Library, we should link against it too
  • -o filename of the library

Time to use Lua hat. It’s trivial to use this library:

On command-line, you should see this:

That’s it. If you find any typos, errors, please notify me.
Thank you for your attention.

Edit: As pointed out by Philipp Janda in lua-l mailing list, on some Unices Lua exports its symbols from the executable by default, and linking with liblua isn’t necessary.

Answers Series – Accelerated C++ (Chapter 0)

This is the first post of the Answers Series, and it is related to the book Accelerated C++, Practical Programming by Example, by Andrew Koenig and Barbara E. Moo, Addison-Wesley, 2000, ISBN 0-201-70353-X.

You can send any corrections to or, better, using github itself (clone the repository and send a pull request).

Programming Books “Answers Series”

This is the beginning of a series of posts of answers to the problems programming books present to readers. Despite the fact that some say this is a way to discourage students to really solve the problems, I will spoil do anyway.

The real difference here is that all the files are versioned in a github repository. This has the benefit that someone might clone it to compile, test, modify and learn, with no need to copy it by hand at every exercise. It also allows others to make a pull request so I can correct the not-so-correct-answers.

At first, although it’s reasonable to have a repository for each book, I won’t (for the moment, at least).

The first post will follow soon…

The format

The answers will always be versioned, whatever contains code or not.

  1. Exercises that only require code, there is nothing to explain.
  2. Exercises that require some explanation and code, the explanation will be given as a comment in code.
  3. Exercises that do not require code will be answered as comment only.

This makes it easy for readers to eventually send corrections through github.

vCard (.vcf from Google Contacts) to abook (mutt) – vcf2abook

abook is a book program. In other words, it manages contacts. It can be used in conjuction with mutt, a MUA (mail user agent), very common in Unix environments. vcf2abook is a conversion tool from vCard to abook format or, better put, to migrate Google Contacts entries to mutt.

It’s very alpha, but worked OK for me. Instructions are included in the file itself (Perl).