To be honest this is the first day I come out with something useful, and this would not be so bad if only I didn’t waste about one week in pointless experiments. A lot of effort has been spent in trying to figure out how Eclipse works. I’m totally not a big fan of IDEs: I’ve always preferred the GNU/Linux Shell and a good text editor (yes, I’m a Vim user), but I feel I can get used with some exercise. I just hope to speed up a little, or I will never finish!

Enough philosophy for today, let’s talk about Hibernate. There’s no much to say anyways…

Ingredients for the recipe:

• A chroot sandbox for the mysql daemon (I like to separate stuff, and a chroot jails are just awesome)
• All required libraries as explained here;
• The java connector for mysql, which can be found here.

As probably half of the pepole who tried this, I experimented some troubles in figuring out why the gorram “hibernate.cfg.xml” file cannot be found by the library. The problem was actually rooted in my lack of experience with Java, but I guess that the cumulated experience will prevent me from stumbling again in such trivial issues.

Meh. What a useless post…

$ echo 'my password' | su
su: must be run from a terminal

It’s said that he great power of the Unix operating system comes from the fact that everything is a file. So they say (I guess it’s pretty ok).

It’s true that abstraction removes the hassle of checking case-by-case what’s going on, but this doesn’t mean that if you want to do it you cannot!

The fstat system call can be useful in that. Let me show you this piece of code:

$ more test.c

#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>

int main ()
{
    struct stat buf;

    if (fstat(0, &buf) == -1) {
        perror("Eh...");
    }

    const char * cases[] = {
        "regular", "directory", "chardev",
        "blockdev", "fifo", "link", "socket",
        "?"
    };

    int t = S_ISREG(buf.st_mode)    ? 0:
            S_ISDIR(buf.st_mode)    ? 1:
            S_ISCHR(buf.st_mode)    ? 2:
            S_ISBLK(buf.st_mode)    ? 3:
            S_ISFIFO(buf.st_mode)   ? 4:
            S_ISLNK(buf.st_mode)    ? 5:
            S_ISSOCK(buf.st_mode)   ? 6:
                                      7;

    printf("stdin is %s\n", cases[t]);
}

$ make test
cc     test.c   -o test

$ echo hello | ./test
stdin is fifo

$ ./test
stdin is chardev

$ cat /etc/fstab | ./test
stdin is fifo

I didn’t check the source code for the su command, but I guess this would work

Worthy read.

The problem… I hate warnings!

The solution comes strightforward: compile src/conf.erl before anything else. How to do that? Well, I surfed the Internet, searching for solutions. It turns out that, for instance, ejabberd is using Autotools instead of the standard Erlang compile system. Autotools are a really nice piece of crap software, but I don’t have time to discover how to use it with Erlang.

Then I just reconnected my brain…

Easy huh?

Note: Place the

-pa

-make

As you probably know, a good idea here would be using a mapping instead, say a Hash table, to store the elements you would put in the matrix with the coordinates as keys. In order to explain this concept to a friend of mine, I sketched an implementation of this principle in Python, and soon I realized it’s extremely easy!

Just look at this:

>>> class Foo:
... def __getitem__ (self, *args): print(args); return 0
... def __setitem__ (self, *args): print(args);
...
>>> test = Foo()
>>> test[1]
(1,)
0
>>> test[1,2,3]
((1, 2, 3),)
0
>>> test[5,6,7] = 100
((5, 6, 7), 100)
>>>


Does that ring some bell in your mind?

>>> M = dict()
>>> M[1,2] = 300
>>> M[1,2]
300


Yes, is that simple. It has just one drawback:

>>> M[100,200]
Traceback (most recent call last):
File "", line 1, in
KeyError: (100, 200)


But it can be solved very easily! Do you remember how awesome is the collections.defaultdict class?

>>> from collections import defaultdict
>>> M = defaultdict(lambda : 0)
>>> M[1,2] = 300
>>> M[1,2]
300
>>> M[100,200]
0


Surprisely nice huh? Happy hacking!

The wise C programmer knows how souce code gets linked, so he or she is also aware of how symbols are managed into object code. In our module we typically want to export some symbols, like for instance a function or, if you really need to do it a global variable. Note also that types are not object symbols.It’s useful to figure symbols from two distinct point of view:

1. From the syntactical/sematical point of view, you’ve the prototypes:
   1. The programmer puts them in the header file;
   2. The compiler uses them for static checking.
2. From the low level side there are object symbols:
   1. The assembler puts them in the object file;
   2. The linker uses them as reference in order to produce the executable.

The private symbols which we are talking about are not supposed to be exported, thus they

1. Don’t get represented in header files;
2. Are declared static in the module.

