kcomex | 03 June, 2008 16:53

Open C is a quite powerful tool when porting open source projects to Symbian OS platform. But a mobile kitty is not a desktop monster, it doesn't have a so powerful kernel, especially you encountered some design limitations. For small projects which don't utilize lower or system level functions, you will wield Open C without any pain. However, projects as large as Mozilla will meet the limitations and avoid using incomplete or absent functions. So marking those limitations with good documentation and practical experiences is very important. Here I will try to tell you some of my experiences.

First of all, you need to read Open C documents carefully, Nokia and Symbian try to explain every limitation they know as clear as possible. So you don't need go discussion board and ask questions before check the documents. *BUT ACTUALLY*, the problem is not all about checking Open C documents, there are possibilities the problem is not caused by Open C but your code. In this case, the situation is not easy. You need practical experiences from others, by talking with colleagues or searching discussion board.

Here comes the body. The most incomplete group is libc Signal Handling, but what's lucky is we can find absence of these functions, you don't need to determine where the problem comes from, your code or Open C. The second hard one to over come is using posix_spawn() instead of fork() and exec(). Here I would give you a suggestion, read the complete fork() manual and compare the difference between posix_spawn(). Then check the context of your code, see if these differences applied. This technique is not so easy, even there are further hidden side effect, for example "In the child process created with popen3/popen/system/posix_spawn, operations on the inherited file may cause a panic." in P.I.P.S. V1.3 Release Notes. Bear in mind those side effects from practice, then the job would be less tough.

With two big stop showers ahead, I think the most important is not getting those limitations one by one, but a skill to find if the bug comes from _my_ code or Open C. Once the debug tricks are at hand, there won't be anything "won't fix"