<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Inexecutable statements inside switch case</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/22520/inexecutable-statements-inside-switch-case</link><description> 
I have a segment of codes as follows. &amp;#39;app&amp;#39; is a structure
variable. 

 
The code can successfully pass the compiling process and run but
contains some inexecutable important commands, which can&amp;#39;t be
recognized by compiler, e.g.app.bT = TRUE. Besides</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/150221?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 11:54:06 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b40bdd86-6519-4c82-9070-d2af5c4cd839</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;I am sorry I can&amp;#39;t post the whole source codes&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
The fact that it was just an extract wasn&amp;#39;t the issue - the real
issue was that it was unreadable, because you hadn&amp;#39;t followed the
instructions about using the tags...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/113226?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 11:51:44 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:1d6bd022-fa4f-49e9-9d01-2a79a0253928</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;I am a fresh Keiler&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Do understand that this is nothing specifically to do with Keil -
&lt;i&gt;&lt;b&gt;all&lt;/b&gt;&lt;/i&gt; modern compilers perform such optimisations.&lt;/p&gt;

&lt;p&gt;
The difficulty of debugging such highly-optimised code is the
price you pay - as ever, it is a tradeoff, and only you can judge
whether it&amp;#39;s worth it &lt;i&gt;in your particular case&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
The specific optimisations performed by the Keil C51 compilers are
outlined here: &lt;a href="http://www.keil.com/support/man/docs/c51/c51_optimize.htm"&gt;http://www.keil.com/support/man/docs/c51/c51_optimize.htm&lt;/a&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/99693?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 10:07:12 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:612a64a0-2907-4a19-8ee0-23a196649bd4</guid><dc:creator>Chao Hu</dc:creator><description>&lt;p&gt;&lt;p&gt;
Yes, you are right. I am sorry about that because I am a fresh
Keiler at this point. And I just told every one what I saw.&lt;/p&gt;

&lt;p&gt;
Now with your advice I can understand that if you want to trace
the execution step by step and in a normal order, you will have to
reduce the code optimization level. But the results would be the same
no matter which level you choose. Compiler just reorder the execution
to get optimized.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/149787?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 10:01:11 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9cb3f49e-782b-49b6-89bd-1a815ea30e75</guid><dc:creator>Chao Hu</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thank you for reminding me about these issues. I have learned a
lot from what you told me.&lt;/p&gt;

&lt;p&gt;
This time I got the point you have tried to tell me. What I have
traced is the optimized sequence and the result should be the same. I
admit that what you said is right.&lt;/p&gt;

&lt;p&gt;
For proprietary consideration, I am sorry I can&amp;#39;t post the whole
source codes.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/88553?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 09:41:57 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:bf24c1f1-4b89-4747-9761-8a0d4956468d</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;For example (and a completely invented one), the posted code
has the statement &amp;quot;app.bT = TRUE&amp;quot; in many cases; the compiler might
well choose to promote that statement into a more general block where
it is always executed before entering some of the cases.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
To make that concrete, say the original code looked something like
this:&lt;/p&gt;

&lt;pre&gt;
switch( fred )
{
   case 1:  joe = TRUE;  break;
   case 2:  joe = TRUE;  break;
   case 3:  joe = FALSE; break;
   case 4:  joe = TRUE;  break;
   case 5:  joe = TRUE;  break;
   default: joe = TRUE;  break;
}
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
That could clearly be optimised to, in effect:&lt;/p&gt;

&lt;pre&gt;
joe = TRUE;
switch( fred )
{
   case 3:  joe = FALSE; break;
}
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
Where cases 1, 2, 4, and 5 are, apparently, never executed!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/149280?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 09:35:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5efbdbc2-c2c1-4344-a138-b34dafd666ea</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;are no big difference between statments inside those
cases.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Which is exactly the kind of thing that an optimiser will spot,
and then it &lt;i&gt;&lt;b&gt;will&lt;/b&gt;&lt;/i&gt; re-order the code to avoid the
duplication!&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot; I just posted 4 with respect to efficiency&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
But what you posted was totally illegible, wasn&amp;#39;t it?!&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;What I want to tell you is that ... you should not set the
code optimization level very high in order to prevent such
errors.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
That is misleading advice!&lt;/p&gt;

&lt;p&gt;
You could justifiably say, as many have before, &lt;i&gt;&amp;quot;&lt;b&gt;if you want
source-level debuginng&lt;/b&gt;, do not use high optimisation&amp;quot;&lt;/i&gt; - but
to claim that the higher optimisation levels produce faulty code
certainly needs some serious evidence!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/51170?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 09:31:54 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:15c0da04-94ec-4521-b3cf-cd6341b68c2f</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;&lt;p&gt;
Can you demostrate an actual error in the generated code? That is,
post the source, and the generated assembler code, and point out
where the result of executing the code is incorrect?&lt;/p&gt;