A bit confused? An example will make it clear!

Example module

Suppose we want to provide a function which computes the squared norm of a vector v. The norm is defined as

and we will provide | | v | | ². We need the function square in order to compute , but we don’t want to export it, since it’s just an auxiliary function.

Naive source code

Let’s write it in a naive way: for the moment we just write the needed functions in the file norm.c:

#include "norm.h"

double square (double value)
{
    return value * value;
}

double norm (double values[], int n)
{
    double acc = 0;
    int i;

    for (i = 0; i < n; i ++)
        acc += square(values[i]);
    return acc;
}

The header file (norm.h) is just what you expect: we define the norm function, and not the square function:

#ifndef __defined_norm_h
#define __defined_norm_h

double norm (double values[], int n);

#endif /* __defined_norm_h */

The main will be the following:

#include <stdio.h>
#include "norm.h"

int main (int argc, char **argv)
{
    double values [] = { 1.0, 3.3, 4.2, 1.2, 9.0 };
    printf("norm is: %G\n", norm(values, 5));
    return 0;
}

Object code after compilation

Of course this natural approach is functional enough, now let’s make it classy. First let’s check what happens after compilation:

dacav@mithril:<test>$ ls
main.c  norm.c  norm.h
dacav@mithril:<test>$ gcc norm.c -Wall -c
dacav@mithril:<test>$ nm norm.o
0000000000000015 T norm
0000000000000000 T square
dacav@mithril:<test>$

As you can see, despite the fact we declared only norm in the header file, the object file still exports square in the .text section. Pragmatically speaking, this is potentially dangerous only in some cases (which we’ll see in a while). However this lets us do something stupid right now. Let’s write this alternative main into the file jerk.c:

#include <stdio.h>

extern double square (double);

int main (int argc, char **argv)
{
    printf("2 square is %G\n", square(2));
    return 0;
}

And link it with the object file we produced before:

dacav@mithril:<test>$ ls
a.out*  jerk.c  main.c  norm.c  norm.h  norm.o
dacav@mithril:<test>$ gcc jerk.c norm.o
dacav@mithril:<test>$ ./a.out
2 square is 4
dacav@mithril:<test>$

As you can see we managed to use the symbol even if it was supposed to be private. You may argue that doing this is kind of a hack you’ll never do, but it’s a nice proof of concept.

If we want to do everything right, we can avoid this pretty easily: just add the static keyword for anything is not declared in the header. In our case we make static only the square function:

static
double square (double value)
{
    return value * value;
}

Let’s see what happens:

dacav@mithril:<test>$ gcc norm.c -Wall -c
dacav@mithril:<test>$ nm norm.o
0000000000000015 T norm
0000000000000000 t square
dacav@mithril:<test>$

Awesome! The object file still has the square symbol in the .text section, but it’s no longer exported! Let’s try to comple again jerk.c as we did before.

dacav@mithril:<test>$ gcc jerk.c norm.o
/tmp/cc5yYxqr.o: In function `main':
jerk.c:(.text+0x18): undefined reference to `square'
collect2: ld returned 1 exit status
dacav@mithril:<test>$

Advantages and Threats

Avoid namespace pollution

As you probably know, the C language doesn’t provide a namespace mechanism as C++ or other languages do. As consequence all symbols exported by a modern enough library are typically decorated with some common prefix. The symbols exported by the OpenGL API, for instance, use the gl prefix. This doesn’t give any further information on what the symbol is about: it’s there just for technical reasons.

Within your module you certainly know what your namespace looks like. Provided that any externally linked library has its common prefix, you don’t want to add prefixes for your private functions as well, since you already know what is module you are writing. In a scenario in which all modules declare private objects as static, any ambiguity is restricted to exported symbols, which are wisely prefixed in order to avoid problems.

Not so hidden ambiguity

Let’s hack again the very first version of our example (the one without static), and suppose we made a mistake in naming square:

// should be "square"!
double squae (double value)
{
    return value * value;
}

Also let’s add another file, something.c, which declares a totally unrelated function square which is supposed to be private. Such a function has also a different signature and does exactly nothing. As we said before, types are not symbols!

dacav@mithril:<test>$ more something.c
void square (void) { }

Now let’s compile everything from scratch.

dacav@mithril:<test>$ ls
a.out*  jerk.c  main.c  norm.c  norm.h  norm.o  something.c  something.o
dacav@mithril:<test>$ rm *o a.out
dacav@mithril:<test>$ ls
jerk.c  main.c  norm.c  norm.h  something.c
dacav@mithril:<test>$ gcc -c norm.c
dacav@mithril:<test>$ gcc -c something.c
dacav@mithril:<test>$ gcc main.c *o

