During the debugging and unit test cases running phase, open source projects usually write error string or other information to STDERR file. Quite unluckily, we can not retrieve lines from STDERR in Symbian with Open C. The stdioserver program comes with Open C SDK only redirects STDOUT to a file located on disk, but left STDERR no where to check out.

So in my Mozilla porting days, I have to make a workaround for retrieving information written to STDERR because most of unit test cases write error information to STDERR. There are two workarounds which could be used according to different situation.

If you have only one or not so many .c source files to fix, then I would like to recommend the first way. That is to modify the source code, add these lines as the top most statement:

FILE* stderr_redirect = freopen("C:\\data\\stderr.log", "w", stderr); // Top most line
/* Begin of original code lines */
...
...
...
/* End of original code lines */
fclose(stderr_redirect); // Bottom most line

The other case is that you have many (maybe up to several hundreds) independent .c source files,  so it's almost impossible to adopt  the first way, like NSPR test cases. We have to figure out another solution. Here I did a small trick, that is modify the stdio.h in <EPOCROOT>\Epoc32\include\stdapis in Open C SDK. The stdio.h in looks like this:

...
...
#ifndef __SYMBIAN32__
#define    stdin    __stdinp
#define    stdout    __stdoutp
#define    stderr    __stderrp
#else
__BEGIN_DECLS
IMPORT_C FILE *__stdin  (void);
IMPORT_C FILE *__stdout (void);
IMPORT_C FILE *__stderr (void);
IMPORT_C char * tmpdirname(void);
__END_DECLS
#define stdin       (__stdin())
#define stdout  (__stdout())
#ifdef STDERR_TO_STDOUT
#define stderr  (__stdout())
#else
#define stderr  (__stderr())
#endif
#endif
...
...

These lines are located around line 265 - 283 if you are using Open C SDK v1.3. With the lines shown as light yellow marked, you could know I just let the compiler treats STDERR as STDOUT, sothat information written to STDERR are all redirected to STDOUT. Of course we have to define MACRO STDERR_TO_STDOUT in that .MMP file. And because we don't want this trick infect other projects which don't have their STDERR touched, so we use this macro to mark the  fence. Once STDERR is redirected to STDOUT, then you could use the original stdioserver program comes with the Open C SDK to check out original STDERR information in STDOUT file.

All two ways are easy to understand and use, although I felt the latter one is not so perfect because this requires changing a SDK file. Hope this tip will be helpful in your daily work, and just give me any comments when you get any idea about this.

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"