&lt;p&gt;
Source level debuggers are often confused by highly optimizing
compilers and may show you what appears to be strange execution as
they hop from statement to statement. That does not mean the code is
not producing the correct result.&lt;/p&gt;

&lt;p&gt;
For example (and a completely invented one), the posted code has
the statement &amp;quot;app.bT = TRUE&amp;quot; in many cases; the compiler might well
choose to promote that statement into a more general block where it
is always executed before entering some of the cases. So, if you put
a breakpoint inside the case, you might not never see app.bT being
set, as that happens before the breakpoint.&lt;/p&gt;

&lt;p&gt;
If you can produce an example of the optimizer breaking things,
then I&amp;#39;m sure Keil would appreciate it if you would email the example
to support.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/149275?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 09:30:05 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a7220a35-a1a7-4dd1-a3cc-0c6418555f13</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;No the source code has never been changed.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Of course not - optimisation does not affect the source code!&lt;br /&gt;
Optimisation is performed on the &lt;i&gt;&lt;b&gt;Object&lt;/b&gt;&lt;/i&gt; code!&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;When I increase the optimization level from 7 to 8, the
problem occured again.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
What problem?&lt;br /&gt;
When you use high-level optimisations like this, you will
&lt;i&gt;&lt;b&gt;never&lt;/b&gt;&lt;/i&gt; be able to simply follow the source lines in
generated machine code - that&amp;#39;s the whole point!&lt;br /&gt;
An optimiser &lt;b&gt;will &lt;i&gt;always&lt;/i&gt;&lt;/b&gt; re-order code, remove
unnecessary code, etc, etc to achieve its goal!&lt;br /&gt;
That&amp;#39;s what optimisers do!&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;I observed is that the execution sequence...&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
The execution sequence is irrelevant, and must be
&lt;i&gt;&lt;b&gt;expected&lt;/b&gt;&lt;/i&gt; to change - see above.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;...result produced were totally different&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
The final result, though, should be identical - aside from
timing.&lt;/p&gt;

&lt;p&gt;
If the final result is really different, then you most certainly
do have a problem!&lt;br /&gt;
In what way is the final result different?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/135149?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 09:25:18 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9399e9f8-21bf-4e3e-b2d5-307a34894921</guid><dc:creator>Chao Hu</dc:creator><description>&lt;p&gt;&lt;p&gt;
There are 8 cases inside the codes, but there are no big
difference between statments inside those cases. So I just posted 4
with respect to efficiency. I am sorry about that.&lt;/p&gt;

&lt;p&gt;
What I want to tell you is that, when the code contains complex
statements with &amp;#39;do while&amp;#39;, &amp;#39;switch&amp;#39; and &amp;#39;if&amp;#39; statements inside, you
should not set the code optimization level very high in order to
prevent such errors.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/135150?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 09:19:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:430b5f5c-04de-42b4-a668-67240e88dbda</guid><dc:creator>Chao Hu</dc:creator><description>&lt;p&gt;&lt;p&gt;
No the source code has never been changed. When I increase the
optimization level from 7 to 8, the problem occured again.&lt;/p&gt;

&lt;p&gt;
I understand what you said about the &amp;#39;volatile&amp;#39; and reordering,
but I can tell you clearly that I have traced the execution of every
statement step by step, and what I observed is that the execution
sequence and result produced were totally different between two
different optimization levels.&lt;/p&gt;

&lt;p&gt;
Thank you for your concerns.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/124112?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 09:08:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8be9e43c-1bed-43b7-b76b-4ea2eff0b676</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;e.g. from case1 to case 5&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
If you want to discuss your code, please re-post it properly - I
can&amp;#39;t even see a case 5 in your original post!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/124114?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 09:07:23 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b5b84bf9-6980-4fc5-ac0f-e54a08a06e25</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
You&amp;#39;ve missed the point!&lt;/p&gt;

&lt;p&gt;
&amp;#39;C&amp;#39; does &lt;i&gt;&lt;b&gt;not&lt;/b&gt;&lt;/i&gt; guarantee that your source lines will
be executed in sequence, step-by-step.&lt;/p&gt;

&lt;p&gt;
eg, think about why the &amp;#39;volatile&amp;#39; keyword exists...&lt;/p&gt;

&lt;p&gt;
So long as the overall effect is the same, the program is
operating correctly!&lt;/p&gt;

&lt;p&gt;
Re-ordering instructions within case statements is a classic
example of optimiser behaviour for &lt;i&gt;&lt;b&gt;any&lt;/b&gt;&lt;/i&gt; compiler;&lt;br /&gt;
Similarly, combining common exit and entry code for functions;&lt;br /&gt;
And deleting superfluous operations...&lt;/p&gt;

