!standard  6.3.2(3)                                   01-10-16  AC95-00016/01
!class uninteresting 01-10-16
!status received 01-10-10
!subject pragma Read_Only

!summary

!appendix

From: V. Santhanam (Boeing)
Sent: Wednesday, October 10, 2001 9:12 AM

Issue:

In Ada, it is awkward to create a variable in a package for read/write use
internally but read-only use by clients. To achieve this, one would have to
declare the variable either in the private part of the package spec or in
the body, and provide a visible function to read the variable.

Solution:

Provide a Read_Only pragma which can be applied to variables in the visible
part of a package so that they are treated as constants by the clients of
the package. Example:

	Error_Count : Natural := 0;
	pragma Read_Only (Error_Count);

The read-only restriction is not applicable the declaring package itself.

Reasoning:

The reader function approach incurs a significant run-time penalty. I know
of at least one program in which a decision was made to declare all such
variables in the visible part of the package, exposing them to potential
modifications by clients, in order to avoid the function call penalty.
Inlining the function call was not an option for certification reasons. The
proposed solution will avoid the run-time penalty without sacrificing
safety.

****************************************************************

From: Randy Brukardt
Sent: Tuesday, October 16, 2001  7:12 PM

> The reader function approach incurs a significant run-time penalty.

It shouldn't have any runtime penalty, if combined with a pragma Inline. Why
doesn't that solve your problem without introducing any new language features?
(If your vendor doesn't Inline these properly, either pressure or change the
vendor! This is the sort of thing that Inline was designed to handle).

****************************************************************

From: Craig Carey
Sent: Thursday, October 18, 2001  7:23 PM

At 2001.October.10 09:12 -0500 Wednesday, Santhanam, Vdot wrote:
 >Issue:
 >
 >In Ada, it is awkward to create a variable in a package for read/write use
 >internally but read-only use by clients. To achieve this, one would have to
 >declare the variable either in the private part of the package spec or in
 >the body, and provide a visible function to read the variable.
 >
 >Solution:
 >
 >Provide a Read_Only pragma which can be applied to variables in the visible

What about "exported constant" (etc.) ?, or "pragma Export_As_Constant(...)" ?.
'Read_Only' sounds like a description that can make the variable be constant,
even inside of the body of the package.

 >part of a package so that they are treated as constants by the clients of
 >the package. Example:
 >
 >       Error_Count : Natural := 0;
 >       pragma Read_Only (Error_Count);
 >
 >The read-only restriction is not applicable the declaring package itself.
 >

In GNAT there is this error message:

     "error: access-to-variable designates constant";

when the 'Access attribute is applied to a constant. Pointers to constants
can't be assigned and the language does not dynamically keep track of
whether a pointer is to a constant or to a variable.

I saw a comment (not public at this list) that suggested that this could be
a difficult thing for a compiler vendor to implement.

Note that there was no mention of interfacing with another language, e.g. C.

-------------------------------------------------

At 2001.October.16 19:13 -0500 Tuesday, Randy Brukardt wrote:
 >
 >> The reader function approach incurs a significant run-time penalty.
 >
 >It shouldn't have any runtime penalty, if combined with a pragma Inline.
 >Why doesn't that solve your problem without introducing any new language
 >features?

It could be bugs in the compiler that Boeing was using or a suspicion of
them.

 >          (If your vendor doesn't Inline these properly, either pressure or
 >change the vendor! This is the sort of thing that Inline was designed to
 >handle).
 >


Inlining is something that may not happen even after the compiler is told
to inline. If it is a serious suggestion, then universities could teach
students how to study Ada code in its assembly language form.

In GNAT there are restrictions on inlining: (quoting from the user guide):

        "The call appears in a body (not in a package spec).".

Also the -gnatn option must be specified and so must a -O1 or -On
optimising option.

An option could be to put the many variables of the package spec, into a
a single record and then have two of those records overlaid.

One record would be constant and exported to other packages.
The other record would be not constant, and its components could be used
inside of the package. Some trick I can't think of at the moment is
used to circumvent the prohibition against applying 'Access to a
constant.

That could be regarded as a proof that compiler vendors can implement the
feature easily. But I am not sure.

Another option might be to have a simple dummy package to get around the
safety problem. Here is an example":

generic
    Pkg_Security_ID_Code : Boolean;
package West_Coast_Consts is
    ...
    A69  : constant Boolean := East_Coast_Vars.A96;
    ...   -- 555 more lines
end West_Coast_Consts;

****************************************************************