<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Gem #32: Safe and Secure Software : Chapter 1, Safe Syntax</title>
	<atom:link href="http://www.adacore.com/2008/04/21/gem-32/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.adacore.com/2008/04/21/gem-32/</link>
	<description>AdaCore technology and news</description>
	<lastBuildDate>Mon, 06 Feb 2012 18:59:19 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Alan Barnes</title>
		<link>http://www.adacore.com/2008/04/21/gem-32/comment-page-1/#comment-1421</link>
		<dc:creator>Alan Barnes</dc:creator>
		<pubDate>Thu, 01 May 2008 08:57:00 +0000</pubDate>
		<guid isPermaLink="false">http://www2.adacore.com/2008/04/21/gem-32/#comment-1421</guid>
		<description>Regarding renoX&#039;s comment:

The fact that = in the C-family of languages returns a value is just one instance of the lack of clear separation between 
expressions (which should return a value but not affect program state) and commands (which alter program state but do not have a value).  

Other instances are the possibility of ignoring function return values, i.e. using a function call as a complete program step and the ++ and -- operators (both prefix and postfix!) which are useful abbreviations if used solely as commands but lead to many obscurities if used in expressions.

In Ada the separation is much clearer although not complete as function calls can directly affect program state by altering non-local variables and/or by performing I/O (and also through the use of access parameters)</description>
		<content:encoded><![CDATA[<p>Regarding renoX&#8217;s comment:</p>
<p>The fact that = in the C-family of languages returns a value is just one instance of the lack of clear separation between<br />
expressions (which should return a value but not affect program state) and commands (which alter program state but do not have a value).  </p>
<p>Other instances are the possibility of ignoring function return values, i.e. using a function call as a complete program step and the ++ and &#8212; operators (both prefix and postfix!) which are useful abbreviations if used solely as commands but lead to many obscurities if used in expressions.</p>
<p>In Ada the separation is much clearer although not complete as function calls can directly affect program state by altering non-local variables and/or by performing I/O (and also through the use of access parameters)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: renoX</title>
		<link>http://www.adacore.com/2008/04/21/gem-32/comment-page-1/#comment-1405</link>
		<dc:creator>renoX</dc:creator>
		<pubDate>Fri, 25 Apr 2008 12:34:18 +0000</pubDate>
		<guid isPermaLink="false">http://www2.adacore.com/2008/04/21/gem-32/#comment-1405</guid>
		<description>I find the &quot;analysis&quot; of = vs := misleading, the reason why = in C can leads to error if used in the test part of an &#039;if&#039; instruction isn&#039;t so much because of its name but because = in C returns a value  whereas := in Ada doesn&#039;t.
If = in C didn&#039;t return a value, the error couldn&#039;t happen..

As for the &#039;superiority&#039; of reading Y:=X instead of Y=X, let&#039;s just say that this is highly debatable and I&#039;ve never, ever been confused about it..

The other examples are correct though (except the structure assignment as was already remarked).</description>
		<content:encoded><![CDATA[<p>I find the &#8220;analysis&#8221; of = vs := misleading, the reason why = in C can leads to error if used in the test part of an &#8216;if&#8217; instruction isn&#8217;t so much because of its name but because = in C returns a value  whereas := in Ada doesn&#8217;t.<br />
If = in C didn&#8217;t return a value, the error couldn&#8217;t happen..</p>
<p>As for the &#8217;superiority&#8217; of reading Y:=X instead of Y=X, let&#8217;s just say that this is highly debatable and I&#8217;ve never, ever been confused about it..</p>
<p>The other examples are correct though (except the structure assignment as was already remarked).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alan Barnes</title>
		<link>http://www.adacore.com/2008/04/21/gem-32/comment-page-1/#comment-1401</link>
		<dc:creator>Alan Barnes</dc:creator>
		<pubDate>Thu, 24 Apr 2008 11:28:20 +0000</pubDate>
		<guid isPermaLink="false">http://www2.adacore.com/2008/04/21/gem-32/#comment-1401</guid>
		<description>My previous reply seems to have been mangled somewhere along the line. I meant to say

2) Problems with for loops

a) One more/one fewer repetition than intended, e.g. writing

for (int i=0; i= 0)
   if (x &gt; 0)
    System.out.println(&quot;Positive&quot;);
else
   System.out.println(&quot;Negative&quot;);</description>
		<content:encoded><![CDATA[<p>My previous reply seems to have been mangled somewhere along the line. I meant to say</p>
<p>2) Problems with for loops</p>
<p>a) One more/one fewer repetition than intended, e.g. writing</p>
<p>for (int i=0; i= 0)<br />
   if (x &gt; 0)<br />
    System.out.println(&#8220;Positive&#8221;);<br />
else<br />
   System.out.println(&#8220;Negative&#8221;);</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alan Barnes</title>
		<link>http://www.adacore.com/2008/04/21/gem-32/comment-page-1/#comment-1400</link>
		<dc:creator>Alan Barnes</dc:creator>
		<pubDate>Thu, 24 Apr 2008 11:20:30 +0000</pubDate>
		<guid isPermaLink="false">http://www2.adacore.com/2008/04/21/gem-32/#comment-1400</guid>
		<description>There are of course other examples of unsafe syntax in the C family of languages:

1) The fall-through in switch statements if break is omitted.

2) Problems with for loops

a)  One more/one fewer repetition than intended, e.g. writing
   for(int i=0; i&lt;=10; i++)
  
when one intends

   for(int i=0; i&lt;10; i++)

or vice-versa
 
For example
   int a[10];
   for(int i=0; i&lt;=10; i++)
     a[i] =0;
   
This type of error is much less likely if one uses an explicit range
  
FOR I IN 0 .. 9 LOOP
  A(I) := 0;
END LOOP;

or better

FOR I IN A&#039;Range LOOP
  A(I) := 0;
END LOOP;


b) Wrap-around in, for example in Java

 for(byte i=0; i&lt;128; i++) {
    do_something()
 }

