Showing posts with label c++. Show all posts
Showing posts with label c++. Show all posts

Monday, April 18, 2011

Granumophobia

Getting dynamic linking to work right is a never-ending series of dumped cores. Today I found two bugs which were actually quite generic (i.e. not architecture-specific) and, to be honest, quite silly.

First a sizeof(ptr) instead of sizeof(*ptr) passed to memset() caused the dyn_info_t structure not to be properly zeroed out. If something in dyn_info_t is not zero, it is assumed to be valid entry present in the dynamic section. Hence mysterious occasional crashes. Luckily thanks to the new memory allocator which has debugging turned on there was a suspicious quantity of dead beef being thrown around which slightly helped me find the problem.

Second, the relocation processing code was dying while trying to fix up references to libc variables in the text segment of the main program, which is stored in a memory area with R-X permissions. Huh? Well, the main program is loaded by loader, instead of dynload. Unlike dynload, loader does not make all loaded segments writable. Bummer.

Dynamic linking takes patience. If you suffer from granumophobia, then stay away.

Monday, January 4, 2010

The woes of C

If I wanted to make this article look interesting, I would title it C considered harmful, but I will not. HelenOS is written in C. C is a programming language created at the beginning of 1970's. It's creation is closely tied with the birth of UNIX. At the time of its creation, C was a simple and yet extremely powerful programming language.

C maps (or can map) rather closely to the hardware. Originally it required no or very little run-time support. (What this means: a piece of code using only the core language -- not library routines -- can be compiled directly to machine code and does not require additional libraries or other support to execute).

For quite some time C has been showing its age. Both the core language and the standard library are becoming more and more inadequate for implementation of applications.

Working with strings has always been an extreme pain in C, but with multi-byte encoding (i.e. UCS/Unicode) it has become a nightmare. In HelenOS we decided to drop the standard C99 way of handling multi-byte strings altogether and implement our own. Needles to say, it's only a little better, the language won't allow us more. I demand automatic memory management! I demand user-defined operators!

String formatting in C is a chapter on its own. While this could be re-implemented in the standard library to be extensible (i.e. allow the consumer to register a formatting function for their custom type) we cannot really do away with the need to provide the type of argument in the formatting string, at least not in a sensible way. I demand virtual methods!

What usually drives me mad is the complexity involved in using a hash table in HelenOS. I need to implement several callbacks just to get my int->pointer map. I want generics! I demand collections!

There is a plan to implement a graphical user interface for HelenOS. Having to implement it in C is just giving me the Willies. We would probably end up with some monstrosity like GTK... or worse. I demand inheritance!

I demand a language worthy of the 21st century!

... to be continued.