Some APIs of the Standard C Library are not implemented because of the constraints or limitations of Symbian platform:
AF_LOCAL sockets only support SO_SNDBUF and SO_RCVBUF in setsockopt and SO_TYPE, SO_SNDBUF and SO_RCVBUF in getsockopt.
No ioctl commands are available.
AF_LOCAL sockets do not support shutdown().
The stdioserver does not support per-process configurations.
Signals cannot be directed at an individual thread.
kill(self)/sigqueue(self)/raise() is
not synchronous in the current implementation.
Semantics of signal delivery is different from that of *nix OSes.
The tm_tzname in the struct tm is
not updated by localtime() and mktime().
This is owing to a limitation of localisation resource files in these platforms.
The field will always be set to "UTC".
On S60 emulators started in textshell mode, the time
zone offset returns the wrong value. In GUI mode, the offset is set correctly.
The tm_isdst field in the struct tm (used in localtime() and mktime())
is not updated properly on the S60 3rd Edition SDK and devices; the field
is simply set to -1.
mktime() and localtime() APIs are about 3 times slower on the S60 3rd Edition SDK and devices, because of lack of native support for more efficient code that is used for S60 3rd Edition, Feature Pack 1 and later SDKs.
In text mode stdio, fseek() to
the return value of ftell() does not behave as expected.
In text-mode, fread(), fwrite() and their siblings will take approximately twice the time compared to binary mode. This is because of extra code required to perform newline-translations in text-mode.
P.I.P.S. applications built using the plug-in with this SDK, will not run on earlier versions of runtimes.
stat() retrieves the modification time of a directory incorrectly, if it was set (by utime()) to an odd value.
Owing to the difference in the Symbian platform model (when compared to UNIX -like OS), fork() and exec() functions are not supported.
Since fork() and exec() are not supported, popen() is not complete. It will create a child process and open a pipe between a parent and a child process either in read or write mode. It does not copy the address space to a child.
The following are the limitations with waitpid(pid_t waitpid(pid_t
pid, int *stat_loc, int options);
On OpenC there is no process group Ids. So, passing pid as 0 and
less than -1 does not work as intended.
On OpenC, support is provided only for options - WNOHANG.
Others are not supported.
The macros which related to job control which work on the stat_loc do
not work:
WIFSIGNALED
WTERMSIG
WIFSTOPPED
WSTOPSIG
WIFCONTINUED.
On Symbian, the following additional macros that work on the stat_loc are
provided:
WIFTERMINATED
WTERMINATESTATUS
WIFPANICED
WPANICCODE
For int dup2(int oldfd, int newfd);, the return value
of dup2 can be different from the one the developer expected
it to be (newfd). So, the developer of dup2 should
use the return value of dup2 as the new allocated fd rather
than the one passed to dup2 (newfd). According to the standard, newfd and
return values are the same, if dup2 is successful.
Some of the APIs of Open C assume that a cleanup stack is created and
there is a top-level TRAP for the current thread. All the threads created
using RThread::Create() should create them explicitly.
In case of Open C, libc will have its own console
object maintained and all threads console I/O will be routed to the console.
In case of a hybrid application, if the application creates one more console,
then switching between these consoles will be a problem. The user may not
be aware of this problem.
In case of an emulator, the developer can configure the window size
dynamically. But the console maintained by Open C libc will
remain the same. So, if the configuration is changed, data displayed on the
console may not be aligned properly.
More detailed information about the limitations can be found in the P.I.P.S. API reference documentation.