Descriptors – a milestone in the Symbian C++ learning curve?

I guess many C enthusiast programmers wanting to switch to Symbian code developing, faced some issues when learning about Symbian descriptors. Even if many useful and helpful resources can be found on the Internet, especially those written by Jo Stichbury (personally I would recommend this one a weblog completely dedicated to descriptors, but there are also other ones which can be found on Symbian developer communities or on Nokia forums), some misunderstandings still persist.

Personally I almost do not know anything about descriptors, I have just some scarce knowledge about Symbian in general, but I am struggling to improve. 🙂

Let me tell you how I see the things from a beginner perspective.

First of all two things are important to mention just from the beginning: descriptors (which are somehow equivalent of C arrays) are safer than ordinary C arrays and they are heavily used in transferring data, either on binary format or text.

Before going deeper into descriptors’ understanding I think it is required to clarify why is it so unsafe to use null terminated strings, like those implemented in C.

What is a nul (and it is rather more correct to call it NUL instead of NULL, which has more to do with dynamically allocated pointers – NULL could be something like ((void*)0)) terminated character array?

Let’s turn to Wikipedia and see what is there explained.

There is no place where the length of the character array is stored. It is just calculated by iterating through array’s elements until finding the NUL character. The driving idea of this feature is basically that more memory space is saved in this way than by explicitly storing the size of the string. This method has the advantage of a constant and linear time for calculating the string-length. For those who are familiar with algorithms (here you can skip me) this is O(1).

But on the other hand this created notorious security holes in the code which can be exploited. One of the main drawbacks of it, is that one can “play” with this NUL character and place it wherever he wants.

“Poison null byte” is a security exploit targeting this end-of-string character and it consists in intentionally inserting such character somewhere in the middle of a file name string in order to remove some important part from it.

A common bug in C programming is not correctly bounding a character array by the NUL character. You may find here a more detailed explanation of the errors that a faulty string manipulation in C may generate.

Briefly resuming the ideas from the article indicated above, three types of such error are taken into consideration: unbounded string copies, null-termination errors and string truncation.

Unbounded string copies occur when a string is read as an input using gets() function into a fixed length buffer.
Null-termination errors are when copying via strncpy() function from a source string into a destination string. According to the strncpy function if there is no NUL character encountered in the first n characters in the destination array, the resulted string is not NUL terminated, which is very error-prone.
String truncation, as the names involves, occurs when the destination character array is shorter than the source array. In these situations a buffer overflow is generally avoided by truncating the source array resulting in a loss of data and potentially vulnerabilities.

Let’s just get back to our descriptors. Why are they called like this?
Because they are self-describing: they hold the length of the string they represent and also the type.

What is their length? As you probably guessed it has to be 8 bits. Yes it is so, but there are also 16-bit descriptors which support UNICODE characters. (UNICODE characters are on 16bit and ASCII characters are 8-bit length).