<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-C585871E-BE82-49EF-A4B9-4340A7154264" xml:lang="en"><title>Limitations</title><shortdesc/><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>Some APIs of the Standard C Library are not implemented because of the
constraints or limitations of Symbian platform:</p>
<ul>
<li><p><codeph>AF_LOCAL</codeph> sockets only support <codeph>SO_SNDBUF</codeph> and <codeph>SO_RCVBUF</codeph> in <codeph>setsockopt</codeph> and <codeph>SO_TYPE</codeph>, <codeph>SO_SNDBUF</codeph> and <codeph>SO_RCVBUF</codeph> in <codeph>getsockopt</codeph>.
No <codeph>ioctl</codeph> commands are available.</p></li>
<li><p><codeph>AF_LOCAL</codeph> sockets do not support <xref href="GUID-45E5490B-7951-395D-9B88-0A95ACB50C73.dita"><apiname>shutdown()</apiname></xref>.</p></li>
<li><p>The <codeph>stdioserver</codeph> does not support per-process configurations.</p></li>
<li><p>Signals cannot be directed at an individual thread.</p></li>
<li><p><codeph>kill(self)</codeph>/<codeph>sigqueue(self)</codeph>/<codeph>raise()</codeph> is
not synchronous in the current implementation.</p></li>
<li><p>Semantics of signal delivery is different from that of *nix OSes.</p></li>
<li><p>The <codeph>tm_tzname</codeph> in the <codeph>struct tm</codeph> is
not updated by <xref href="GUID-C0143331-6DC4-3FEA-8BD3-5D6C2A24FD73.dita"><apiname>localtime()</apiname></xref> and <xref href="GUID-CAA7C4BC-6C35-3AAE-AD4E-B11C9B58A605.dita"><apiname>mktime()</apiname></xref>.
This is owing to a limitation of localisation resource files in these platforms.
The field will always be set to "UTC".</p></li>
<li><p>On S60 emulators started in <codeph>textshell</codeph> mode, the time
zone offset returns the wrong value. In GUI mode, the offset is set correctly.</p></li>
<li><p>The <codeph>tm_isdst</codeph> field in the struct tm (used in <xref href="GUID-C0143331-6DC4-3FEA-8BD3-5D6C2A24FD73.dita"><apiname>localtime()</apiname></xref> and <xref href="GUID-CAA7C4BC-6C35-3AAE-AD4E-B11C9B58A605.dita"><apiname>mktime()</apiname></xref>)
is not updated properly on the S60 3rd Edition SDK and devices; the field
is simply set to -1.</p></li>
<li><p><xref href="GUID-CAA7C4BC-6C35-3AAE-AD4E-B11C9B58A605.dita"><apiname>mktime()</apiname></xref> and <xref href="GUID-C0143331-6DC4-3FEA-8BD3-5D6C2A24FD73.dita"><apiname>localtime()</apiname></xref> 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.</p></li>
<li><p>In text mode <codeph>stdio</codeph>, <xref href="GUID-10B78898-E3AF-371B-A280-6F33CEDAB864.dita"><apiname>fseek()</apiname></xref> to
the return value of <xref href="GUID-BC4F6F39-1894-329E-8157-871B841E705A.dita"><apiname>ftell()</apiname></xref> does not behave as expected.</p></li>
<li><p>In text-mode, <xref href="GUID-7ECDC892-F515-3DF3-BCBB-00E9C639E537.dita"><apiname>fread()</apiname></xref>, <xref href="GUID-56F38DFC-0A8D-3891-9B5F-86FD2AA6729C.dita"><apiname>fwrite()</apiname></xref> 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></li>
<li><p>P.I.P.S. applications built using the plug-in with this SDK, will not
run on earlier versions of runtimes.</p></li>
<li><p><xref href="GUID-A89FA772-80F2-39E8-AEFB-B9B4E833A1FA.dita"><apiname>stat()</apiname></xref> retrieves the modification time of a directory
incorrectly, if it was set (by <xref href="GUID-234DE8F8-1D41-3BE0-980B-37ACF281DDA6.dita"><apiname>utime()</apiname></xref>) to an odd value.</p></li>
<li><p>Owing to the difference in the Symbian platform model (when compared
to UNIX -like OS), <xref href="GUID-432C9AA0-A698-3A62-95D8-CB010965F92C.dita"><apiname>fork()</apiname></xref> and <xref href="GUID-1F3AB7F6-B354-36DB-AA0C-D8F2DC89A6DD.dita"><apiname>exec()</apiname></xref> functions
are not supported.</p></li>
<li><p>Since <xref href="GUID-432C9AA0-A698-3A62-95D8-CB010965F92C.dita"><apiname>fork()</apiname></xref> and <xref href="GUID-1F3AB7F6-B354-36DB-AA0C-D8F2DC89A6DD.dita"><apiname>exec()</apiname></xref> are not
supported, <xref href="GUID-A9DB6E7C-B8D6-377A-BBE6-39E0A7A09E5D.dita"><apiname>popen()</apiname></xref> 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.</p></li>
<li><p>The following are the limitations with <codeph>waitpid(pid_t waitpid(pid_t
pid, int *stat_loc, int options);</codeph></p><ul>
<li><p>On OpenC there is no process group Ids. So, passing pid as <codeph>0</codeph> and
less than <codeph>-1</codeph> does not work as intended.</p></li>
<li><p>On OpenC, support is provided only for options - <codeph>WNOHANG</codeph>.
Others are not supported.</p></li>
<li><p>The macros which related to job control which work on the <codeph>stat_loc</codeph> do
not work:</p><ul>
<li><p> <codeph>WIFSIGNALED</codeph></p></li>
<li><p><codeph>WTERMSIG</codeph></p></li>
<li><p><codeph>WIFSTOPPED</codeph></p></li>
<li><p><codeph>WSTOPSIG</codeph></p></li>
<li><p><codeph>WIFCONTINUED</codeph>.</p></li>
</ul></li>
<li><p>On Symbian, the following additional macros that work on the <codeph>stat_loc</codeph> are
provided:</p><ul>
<li><p><codeph>WIFTERMINATED</codeph></p></li>
<li><p><codeph>WTERMINATESTATUS</codeph></p></li>
<li><p><codeph>WIFPANICED</codeph></p></li>
<li><p><codeph>WPANICCODE</codeph></p></li>
</ul></li>
</ul></li>
<li><p>For <codeph>int dup2(int oldfd, int newfd);</codeph>, the return value
of <codeph>dup2</codeph> can be different from the one the developer expected
it to be (<codeph>newfd</codeph>). So, the developer of <codeph>dup2</codeph> should
use the return value of <codeph>dup2</codeph> as the new allocated fd rather
than the one passed to <codeph>dup2 (newfd)</codeph>. According to the standard, <codeph>newfd</codeph> and
return values are the same, if <codeph>dup2</codeph> is successful.</p></li>
<li><p>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 <xref href="GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5.dita#GUID-B0E661BC-4058-3256-B9C3-5A4FD52F6DE5/GUID-6C840907-C3F7-34B7-97DB-CEDBA68EA277"><apiname>RThread::Create()</apiname></xref> should create them explicitly.</p></li>
<li><p>In case of Open C, <codeph>libc</codeph> 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.</p></li>
<li><p>In case of an emulator, the developer can configure the window size
dynamically. But the console maintained by Open C <codeph>libc</codeph> will
remain the same. So, if the configuration is changed, data displayed on the
console may not be aligned properly. </p></li>
</ul>
<p>More detailed information about the limitations can be found in the P.I.P.S.
API reference documentation.</p>
</conbody></concept>