--- a/Symbian3/PDK/Source/GUID-7A71CD0B-84C7-5A77-B573-C61F67C382DA.dita Thu Mar 11 15:24:26 2010 +0000
+++ b/Symbian3/PDK/Source/GUID-7A71CD0B-84C7-5A77-B573-C61F67C382DA.dita Thu Mar 11 18:02:22 2010 +0000
@@ -1,39 +1,39 @@
-<?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-7A71CD0B-84C7-5A77-B573-C61F67C382DA" xml:lang="en"><title>Summary
-of cleanup rules</title><shortdesc>This document states general rules for cleanup.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>The general rules for cleanup during the lifetime of an object are:</p>
-<ul>
-<li id="GUID-AEE55F10-3FD5-5B09-B025-C5499DE7B312"><p>between the moment the
-object is allocated, and the moment that a pointer to that object is stored
-in a structure which would be accessible if a leave occurred, the object must
-be pushed to the clean-up stack if a leave could possibly occur</p> </li>
-<li id="GUID-B69DDE00-FE4C-582F-B5FA-0FA7684591F6"><p>when a pointer to the
-object has been stored in an object which would be accessible if a leave occurred,
-then the object should be popped from the cleanup stack before a leave could
-possibly occur: normally, the object is popped first, and then the pointer
-is stored</p> </li>
-<li id="GUID-D8D6B31E-0B9F-56C6-B9B0-2197549E78FC"><p>an object is accessible
-if a leave occurs, if either it is pushed to the cleanup stack, or there is
-a reference to it from another object which would be accessible if a leave
-occurred, or there is a reference to it from a stack frame which would not
-be affected when a leave occurs (because of an appropriately-placed <codeph>TRAP</codeph>),
-or there is a reference to it from a global variable</p> </li>
-<li id="GUID-4F508BDB-59D1-52EA-84C2-CABE3E9339EC"><p>it should never be possible
-to clean up an object more than once, if a leave occurred</p> </li>
-</ul>
-<p>In practice, this means that an object must be referred to either by a
-cleanup stack frame, or by a reference from another object. More rarely, the
-object may be referred to by a stack frame which cannot be unwound during
-the lifetime of that object, because of an appropriate <codeph>TRAP</codeph>.
-More rarely still, the object may be referred to by a global variable.</p>
+<?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-7A71CD0B-84C7-5A77-B573-C61F67C382DA" xml:lang="en"><title>Summary
+of cleanup rules</title><shortdesc>This document states general rules for cleanup.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>The general rules for cleanup during the lifetime of an object are:</p>
+<ul>
+<li id="GUID-AEE55F10-3FD5-5B09-B025-C5499DE7B312"><p>between the moment the
+object is allocated, and the moment that a pointer to that object is stored
+in a structure which would be accessible if a leave occurred, the object must
+be pushed to the clean-up stack if a leave could possibly occur</p> </li>
+<li id="GUID-B69DDE00-FE4C-582F-B5FA-0FA7684591F6"><p>when a pointer to the
+object has been stored in an object which would be accessible if a leave occurred,
+then the object should be popped from the cleanup stack before a leave could
+possibly occur: normally, the object is popped first, and then the pointer
+is stored</p> </li>
+<li id="GUID-D8D6B31E-0B9F-56C6-B9B0-2197549E78FC"><p>an object is accessible
+if a leave occurs, if either it is pushed to the cleanup stack, or there is
+a reference to it from another object which would be accessible if a leave
+occurred, or there is a reference to it from a stack frame which would not
+be affected when a leave occurs (because of an appropriately-placed <codeph>TRAP</codeph>),
+or there is a reference to it from a global variable</p> </li>
+<li id="GUID-4F508BDB-59D1-52EA-84C2-CABE3E9339EC"><p>it should never be possible
+to clean up an object more than once, if a leave occurred</p> </li>
+</ul>
+<p>In practice, this means that an object must be referred to either by a
+cleanup stack frame, or by a reference from another object. More rarely, the
+object may be referred to by a stack frame which cannot be unwound during
+the lifetime of that object, because of an appropriate <codeph>TRAP</codeph>.
+More rarely still, the object may be referred to by a global variable.</p>
</conbody></concept>
\ No newline at end of file