3) The dangling else
   For example in Java
if (x &gt;= 0)
  if (x &gt; 0)
     System.out.println(&quot;Positive&quot;);
else
     System.out.println(&quot;Negative&quot;);
</description>
		<content:encoded><![CDATA[<p>There are of course other examples of unsafe syntax in the C family of languages:</p>
<p>1) The fall-through in switch statements if break is omitted.</p>
<p>2) Problems with for loops</p>
<p>a)  One more/one fewer repetition than intended, e.g. writing<br />
   for(int i=0; i< =10; i++)</p>
<p>when one intends</p>
<p>   for(int i=0; i&lt;10; i++)</p>
<p>or vice-versa</p>
<p>For example<br />
   int a[10];<br />
   for(int i=0; i<=10; i++)<br />
     a[i] =0;</p>
<p>This type of error is much less likely if one uses an explicit range</p>
<p>FOR I IN 0 .. 9 LOOP<br />
  A(I) := 0;<br />
END LOOP;</p>
<p>or better</p>
<p>FOR I IN A'Range LOOP<br />
  A(I) := 0;<br />
END LOOP;</p>
<p>b) Wrap-around in, for example in Java</p>
<p> for(byte i=0; i&lt;128; i++) {<br />
    do_something()<br />
 }</p>
<p>3) The dangling else<br />
   For example in Java<br />
if (x >= 0)<br />
  if (x > 0)<br />
     System.out.println(&#8220;Positive&#8221;);<br />
else<br />
     System.out.println(&#8220;Negative&#8221;);</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Qunying</title>
		<link>http://www.adacore.com/2008/04/21/gem-32/comment-page-1/#comment-1387</link>
		<dc:creator>Qunying</dc:creator>
		<pubDate>Mon, 21 Apr 2008 17:59:29 +0000</pubDate>
		<guid isPermaLink="false">http://www2.adacore.com/2008/04/21/gem-32/#comment-1387</guid>
		<description>In page 5,

struct date today = (1, 12, 8);
It is not a legal C construct, it should be:
struct date today = {1, 12, 8};

And in C99, there is designated initializer.

struct date today = {
 .day = 1,
 .month = 12,
 .year = 8
};

So it is not an advantage over C any more on this particular example.</description>
		<content:encoded><![CDATA[<p>In page 5,</p>
<p>struct date today = (1, 12, 8);<br />
It is not a legal C construct, it should be:<br />
struct date today = {1, 12, 8};</p>
<p>And in C99, there is designated initializer.</p>
<p>struct date today = {<br />
 .day = 1,<br />
 .month = 12,<br />
 .year = 8<br />
};</p>
<p>So it is not an advantage over C any more on this particular example.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MichaelP</title>
		<link>http://www.adacore.com/2008/04/21/gem-32/comment-page-1/#comment-1385</link>
		<dc:creator>MichaelP</dc:creator>
		<pubDate>Mon, 21 Apr 2008 12:46:17 +0000</pubDate>
		<guid isPermaLink="false">http://www2.adacore.com/2008/04/21/gem-32/#comment-1385</guid>
		<description>Minor typo on page 6:

float index(float height, weight) {

should be:

float index(float height, float weight) {</description>
		<content:encoded><![CDATA[<p>Minor typo on page 6:</p>
<p>float index(float height, weight) {</p>
<p>should be:</p>
<p>float index(float height, float weight) {</p>
]]></content:encoded>
	</item>
</channel>
</rss>

