Use of constants on EFA

Use of constants on EFA

[Kevin Wilson]

For Eurofighter software we must conform to the following coding
standards :

EF Software Programmer's Manual PL-J-019-V-1101 Issue 4 April 1992
which contains a section saying :

5.4.2.1 Constants
Objects shall be defined as being constant if their value is fixed
throughout the execution of the software.

As would be expected we have taken this to mean that if a variable is fixed
within its scope (whatever this may be) then it should be a constant.

So for example

    declare
      Status : constant Status_Type := Get_Status ;
    begin
      if Status = Good
      then
        Do_This ;
      else
        Do_That ;
      end if ;
    end ;

would be OK.

However our customer (who must accept our code) states that constants
should only be declared at package level. They argue that in the
above example the constant will change its value if the code is executed
again, therefore is not fixed !

Apart from the question of good programming practice, we rely heavily
on declaring local constants to read unconstrained array structures
returned by functions and without this would require untidy interfaces
and I would imagine more memory.

Any comments on this would be appreciated or if there are any people
reading this who were involved in the writing of this document and can
clarify what was meant by this statement please let me know.

K.Wilson

Re: Use of constants on EFA

[Robert Dewar]

More on that rule, you quoted the rule as

<<Objects shall be defined as being constant if their value is fixed
throughout the execution of the software.>>

This is definitely stated positively, as a rule for when constant must
be used. It is impossible to derive from the above rule any requirement,
or even implication that "objects shall NOT be defined as being constant
if their value is NOT fixed throughout the execution of the software", to
deduce this from the above statement is simply faulty logic.

You are applying a rule about how to use constant within a scope that
is not derivable from the above rule, but is a reasonable extension of
it.

Actually, how about the following argument that your code does indeed
conform to the rule, and that the rule forces the use of constant in the
cases where you want it.

If you have block:

	declare
	   x : constant String := xxx
        begin
	   ...
        end;

then your customer complains that the value of the object x changes
from one execution of this block to another.

That is wrong, as soon as you leave the block the object x disappears.
When you reenter, a completely new object x is created that has nothing
whatsoever to do with the previous one. 

So multiple executions of this block correspond to multiple objects,
and each of these objects has the quality that its value is fixed from
the point of its creation to the point of its destruction, which is
a reasonable working definition of what is meant by throughout the
execution of the software.

After all consider the global case

  package x is
	y: integer;
        z : constant integer := 3;
	...
  end x;

Is it the case that z has the value from the beginning to the end of the
execution of the program? Certainly not. The object z does not exist until
its declaration is elaborated, i.e. at the point where you elaborate the
declaration of y (or any other packages that are elaborated before package
x), the object z does not exist, and certainly does not contain the value 3.

So in the global case, it is clear that the lifetime that is relevant is
the lifetime of the variable, not the lifetime of the program, and the same
principle applies in identical manner to the multiple objects created by
multiple invocations of a declare block.

Good luck in your fight to prevail here, you are definitely on the right
side of this issue!

Robert Dewar
Ada Core Technologies.

Re: Use of constants on EFA

[Robert Dewar]

<<EF Software Programmer's Manual PL-J-019-V-1101 Issue 4 April 1992
which contains a section saying :

5.4.2.1 Constants
Objects shall be defined as being constant if their value is fixed
throughout the execution of the software.
>>

This is a very poor software design principle. Your coding practices
are the appropriate ones. But as often happens, when someone puts a 
rule into a formal book, even if it is completely misguided as in
this case, it tends to be taken by someone not in a position to
evaluate the value of the rule as gospel.

Note that at least in Ada 95, you do not have to declare constants
to deal with the unconstrained cased, but of course it is still better
practice to use the keyword constant wherever possible.

Undoubtedly the rule was written by someone who did not appreciate the
importance of the use of constant declarations in the manner in which
you suggest. Probably the rule was intended to force the use of constant
in appropriate situations, and it would be a surprise to the author of
the rule to find it being used to *prevent* use of constant in
appropriate situations.

The proper rule for the use of constant in Ada is roughly, use constant
on every object declaration, unless there is some reason that you cannot
do so (i.e. there is some explicit or implicit assignment to the object).

