|
Gem #32: Safe and Secure Software : Chapter 1, Safe Syntax
Author: John Barnes
Abstract: This week’s gem is the first chapter of John Barnes’ new booklet:
Safe and Secure Software: An Introduction to Ada 2005.
Over the coming months, we will be publishing all thirteen chapters of the booklet. In the attachment at the bottom of Gem #30 you can access the contents and bibliography for the entire booklet. We hope you will enjoy the read!
Let’s get started…
Syntax is often considered to be a rather boring mechanical detail. The argument being that it is what you say that matters but not so much how it is said. That of course is not true. Being clear and unambiguous are important aids to any communication in a civilized world.
Similarly, a computer program is a communication between the writer and the reader, whether the reader be that awkward thing: the compiler, another team member, a reviewer or other human soul. Indeed, most communication regarding a program is between two people. Clear and unambiguous syntax is a great help in aiding communication and, as we shall see, avoids a number of common errors.
An important aspect of good syntax design is that it is a worthwhile goal to try to ensure that typical simple typing errors cause the program to become illegal and thus fail to compile, rather than having an unintended meaning. Of course it is hard to prevent the accidental typing of X rather than Y or + rather than * but many structural risks can be prevented. Note incidentally that it is best to avoid short identifiers for just this reason. If we have a financial program about rates and times then using identifiers R and T is risky since we could easily type the wrong identifier by mistake (the letters are next to each other on the keyboard). But if the identifiers are Rate and Time then inadvertently typing Tate or Rime will be caught by the compiler. This applies to any language of course.
Read Chapter 1 in full
Note: All chapters of this booklet will, in time, be available on the Ada 2005 home page.
 608.2Kb |
Posted
in Development Log, Ada / Ada 2005, Devt log - Gem of the Week
Have your own idea for a Gem?
If you have an idea for a Gem you would like to contribute please feel free to contact us at: gems@adacore.com
MichaelP said:
Minor typo on page 6:
float index(float height, weight) {
should be:
float index(float height, float weight) {
Qunying said:
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.
Alan Barnes said:
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< =10; i++)
when one intends
for(int i=0; i<10; i++)
or vice-versa
For example
int a[10];
for(int i=0; i<=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'Range LOOP
A(I) := 0;
END LOOP;
b) Wrap-around in, for example in Java
for(byte i=0; i<128; i++) {
do_something()
}
3) The dangling else
For example in Java
if (x >= 0)
if (x > 0)
System.out.println(”Positive”);
else
System.out.println(”Negative”);
Alan Barnes said:
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 > 0)
System.out.println(”Positive”);
else
System.out.println(”Negative”);
renoX said:
I find the “analysis” of = vs := misleading, the reason why = in C can leads to error if used in the test part of an ‘if’ instruction isn’t so much because of its name but because = in C returns a value whereas := in Ada doesn’t.
If = in C didn’t return a value, the error couldn’t happen..
As for the ’superiority’ of reading Y:=X instead of Y=X, let’s just say that this is highly debatable and I’ve never, ever been confused about it..
The other examples are correct though (except the structure assignment as was already remarked).
Alan Barnes said:
Regarding renoX’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)