&lt;p&gt;
If you just run the program with and without optimisation, and
without trying to trace through it, can you actually tell the
difference? If not, then there is no problem.&lt;br /&gt;
If you can tell the difference, that is far more likely to be a flaw
in your source than fault in the compiler!&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/113235?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 08:47:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:26043ac6-7240-4032-80fd-6989285af903</guid><dc:creator>Chao Hu</dc:creator><description>&lt;p&gt;&lt;p&gt;
I am sorry but I can&amp;#39;t agree with you. I have run the program many
times when the compiling was high optimized. Every time I ran and
traced the execution of every statement inside the switch, some
statements, e.g. app_bT=TRUE, could not be recognized as an
executable while they should have been, besides there were disordered
jumps between cases, e.g. from case1 to case 5, which I believe is
absolutely wrong.&lt;/p&gt;

&lt;p&gt;
What Christoph Franck told me is right. It is the problem with
compiling optimization. When I reduce the optimization level by one,
all the statements can be recognized and transformed into executable
machine codes and ran normally.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/99687?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 08:12:54 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e93fc407-a913-437c-9f64-6c350039179c</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;which may have a large potential to cause many
problems&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
What actual problems have you seen?&lt;/p&gt;

&lt;p&gt;
What you have described is perfectly normal behaviour for
&lt;i&gt;&lt;b&gt;any&lt;/b&gt;&lt;/i&gt; optimised code - whether machine-optimised, or
hand-crafted by a skilled assembler programmer.&lt;/p&gt;

&lt;p&gt;
The &amp;quot;problems&amp;quot; you describe are merely &lt;i&gt;(sic)&lt;/i&gt; in debugging -
they should not affect the overall operation of the code...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/75531?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 08:02:53 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:0d6facfd-2094-4cad-924d-b818f422485c</guid><dc:creator>Chao Hu</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thank you so much!!!!&lt;/p&gt;

&lt;p&gt;
I followed your advice to reduce the optimazation level from 8 to
7 and the problem has been solved. But I can&amp;#39;t believe why the
default optimazation level is set 8, which may have a large potential
to cause many problems.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/84583?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 07:41:51 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f29d7d60-edfc-4354-887d-bc65456f4238</guid><dc:creator>t m</dc:creator><description>&lt;p&gt;&lt;p&gt;
Post a minimal version of your code that fails so we can look.&lt;/p&gt;

&lt;p&gt;
Please remember the &amp;#39;pre&amp;#39; tags.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/75532?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 07:40:26 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:dd1fec24-729f-467e-9ee1-3e54f4ff1ca1</guid><dc:creator>Chao Hu</dc:creator><description>&lt;p&gt;&lt;p&gt;
I am sorry about that. I shortened the statements before I posted
them out. There are totally 8 cases, ranging from case 0 to case 8.
Inside the case, there are just some &amp;quot;if&amp;quot; statements just as I
posted.&lt;/p&gt;

&lt;p&gt;
I have tried the optimazation setting but it doesn&amp;#39;t work at all.
Also I have transplanted the entire &amp;quot;do switch&amp;quot; statements out to a
single C file and compile it, but the same problem occured. So I am
totally confused.&lt;/p&gt;

&lt;p&gt;
Thank you for your help.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/88555?ContentTypeID=1</link><pubDate>Mon, 24 Sep 2007 00:02:58 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:86aa6f02-43dd-4e2c-8c79-118d5e88617a</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;Why not use the &amp;#39;pre&amp;#39; tagging?&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
As clearly described in the instructions: &lt;a href="http://www.danlhenry.com/caps/keil_code.png"&gt;www.danlhenry.com/.../keil_code.png&lt;/a&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/51171?ContentTypeID=1</link><pubDate>Sun, 23 Sep 2007 23:52:28 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:22ed58ef-4058-4c83-b208-91feb0ebc71e</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Besides, there are some disordered jump inside the switch, e.g.
jumping from case 1 to case 5 without executing &amp;quot;break&amp;quot; in case
1.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
This is most likely due to using a high optimization level when
compiling. Turn off compiler optimizations and then check again.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Inexecutable statements inside switch case</title><link>https://community.arm.com/thread/48646?ContentTypeID=1</link><pubDate>Sun, 23 Sep 2007 23:32:09 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:17d7fec7-90e9-4754-8abe-f8ffc34406d8</guid><dc:creator>t m</dc:creator><description>&lt;p&gt;&lt;p&gt;
Code is &lt;b&gt;VERY&lt;/b&gt; difficult to read !&lt;/p&gt;

&lt;p&gt;
Why not use the &amp;#39;pre&amp;#39; tagging?&lt;/p&gt;

&lt;p&gt;
Where is case 5 that you speak of?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>