Note that, for the moment, we are not compiling with the -Wall flag (later on I’ll tell you why). Ready for the execution?

dacav@mithril:<test>$ ./a.out
norm is: 5
dacav@mithril:<test>$

Which is wrong: the correct norm is 111.97! What happened?

1. We forgot to make private things static;
2. We also wrote squae instead of square
3. When the linker searched for the square function, he found the one declared in something.c. Since he’s not supposed to run static analysis, any square symbol into the .text section is good enough for him!
4. The square function of something.c does nothing, so the return value is just the content of the return register (which depends on the [ABI]).

Crashed into the -Wall

Things screwed. Let’s do it again with the -Wall option:

dacav@mithril:<test>$ ls
a.out*  jerk.c  main.c  norm.c  norm.h  norm.o  something.c  something.o
dacav@mithril:<test>$ rm *o a.out
dacav@mithril:<test>$ ls
jerk.c  main.c  norm.c  norm.h  something.c
dacav@mithril:<test>$ gcc -Wall -c norm.c
norm.c: In function ‘norm’:
norm.c:14: warning: implicit declaration of function ‘square’
dacav@mithril:<test>$

Well, this saves the day. The compiler noticed that we are using a function which is not declared by an header. Note that the square function is not listed into the norm.h file!

The -Wall option seems to make this discussion pointless, but what if we are using a private function prototypes inside a module? This happens, for instance when we have two functions which reference one another.

Also take this in account: there’s plenty of guys out there, and many of them are not supposed to be programmers. Some day they will need to write some (typically poorly designed) software. They hate warnings or don’t know what the -Walloption is… You got the concept, don’t you?

Not in C++

As I learned, using static in C++ is possible but not advisable. By declaring an anonymous namespace you can obtain the same protection as in static, but you can also protect types. I cannot figure if this is actually useful, however.

Notes

I learned this information by studying how the ELF format works.

typedef struct {
    uint8_t foo;
    uint16_t bar;
} __attribute__((packed)) foo_t;

From the doxygen point of view this could be nasty, since it will start thinking __attribute__((packed)) is the name of the struct.

Doxygen provides a solution to this through a special command inside the Doxyfile:

# The PREDEFINED tag can be used to specify one or more macro names that
# are defined before the preprocessor is started (similar to the -D option of
# gcc). The argument of the tag is a list of macros of the form: name
# or name=definition (no spaces). If the definition and the = are
# omitted =1 is assumed. To prevent a macro definition from being
# undefined via #undef or recursively expanded use the := operator
# instead of the = operator.

PREDEFINED             =

So we can just put a PREDEFINED = DOXYGEN and modify our code as follows:

typedef struct {
    uint8_t foo;
    uint16_t bar;
}
#ifndef DOXYGEN
__attribute__((packed))
#endif
foo_t;

Notes

I learned this trick by reading Alsa ASoundLib’s source code.

In a situation like this we need a dictionary mapping strings to lists of identifiers, and if we see a name for the first time we want an empty list.

Simple and stupid way:

def insert (D, name, id):
    if not name in D:
        l = []
        D[name] = l
    else:
        l = D[name]
    l.append(id)

foo = dict()
insert(foo, "Jack", 2)
insert(foo, "John", 3)
insert(foo, "John", 4)

What we get:

>>> foo
{'John': [3, 4], 'Jack': [2]}

A shorter way:

def insert (D, name, id):
    l = D.get(name, [])
    l.append(id)
    D[name] = l

Advantage: less rows of code;
Drawback: we always spawn a new list as default value.

Best way: Proudly Found Elsewhere

Python library provides this, so we get this functionality for free:

from collections import defaultdict
...
D = defaultdict(list)
D["jack"].append(2)
D["john"].append(3)
D["john"].append(4)

What we get:

>>> D
defaultdict(, {'john': [3, 4], 'jack': [2]})

Bonus trick:

What if we need to associate a single incremental identifier to each element of a certain set of names? Check this out:

import itertools
from collections import defaultdict
...
class Cnt :
    def __init__ (self):
        self.__call__ = itertools.count().next

idgen = defaultdict(Cnt())

We obtain this:

>>> idgen['foo']
0
>>> idgen['bar']
1
>>> idgen['foo']
0
>>> idgen['fubar']
2

Oh! Actually we can obtain the same result in a shorter (and maybe cleaner) way:

idgen = defaultdict(itertools.count().next)
>>> idgen['foo']
0
>>> idgen['bar']
1
>>> idgen['foo']
0
>>> idgen['fubar']
2
>>> idgen
defaultdict(<method-wrapper 'next' of itertools.count object at 0xa815a8>,
{'foo': 0, 'bar': 1, 'fubar': 2})