I find that most Ada programmers greatly underuse constant, partly because
the syntax is a little heavy (*). It is most certainly sad to see a style
guide insist on this poor practice. Keep up the fight to have this rule
interpreted in a sensible manner. Particularly so, since, as you note, in
Ada 83, the consequence of not being able to use a constant in the
unconstrained case is extremely painful (indeed in Ada 83, the rule is,
again probably unintentially, removing a critical piece of functionality
from the code.

It is a pity when people replace properly done quality assessment with
simple comparisons to style books, but it happens all the time.

Robert B.K. Dewar
Ada Core Technologies

(*) P.S. in Algol-68, the syntax for a constant is very light:

variable    int a;
constant    int a = 3;

and so the use of constants is much more prevalent in A68 programs (the
syntax for an initilaized variable is  int a := 3;

P.P.S. One very bad consequence of not using constant in the manner you
suggest is that it greatly increases the maintenance burdens. If you follow
this style guideline and write

   procedure x is
	y : integer := ...

instead of

   procedure x is
        y : constant integer := ...

you force the reader/maintainer to either search the entire procedure to
look for an expected assignment to y (and to be irritated when none is
found), or to read the code constantly worrying that y might be changing.

Dynamic constants are an extremely important feature of a language like
Ada. Forbidding them is seriously misguided.

I do think you should try to dig into the origins of this rule. I am almost
certain that the motiviation is to discourage people from failing to use
constant on global values that do not change, in otherwords that an expected
violation of this rule involves the failure to use the constant keyword.

Re: Use of constants on EFA

[Peter Hermann]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
> Good luck in your fight to prevail here, you are definitely on the right
> side of this issue!

agreed

And here is the true reason of my spontaneous posting:

I am simply grateful for a lot of excellent contributions lately
by Robert Dewar and many others who are spending a lot of their time
for many of us: precious and pleasant. Thank you.

--
Peter Hermann  Tel:+49-711-685-3611 Fax:3758 ph@csv.ica.uni-stuttgart.de
Pfaffenwaldring 27, 70569 Stuttgart Uni Computeranwendungen
Team Ada: "C'mon people let the world begin" (Paul McCartney)

Re: Use of constants on EFA

[Matthew Heaney]

In article <63qkmc$8va$1@uttwil.bodensee.com>, "Kevin Wilson"
<Kevin.Wilson@konstanz.netsurf.de> wrote:

>However our customer (who must accept our code) states that constants
>should only be declared at package level. They argue that in the
>above example the constant will change its value if the code is executed
>again, therefore is not fixed !

Perhaps this is a case of ambiguous requirements.  Change the word "fixed"
to the words "read-only," and maybe that'll make them happy.

>Apart from the question of good programming practice, we rely heavily
>on declaring local constants to read unconstrained array structures
>returned by functions and without this would require untidy interfaces
>and I would imagine more memory.

The frequent use of declare blocks and localization of objects _is_ good
programming practice, and you are doing the right thing.

However, there is a certain tension between localization of an object and
nesting - it often happens that you start getting nesting 3 or 4 levels
deep, which can be bad for because this confuses programmers.  So this
means that objects will be localized, but not necessarily constant.

>Any comments on this would be appreciated or if there are any people
>reading this who were involved in the writing of this document and can
>clarify what was meant by this statement please let me know.

Tell your customer to stop micro-managing.  If he's paying you to write
software, then he has get out of your way, and let you do your job.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Use of constants on EFA

[Tom Moran]

>5.4.2.1 Constants
>Objects shall be defined as being constant if their value is fixed
>throughout the execution of the software.
  "If (fixed) then (constant)" does not imply "If not(fixed) then
not(constant)" as any book on logic will tell any reader of that rule.
Perhaps some non-programmer doesn't know the difference between "if"
and "only if"?

Re: Use of constants on EFA

[Michael F Brenner]

That is very interesting, to classify the programming standards. Why
did you decide to do that? How can those standards be reviewed and
commented on by independent authority? How can you program economically
without public light? This is the first time I have seen a methodology
for coding given a security classification. Again, very interesting.

Re: Use of constants on EFA

[Karel Th�nissen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]


Laura & Mike Palmer wrote:
> 
> Kevin Wilson <Kevin.Wilson@konstanz.netsurf.de> wrote in article
> <63qkmc$8va$1@uttwil.bodensee.com>...
> > For Eurofighter software we must conform to the following coding
> > standards :
> >
> > EF Software Programmer's Manual PL-J-019-V-1101 Issue 4 April 1992
> >
> Please note that the EF Programmers Manual has both a copyright and a NATO
> security classification associated with it and as such its subject matter
> should not be discussed within this forum.

Sorry, I do not intend to offend you, but by what I understood, and as a
civilian protected in the future (lets hope that) by the Eurofighter, I
am glad that the original poster *did* ask.

Having been in the army for a while, I know that there is tendency to
classify even the name of the minister of defence and the daily menu. 

> If there are any areas that require clarification, then the process is to
> contact myself, as I am the EF Software Manager and act as the 'custodian'
> of all the software standards for the Eurofighter project.

I guess this information is more useful for a potential enemy than that
in  any previous posting.

> If anyone who actually works on the Eurofighter project wishes to contact
> me, I will reply to messages posted to:
> 
>      Michael.Palmer@BAe.co.uk

-- 
Groeten, Karel Th�nissen

-- mijn e-adres is versleuteld om junk-mailers op het net te verwarren
-- verwijder confusion om zo mijn echte adres te verkrijgen

-- my e-mail address is scrambled to confuse spammers
-- remove the confusion to obtain my true address

Re: Use of constants on EFA

[Dale Stanbrough]

"Please note that the EF Programmers Manual has both a copyright and a
NATO
 security classification associated with it and as such its subject matter
 should not be discussed within this forum."


Yes, I can well imagine the Iraqi's taking advantage of the fact that
variables that don't vary haven't been labelled constants.


Dale

Re: Use of constants on EFA

[Richard Toy]

Just out of interest...

What is your response to the arguments put forward by Dewar et al?

Do you agree with the programer or customers interpretation of the
requirement?

-- 
Regards

Richard Toy

rtoy@dera.gov.uk

Re: Use of constants on EFA

[KevinWilson]

All the comments regarding my original posting are greatly appreciated
but please drop the subject of classification !! Although in this case I
believe the information I provided to be trivial, I perhaps gave details
that were not really relevant to the subject and should not have been
posted to a newsgroup.

Kevin Wilson

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet